The Election Committee announces the second Steering Committee election

[7c6f434c]

Highlighting an edit: the candidate nomination procedure has been copied into announcement from the README

[Zimm_i48]

For some reason, I am in the @NixOS/voters-2025 team (I did get the ping), but not in the eligble.csv file. I checked the SC-election-2025/contributors.csv at 6547d7cf2f7724ca4edda499c72a28e27e0fc980 · NixOS/SC-election-2025 · GitHub file, and my reported numbers there are well above the threshold.

[7c6f434c]

@Zimm_i48 I do see Zimmi48 in eligible.csv, line 284. What is the last line you see there? (maybe GitHub is giving you first-100 rough preview?)

voters-2025 is honestly managed by CI based on eligible.csv, so I would find more likely a useless preview rather than you not being in the list

[Zimm_i48]

Thanks for checking this! Now, the GitHub preview does show this line (and more that were also missing)! So I wonder if it was really GitHub or my browser having stopped loading the page before the end…

[bmillwood]

@ners

Call to action

• If you are an automatically eligible voter, add your email to the voter list:
  Sign in to GitHub · GitHub
• If you are not automatically eligible but significantly contributed to the official projects in one way or another, you may ask for an exception

Who can vote?

The constitution defines a process for automatic voter eligibility based on the number of commits and merge actions in merged PRs opened by a person in any of the projects inside the NixOS GitHub organisation.

• The minimal number of commits for automatic eligibility is 25
• The minimal number of merges for automatic eligibility is 1
• The eligibility window is the past 4 years from and to 1 Aug (see table below for exact dates)

I had the following questions after reading this, which I figured out and summarise below (as a suggested replacement for this section):

• do I need to count my commits to check my eligibility?
• do I need to satisfy one or both of the automatic eligibility conditions?
• what can I conclude from being in the eligible.csv file or the NixOS/voters-2025 team?

---

Call to action

• If you already appear in the automatically eligible voter list and wish to vote in the election, add your e-mail address to your record: Sign in to GitHub · GitHub
• If you are not in the list, but significantly contributed to the official projects in one way or another, you may ask for an exception.

Who can vote?

The constitution is actually very readable on this point, so I’ll just quote it directly:

Before the election (or poll) process is initiated, the EC selects a cutoff date. Only contributions to official projects in the four years preceding the cutoff date are considered.

There are two automatic ways to become eligible for voting, either:

• Have authored enough merged PRs to the NixOS GitHub organisation to total at least 25 commits.
• Have exercised commit access by merging any PR to the NixOS GitHub organisation.

The list of automatically eligible voters is made public.

People not automatically eligible then have some time to send a request to the EC, which can then make an exception and approve them as voters. This is for people whose official contributions are not all visible in the NixOS GitHub organisation, but have contributed roughly the equivalent of 25 commits, also counting contributions such as:

• Participation in official teams
• Infrastructure maintenance
• Organisation of official events
• Maintenance of official third-party accounts (e.g. social media)
• etc.

See the table below for the relevant cutoff dates. The eligible voter list was originally generated using the GitHub API to search for all users matching the automatic criteria, and the NixOS/voters-2025 team is derived from that list.

---

One question I haven’t yet been able to answer myself is what to tell people who want to know more about the process of requesting exceptional eligibility. I suggest writing a little more about that, but I’m not too committed to it

Grateful to the work that’s already been done here! My initial experience of this election was a bit confused (I got added to the NixOS org and didn’t know why that was happening, for example), but I can see a lot has been happening to make it smoother and easier to participate.

[7c6f434c]

eligible.csv is eligibility list (and contributors.csv is the list of counts), if you are in the eligibility list (which is used to control voters-2025 team), you are eligible (and should PR the addition of your preferred email for use with OpaVote to the list, the PR will be auto-merged if everything is done right)

Either of the two auto-eligibility conditions is sufficient.

[Infinisil]

PS: Today is the last day for nominations, including collecting endorsments and sending in the candidate form.

To nominate see GitHub - NixOS/SC-election-2025: 2025 Election for the Steering Committee

Current nominations: Pull requests · NixOS/SC-election-2025 · GitHub

Deadline is 2025-10-01T11:59:00Z

[kiara]

@7c6f434c

CoI-forced recounts are a mess, although not too bad of a mess. Nobody wants them, so people with same CoI seem to have talked in advance last time. I am grateful to them for that. I hope we have the same this time.

It seems like CoI handling is getting relevant again, on the one hand with at least candidates @djacu and @tomberek employed at Anduril, on the other hand with more voices recently arguing similar team membership (esp CppNix members?) should be considered a potential CoI as well.

On another note, I’m not sure I find it a a great idea that existing SC members seemed to not need PRs gathering external nominations to file for candidacy. This would seem to make for an uneven playing field, whereas the PRs I think have been a valuable avenue for public feedback on candidacies - particularly given the low transparency of the SC on its contributions by individual members.

[vcunat]

I fail to see how membership in a team like Nix Team is a conflict of interest, under the current constitution. SC is currently the body that defines and fully controls any other formal teams.

The only explicitly spelled out cases of CoI are related to “the same payer for Nix work”, so I’d be wary of extending it much without additional support for that in the constitution. You need the CoI definition to be relatively clear; I’m afraid it would get messy otherwise.

We’d need a way more elaborately designed constitution if we wanted not to have all teams under the SC, I’d say. Though for example, right now some community members would prefer if the moderation team was not fully controlled by the SC.

[7c6f434c]

@kiara

On another note, I’m not sure I find it a a great idea that existing SC members seemed to not need PRs gathering external nominations to file for candidacy.

Indeed… I think last year’s stats point and their similar positions point towards low risk of both being elected (pre-recount) at 5 places — but if this year is much different, we will do the recounts with dropping the less popular of the two, that’s annoying, not a disaster.

@kiara

On another note, I’m not sure I find it a a great idea that existing SC members seemed to not need PRs gathering external nominations to file for candidacy.

By the constitution, self-nomination+1 endorsement and external-nomination+acceptance are equivalent (and need further endorsements). Self-nomination has been used both by an SC member running for a new term and by people not in SC running for a first term.

@kiara

arguing similar team membership

Without going into merits, and as a personal opinion: after the first decision on endorser CoI is not a good time to change it, and near closing the nominations (or after) is definitely not a good time.

(When these arguments appeared, EC has discussed this and agreed that «around closing the nominations it is too late to try to define this, and there are also details to figure out»)

@vcunat

The only explicitly spelled out cases of CoI are related to “the same payer for Nix work”,

«Same employer» is not only Nix-related employment (this is how EC treats it, and there is at least intent to allow such interpretation in the text).

[SergeK]

@ners

In response to feedback from last year, we got rid of automatic repurposing of emails collected for other purposes (e.g. maintainer list entries).

This was brought up on Matrix already, but I didn’t get the sense the matter reached resolution.
The maintainers-list.nix file (1) predates GDPR by half decade, and (2) to this date does not state any purposes for which emails are being collected.

To follow along with the nation-state role play, there are two sensible ways to look at that data is: either it’s dead weight that can’t be used ever, or it’s contact information of “public servants”^[1] who gave up a piece of their privacy in order to get the job done. Nixpkgs maintainership has always been associated with the latter (prooflink: any github conversation about the forge, the maintainer list, the contributors guide, or packages we don’t want to maintain for free).

I didn’t (yet) check who of the “eligible votes” hasn’t put their email in yet, but I know of at least one prominent (=not myself) contributor who admitted they can’t be bothered to.

1. @ners could you confirm that “eligible voters” without emails would be counted as “absent” and contribute to a measure of “non-representation”?
2. If we’re serious about this SC business, I think we should import the emails from maintainers-list.nix right now.

---

1. Jesus, how do my fingers even allow me to type this ↩︎

[wolfgangwalther]

@SergeK

If we’re serious about this SC business, I think we should import the emails from maintainers-list.nix right now.

Couldn’t agree more.

[7c6f434c]

Nobody understands what the letter of GDPR says exactly on ancient data. In the intent, though, there is a generally understood purpose for which the data was collected, and there were complaints about repurposing (few, that I admit). Which is both bad in terms of the clear part of GDPR spirit, and in terms of OpaVote ToS spirit.

If you wanted an EC that doesn’t care about either, you should have applied for EC work.

[wolfgangwalther]

@7c6f434c

In the intent, though, there is a generally understood purpose for which the data was collected

Yes, but you can’t just stop saying there was an intent - you’ll also have to say what the intent was and whether an SC election would be covered by it.

I strongly believe it is way too narrow to define the intent as “I’m adding my email address here to be contacted about the packages I maintain and nothing else”. Remember - the email address is optional and has always been. Thus the intent of adding the email address can very well be understood as “I’m adding my maintainer entry here to participate in the Nixpkgs/NixOS community and adding my email to be contacted on all community-related matters.”

Voting is about the most fundamental right a maintainer can have. There are strong arguments to be made that the big majority of maintainers would expect to be notified about such an important event via their email address. Not doing so is essentially just preventing a lot of contributors from voting. We have a rule that allows everyone with a reasonable amount of activity within the last 4 years to vote. By not using these emails, we are essentially reducing that to everyone who is currently active enough to see any of the announcements. That’s a big difference.

[7c6f434c]

@wolfgangwalther

Voting is about the most fundamental right a maintainer can have.

Voting access is not actually aligned with maintainership, and having a say about the package is a more fundamental right of maintainership.

@wolfgangwalther

notified about such an important event via their email address

OK, this is different from direct import and probably defensible (and has been gradually prepared, but of course there is always more random events happening that need at least some preparation of reaction…)

[dtomvan]

@SergeK

If we’re serious about this SC business, I think we should import the emails from maintainers-list.nix right now.

A stat: after using nix eval, then jq, then vd to inner-join emails to eligible.csv (that is, only add emails if they were missing in the sense that their Github ID was already listed but not yet any email) I was able to add a whopping 527 emails. That’s over half of the amount of entries in eligible.csv (1012). That would mean that half of people who are eligible to vote has not registered yet and thus are unable to represent themselves as of now. Compare that to the amount of registered voters up until the time of writing this post (2025-10-04T18:50:05+02:00), only 357 (fb650f04)…

For full transparency, here’s what I did if you want to confirm. It’s just a quick hack, nothing fancy.

Process and diff

• Checkout nixpkgs 9ac0381f64566e2da57cc119c24efd5360a32e64
• nix eval --json --file maintainers/maintainer-list.nix | jq -c 'to_entries | map(select(.value.email != null) | .value)[]' > ../SC-election-2025/maintainers.jsonl
• cd ../SC-election-2025
• vd maintainers.jsonl eligible.csv
  • In maintainers, remove name, keys, matrix, github columns
  • In both files, make githubId a key column (!)
  • In eligible, remove all rows that already have an email, and the email column
  • Open the sheets sheet (Shift+S), and mark both files with S
  • Do an inner join (&, then specify “inner”)
  • Save this as new_emails.csv
• cat eligible.csv <(tail -n +2 new_emails.csv) | sort -r | sponge new_emails.csv
• vd new_emails.csv
  • Make githubId a numeric key column again (! #)
  • Execute the select-duplicate-rows command, and delete them (gd)
  • Sort ascending ([)
  • Save as eligible.csv
• Because of how vd saves files, dos2unix eligible.csv
• git diff --stat eligible.csv

Then I got: Maintainer emails to be added to sc-election-2025 · GitHub

I think it’s safe to say at least that a lot of people are missing out on this vote right now…

[colinsane]

those emails are public. if you think it’s right to send all maintainers an email about the SC elections, or notifying them that the Nix Community Survey is open until Dec 1, you can just… do that.

[7c6f434c]

In the meantime, @Infinisil has explained to us (thanks!) that while multiple places of OpaVote docs somewhat imply first the voters are added, then the voting happens, strict order — there is one place that explicitly and unambiguously promises the ability to add voters on the fly.

The EC is intending to use this functionality and thus allow later voter registration (although it will definitely not be transferred in real time)

(Some details including how exactly we update the timeline are currently under discussion)

[SergeK]

@colinsane

you can just… do that.

I know some people are considering doing that, or maybe spawning a parallel OpaVote “poll”? Don’t want to rush, so as to avoid disturbing people more than once.

@7c6f434c

If you wanted an EC that doesn’t care about either, you should have applied for EC work.

Sure, fair. Now merely trying to understand your (current EC’s) plan and confirm it “checks out” despite the haze around emails and the number of voters.

@dtomvan

A stat: … I was able to add a whopping 527 emails

Wow, thank you, I recognize quite a few names in this diff! PS I wrapped some of this logic into a Nix expression:

https://gist.github.com/SomeoneSerge/3a04879aac44dbaa0c6b7818711f2b77#file-voters-nix

[7c6f434c]

@SergeK

@colinsane

you can just… do that.

I know some people are considering doing that, or maybe spawning a parallel OpaVote “poll”? Don’t want to rush, so as to avoid disturbing people more than once.

I think two different OpaVote polls are not likely to be possible to recognise officially in any orderly way even if the entire SC wants it. Of course, unofficial turnout-driving campaigns towards the official election won’t be creating any similar split-election issues.

In the meantime we have agreed on how official reminders could provide a simplified version of confirming the probably-preferred address (EC decision to recognise nginx logs of magic links being clicked as evidence of intent), and asked for an official subdomain so that they don’t look like phishing.