Progress report
Since our initial update, the Nixpkgs core team has:
-
Formalized a minimal set of consensus‐based decision‐making procedures for our initial bootstrap.
-
Established a line of contact to the NixOS Foundation board, which we are using to try to re‐establish the line of contact to GitHub to discuss Nixpkgs’ needs and problems.
-
Reorganized Nixpkgs maintainer teams on GitHub. This included removing leftover Nixpkgs write roles from security and systemd teams and the maintainer role from release managers; these were required because of the old GitHub codeowners implementation, but are now unnecessary and prevent onboarding of non-committers.
-
Established a new onboarding workflow for maintainer teams and approved the first new GitHub team that way.
-
Delegated full control of
cabal2nixandjailbreak-cabalrepos to the Haskell team, giving them admin rights. -
Set up the new
staging-nixosbranch in our capacity as the new codeowners of the branch protection rulesets for Nixpkgs.
Statement on membership
We do not believe that members speaking in one voice is beneficial to a team like ours, and indeed aim to avoid making collective team statements at all where unnecessary. We therefore see no need to restrict individual political activity of our members. However, we have agreed from the start that given the workload involved, the nature of substantive delegation, and the Steering Committee’s role as a backstop, no member should serve on the Nixpkgs core team and the Steering Committee simultaneously. Therefore, we have agreed that any member elected to the SC will step down from the Nixpkgs core team.
In general, we are acutely aware of the need to develop procedures for Nixpkgs core team membership and decisions that are accountable to the contributors and teams we exist to serve. The usual model of teams appointing their own members has served the NixOS project well, and is more in line with the project value of distributed decision‐making than direct appointment by a body like the SC, especially for a team based around extensive experience with direct Nixpkgs work. We also recognize, however, that the Nixpkgs core team’s wide scope and oversight of existing teams demands additional accountability to contributors beyond the SC’s backstop role.
We have not yet worked out the details, but taking inspiration from the Rust Project’s Leadership council, we currently believe a model of drawing future core team candidates from established Nixpkgs teams nominating their own members will be the best fit to provide a balance of bottom‐up accountability and ensuring that the Nixpkgs core team consists of highly‐involved contributors who can work well together as a team.
Next steps
Our immediate priorities are:
-
Continuing our efforts to get in touch with teams and contributors across the project.
-
Making contact with the new Steering Committee after the election to discuss our respective visions for the project and strengthen our working relationship.
-
Defining more fully‐fledged procedures for Nixpkgs core team membership and decision‐making based on the considerations above.
Medium‐term goals
Going forward from our initial bootstrap and in collaboration with the community, we see the following as high priorities for improving Nixpkgs decision‐making and sustainability:
-
Formulating a better RFC process for Nixpkgs, to prevent initiatives fizzling out without a clear decision when an easy consensus cannot be reached, while maintaining strong community involvement in big decisions.
-
Reforming the Nixpkgs commit bit procedures for increased transparency and quicker decisions, in collaboration with the committer delegation team.
-
Addressing the PR triage bottleneck and reducing the burden on committers, e.g. by:
-
Establishing a “trusted maintainer” role that allows wider use of the merge bot for vetted package maintainers, to help empower contributors while mitigating the risks of tree‐wide commit access in a growing project.
-
Improving checklists and automate triage for Nixpkgs contributions, especially from new contributors.
-
Better distributing work on wide‐scale changes to individual package maintainers and notify maintainers of build regressions.
-
-
Reworking the contribution documentation to be more approachable while defining the expectations for contributors, reviewers, maintainers, and committers more clearly.
We obviously can’t achieve these single‐handedly, and they’re not set in stone; the prioritization and implementation will depend on input and collaboration from the community. As always, we encourage you to get in touch with any feedback you might have. We will provide further updates as we go.