How will you help decrease the number of open PRs in Nixpkgs?

[PedroHLC]

Question

With the whole Wayland-protocols debate going on, one cannot skip the parallel to Nixpkgs. Some users have a good friend committer to have their PRs reviewed and merged. But the frustration even hits commoters sometimes that are caught self-merging.

Practical solutions to end the frustration would and will take the entire participation community. How can you as a lead help, both to accommodate all the opinions as well to speed the adoption of solutions, taking the number down while caring about the health (consider burnout) of those involved in applying those measures?

Candidates I'd like to get an answer from

No response

Reminder of the Q&A rules

I'm and will follow the Q&A guidelines and rules

PS: Good job on everything related to this repo!

[mschwaig]

I think one productive way to make sure large parts of the community are involved in solving this issue, and to reduce the pressure on individual heroic reviewers, would be spending time and effort on designing incentives that give us the results we want.

For example: There are just as many contributors waiting to get their changes merged, as their are open pull requests (well, except for the bots). How can we incentivize those contributors into reviewing the PRs of others and do it diligently - in order to get their own PRs reviewed and merged faster?

For sure any such proposal would be controversial to some degree, and a lot of discussion will happen in the community and with the SC. In the end I see the role of the SC as taking responsibility for this kind of decision. When there is a specific proposal on the table that people have worked out and analyzed, the SC can make the decision to try it.

[nyabinary]

To address the challenge of reducing the number of open PRs in Nixpkgs, I would advocate for more automation within Nixpkgs, with a particular emphasis on expanding the capabilities of OfBorg. By automating more aspects of the package management process, we can significantly reduce the manual toil/workload on maintainers and committers, which is, in my opinion, critical for preventing burnout and retaining the bulk of our contributors. I will also push for the implementation of automated bumps for a carefully curated core set of packages, ensuring these packages remain consistently up-to-date with minimal manual input. These packages will be supported by a suite of automated test (including unit, integration, regression, and performance test) further decreasing the manual effort required from reviewers and allowing them to focus on more fulfilling tasks than mind-numbingly tasks that require lots of tedious manual labor.

Furthermore, I recognize that many in the Nix community find it challenging to contribute back to the Nix ecosystem, according to recent Nix community surveys results. I will advocate for clearing away roadblocks that make it difficult to contribute, ensuring that the barriers to entry are minimized and that new contributors can more easily participate in the ecosystem. This will involve streamlining processes, improving documentation, and providing better onboarding resources. Additionally, I will actively seek feedback from the community on specific pain points and work collaboratively to address these issues. By making it easier for people to contribute, we can foster a more vibrant and inclusive community, ultimately strengthening the entire Nix ecosystem as a whole :).

[illustris]

My thoughts on this are of course biased by my own frustration in getting PRs merged. These are some possible solutions to reduce frustration and improve the contribution process:

Replace nitpick reviews with automation

The feedback loop for reviews that suggest small syntax changes is too long. It is wasting both the contributors' and reviewers' time. We can handle these with tools like nixf-tidy, leaving reviewers to concentrate on more substantive feedback.

Define guidelines for PR reviews

It's essential to define what makes a PR "merge-ready." Reviewers should avoid delaying merges over trivial issues, especially for PRs that have been open for a long time and have undergone multiple rounds of minor feedback. We should develop guidelines that outline what a constructive review looks like, focusing on significant improvements rather than perfection. Reviewers should communicate clearly about the necessary changes for a PR to be accepted and set appropriate expectations, especially for larger contributions that may require multiple review cycles.

As a member of the steering committee, I would:

1. Promote more automation in the review process
2. Advocate for developing review guidelines
3. Foster an environment where contributors feel valued and supported