What is expected from a candidate when applying to the committers list

[Mic92]

Context: #50 (comment)

(This is not a request to add me to the committers list.)

I'd like to understand what is expected from a candidate before applying. There are examples above the thread of different stature, and so it's hard to say what the actual bar is just by looking at these. I git grep'ed over the repo for committer but nothing specific popped up. I understand that, ultimately, it's up for the existing team to agree, but I assume their deliberation over a candidate is based on some standards / guidelines. I'd love to see those.

Originally posted by @booxter in #321665

Update Since this is a rather opened ended question, I would consider this issue closed when we have publicly documented what we expect from nominees.

[Pandapip1]

At least one criteria: #50 (comment)

@Guanran928 haven't really interacted with you yet, but I feel like this is a bit too short being active to be a committer yet. I feel your contributions are good so I'd suggest being active for somewhat longer and then applying again. And keep going with the great work!

@Mindavi As someone also considering applying for committer access at some point in the (probably distant) future, what would you say the lower bound for "contributing since" is?

I think a good bare minimum would be 2 release cycles (~a year or so). Ultimately it'll be decided on a case-by-case basis, time being active is just one of the factors. But being active longer shows some commitment and involvement, which I feel is important because committers get a lot of responsibility.

[SigmaSquadron]

When I made my nomination, I got the impression that the requirements were loosely defined for a reason. It makes sense to me that the commit delegation team has some internal procedure to approve/deny nominations that can't necessarily be described in quantifiable requirements.

Silvan in #60 (comment) posted a list of numerical requirements to establish a minimum benchmark for new committers:

To become a nixpkgs committer you need:

• To have at least 50 merged PR's, 10 of which non-trivial
• To have review at least 20 non-trivial PR's
• To have added at least 2 new packages, to know how to write nix code and package stuff in nixpkgs
• To have written at least 1 NixOS module

While also conceding that these requirements would be only one of the factors that determine the final decision of the delegation team:

Of course, a manual check will be involved as well, but having such a set of requirements could set a baseline.

Their original proposal was debated by several other contributors, some of which were not a committer at the time, and only received their current permissions later on. Here's a selection of other suggestions:

7c6f434c in #60 (comment):

[In reply to the 20 reviews minimum requirement] I have some vague feeling that this is a risky guideline, maybe we just want to lower the number. Basically, we want non-committers to review things where they are already confident, and some part of a person's project participation time should have gone into getting that confidence. Maybe 20 is a large enough number that it looks like we expect people to be a bit more aggressive about what they review. Not sure (as I said, this is a vague feeling).

Alyssa in #60 (comment):

I would be wary of over-formalising. If you have an entirely numeric public set of benchmarks for when somebody can become (or be considered to become) a contributor, it would be very easy to end up with a situation where there's somebody that the team feels, for whatever reason, wouldn't be a good fit, but has met the benchmarks, and feels that they aren't getting something that they have earned and deserve. On the other hand, those same benchmarks might slow down the process of bringing somebody on board who would unquestionably be an asset. For example, somebody who had made 300 perfect package update PRs and reviewed 300 more from other people would likely be very valuable, even if they had no interest in larger changes or NixOS modules or whatever.

There was also some discussion about the expectations for a non-committer in Nixpkgs, most notably the expectation that a non-committer review some other PRs in Nixpkgs, which is a somewhat novel concept across FOSS communities. Since then, Nixpkgs makes it clearer that anyone is allowed to (and encouraged) to review.

It's also important to mention this comment by Silvan, which would turn the commit delegation process into something akin to what we had during the SC election. Several points made in that comment make a lot of sense to ensure that the delegation committee get to know prospective nominees a bit better, and it would certainly make sense to have more than an introduction and some benchmark numbers written down as a final nomination. Of course, there's the issue of potentially turning the whole process into a popularity contest, which would potentially harm those highlighted by Alyssa in #60 (comment):

One more thing: if commit rights were something that had to be requested, I think that might put people off. "What if I'm rejected?", "What if it's rude to ask, and I should wait until I'm invited?". People can be shy or nervous, and it's important to remember that there is a power imbalance here between the "applicant" and the existing committers that could make asking straight up feel daunting.

But, I digress. Ultimately, the goal from all ideas that appeared in the early days of #60 culminate in ensuring that nominees demonstrate some knowledge of the rights and responsibilities of becoming a committer.

Of course, the first few nominations didn't do any of that. Current (at the time) committers simply nominated those they found were useful without much ado. That said, Janne's nomination helped highlight a potential anti-pattern regarding a committers' motivation, which has generally been accepted into the current consensus:

I hope to be able to make this easier for me (as I don't have to wait) and also easier for other committers (as they don't have to merge my stuff).

This I don't agree with. We should aim at not merging our own stuff, and instead review/merge others' work.

Over time, nominations began manually incorporating the links we now turn to Lorenz's script for. Notably, it seems that Silvan's original numeric requirements were not considered hard minimums, but mere suggestions, as nominees with only 40 merged PRs (at the time) were accepted due to the quality (not quantity) of their contributions.

Later, in davidak's nomination, Samuel Dionne-Riel's endorsement included a mention that they were not "a simple PR reviewer automaton", which is, as far as I can tell, the first time we started separating nit-picky reviews that end in an easy LGTM with in-depth reviews that display knowledge of the system being reviewed.

The requirements didn't change since then. In fact, they became ubiquitous after November of 2021, with several committers describing them as "well-known" or "established". Later on, some committers were removed due to issues related to communication in a group effort. I don't want to dig too much into this, as it's already been discussed to death, but I think it's important to mention that the ability to communicate well is an important ability for a committer, which may or may not be reflected in the delegation committee's final decision.

Finally, we reach the present day. Nominees either self-nominate or are nominated in #50, and most of them have around 50+ merged PRs and 100+ reviews. Having positive experiences with other committers seem to be an important unofficial requirement, as noted in #50 (comment). I think it's fair to say that the current requirements list is loose, and used mostly as a suggested baseline for contributors, though I've noticed there's been a relatively higher importance placed in quantifiable benchmarks lately. (or maybe most accepted nominees in the new issue just reviewed more PRs than the old issue's average)

Bonus: Silvan's proposal for mentoring new committers: #61

TL;DR:

^{This list of requirements is based on my own observation of the process and is in no way representative of the delegation team's decisions.}

• Have around 50 merged PRs, or a smaller number of higher-impact PRs. There is no strict definition of what's high-impact, but common sense will be able to tell you that adding a new package set has a higher impact than a single package update. Ultimately, maintaining what's already there is more important than adding new stuff.
• Most of your PRs should be of a high enough quality so regressions introduced by them are rare. Your ability to respond to these regressions quickly when they occur is also important.
• Review as many PRs as you're comfortable with. Even though most nominees in the new issue have reviewed 100-200 PRs, high quality reviews are more important than being a human code linter.
• Be able to communicate with your fellow maintainers. Put some effort in resolving issues and reconciling differences in opinion when they inevitably occur during code reviews or discussions on Matrix/Discourse.
• Display an understanding of the depths of your responsibility as a committer. While anyone can introduce regressions to Nixpkgs, it's up to you to ensure that Nixpkgs continues to be usable. A committer can wipe the entirety of the master branch by self-merging a PR that deletes everything. Obviously, if you're a maintainer, you won't do anything of the sort on purpose, but it's always possible to do something like this accidentally when you become a committer.
• Display an understanding of your goals as a committer and how not having commit permissions is preventing you from contributing further to Nixpkgs. Nobody should become a committer to quickly self-merge their own PRs, but to help others get their work merged after a thorough review.
• Being here for long enough to understand how Nixpkgs/NixOS operates. The two-release-cycle minimum as described above is a good baseline for this, but it's always possible for someone to memorise the NixOS release wiki in less than a year, or need a couple of years to understand the staging process. Knowing one's maintenance responsibilities across our release cycles is paramount.

[Mic92]

• When I was still on the team, I would not focus on the absolute number of reviews, which is often meaningless. Instead, I would examine the content of reviews and contributions unless I had enough prior knowledge about the user to determine if they knew the codebase well enough to make quality reviews. From my perspective, I would just need to see sufficient activity to make this judgment call.
• I would assess how well they interact with others in general (Are they able to communicate clearly? Are they able to make compromises? How effectively do they handle conflicts and discussions?)
• I would also consider how the rest of the community supports the nomination.

[Sigmanificient]

spotted a tiny typo (candiate -> candidate) :o

[ryand56]

spotted a tiny typo (candiate -> candidate) :o

Also (comitters -> committers) 😉

[Sigmanificient]

Done!

[wolfgangwalther]

I'm proposing to move this issue to the https://github.com/NixOS/nixpkgs-committers repo and pin it there for better visibility.