In regards to that, recently I’ve seen the CODEOWNERS features from GitLab. While it does not solve the finding a committer it might be useful?
(As much as I disliked GH this is not a forge migration suggestion, just throwing more ideas into the collective consciousness).
For item 1: Basically certain the first exists, although there are warnings that the detection isn’t always perfect. I think they just get added as requested reviewers? r-ryantm has explicit maintainer pings in its PRs also.
For item 2: Looking at https://github.com/NixOS/nixpkgs/blob/c4fa370b3419e637a73d9f5907b9752299824990/ci/github-script/bot.js#L496 suggests that something is happening with owners, although tbh I haven’t dug into what an owner is in the context of nixpkgs.
For item 3: It sounds like an interesting idea, although obviously a more complicated logic to implement. No ideas on whether or not there is anything like this in the stuff within .github/workflows, ci/eval, ci/github-script, and ci/codeowners-validator or other varioius CI-type stuff.
I want to begin to say that I can empathize with your feelings.
Onboarding on nixpkgs is hard, but at the same time, I’d argue it is much easier than on other Linux package repositories because of how open the process is.
Literally anyone can create a nixpkgs PR, and this probably also is a source of why we have so many more pending PRs than adequate reviewers.
Now I am not advocating for changing this, I actually think it’s one of the best feats of nixpkgs.
When I encounter a PR that shows all the signs of someone unfamiliar to contributing to nixpkgs, I try to get in direct contact with them to explain the process and procedure.
Doing this through a back and forth in PR review has most often turned out impersonal and counterproductive from my point of view.
As my time and resources are limited, I admittedly can’t do this direct engagement more often than a few times per year, but for those where I did, I always experienced a much faster understanding of what is required to get the PR into a mergeable state.
Then someone will come along, say “you misspelled the word ‘attribute’,” or “that doesn’t match how I would do it,“ and there it is. Your review. Nothing of substance said about the content.
There is an ongoing attempt to discourage nits.
They are not meant to be blocking, but as you rightfully noted, others will still shy away from dismissing them.
Do reach out to other committers if you encounter them. I know it seems hard, but communication is a big key here.
This is not necessarily their fault, as annoying as it is. Nixpkgs is a volunteer project and you cannot force people to do so. But there is also negative incentive for any other above to occur. Why review anything when you can just not? Why merge anything when you can just not? There’s absolutely no reason some Jane Commit should every look at anyones’ PR. In fact it sounds quite annoying to do so when she has been at work all day. Luckily to keep her commit bit all she has to do is merge one PR a year. So she merges an update for a tool she uses at work. “Great, I did my part for the year. See you next.”
I’ve been a committer for close to 1.5 years now.
Indeed, for those who just got ahold of the commit bit, merging less often and rather trivial changes will seem the saver choice.
I still see a big issue with the onboarding of new committers.
There was an attempt at bringing mentoring to new committers, but from what I heard, this was never really made use of.
I did suggest in the past to have a communication channel for committers, but unfortunately that was decided against because it might increase the perception of the privileged in-club.
I still think this would be a good thing to have, maybe even as a Discourse category instead of a Matrix room, in lack of better onboarding.
Also, a lot of committers still were “grandfathered” into the current state of nixpkgs, having been granted the commit bit in a time where stakes and activity were much lower.
Some of these actually don’t know the current criteria of reviewing and merging, some even stated they wouldn’t be able to maintain their packages if they lost it in their respective automated retirement PRs.
On the other hand, I doubt that drastically shrinking the amount of older existing committers helps with reducing the workload of reviews in any way, so this will not address your own woes unfortunately.
Taking a good look at projects that are quite nice to contribute to, what do they do? They have accountability and responsibility for PRs. Nixpkgs already has some in terms of meta.maintainers. How to make someone feel accountable or responsible for PRs from the peanut gallery? Take a good look at the Rust Project.
Nixpkgs also has topic-related responsibility in the form of teams.
In fact, these have been triaged recently to ensure they are not used to manage company-ownership of packages but actually restrict them to topics, making joining them not depend on external organization membership but on actual skill set and interest.
You can read more about this on https://github.com/NixOS/nixpkgs/issues/478780.
Also, the “CODEOWNERS” file suggested by another comment here already exists: https://github.com/NixOS/nixpkgs/blob/87524662728cd61d67c0d28abbabe3ccec182043/ci/OWNERS.
We do lack a mechanism to automatically assign a vetted reviewer to PRs that do not otherwise have someone responsible for the touched code, that much is true.
My only contribution to the Rust project did receive a review within two days, although that too just boiled down to “LGTM”.
Yet, I’d like to point out that the Rust project does not nearly experience the high amount of contributions we do.
Looking at just the past month, NixOS/nixpkgs merged 8750 pull requests while 2001 pull requests were opened that have not yet been merged.
In comparison, the rust-lang/rust repository has merged 729 pull requests in the last month, with 275 yet unmerged PRs that were opened in that time.
The ratio is quite similar, so arguably we are not doing worse than the Rust project at least.
Now what can we do to improve on this still?
There actually is some community tooling that helps with picking up PRs in dire need of review.
The best one I am aware of is developed by @FliegendeWurst: https://nixpkgs-prs.fliegendewurst.eu/.
I think this is an amazing tool, but I was not aware of it when I originally gained the commit bit.
Showing the tools available must also become part of the onboarding for new committers.
Another comment here raised the idea of approvals increasing the priority of a PR for committers.
The criticism of this becoming a “+1” is valid, but we could introduce a group of trusted reviewers as mitigation, as a pre-form of the commit bit.
There isn’t much risk coming from these, so it could be handed to any vetted person and revoked from anyone abusing it as a “+1” mechanism.
Further ideas that (as far as I remember) were considered by @emily and others were more granular privileges, partially by means of the rather successful nixpkgs merge bot.
A large amount of PRs only deal with package changes, but a committer gets merge rights for all parts of nixpkgs, be those NixOS modules, packages or the library.
Of course, blindly merging things to these without prior communication to the people responsible will rightfully get you a lecture and possibly revocation of the commit bit.
I think it makes sense to keep my reply at this length. I do have more thoughts on the topic, but writing them out takes time, and shaping them to be actionable even more.
I think what else could somewhat help tooling-wise is:
/remind-bot: I am not going to touch this for next 10 days without a reaction from maintainer, but please review-request me afterwards, and in the week afterwards I might find time to review this in the «maintainer-away» frame.meta.reviewers: I acknowledge that I will not meet the canonical maintainer baseline expectations (originally established as roughly «will do best to answer any questions of another person who is trying to do something about the package»), but I am interested enough in the package that I am willing to be review-requested to merge it (as usual, after real-maintainer approval or a week with no reaction, and obvoiusly subject to the positively-merge bar being higher than no-blocking-review bar)Both things are mostly about burnout-safely getting more reviews and merges from committers who have once tried and gave up on the firehose-triage (like me) and retreated to the smaller sectors of competence (and probably with energy expenditure limits for Nixpkgs reviews — which limits should be less stressed when the reviews requested are relevant to interests anyway).