The NixOS RFC Process

History

The NixOS RFC process was established in March 2017, initiated by zimbatm, teh and Moretea in order to standardise a process to find an agreement on larger changes to Nix/NixOS/Nixpkgs and the ecosystem in general. Over the following one and a half years a few uncontroversial RFCs were merged but for most of the RFCs that needed further discussion nobody felt responsible to make a decision. That is the reason RFC 36 was written in collaboration with most core Nix/Nixpkgs members at the last NixCon and merged in December 2018 in order to streamline the process and define clearer responsibilities.

Now as a follow-up RFC 43, concerning the rotation of the RFC Steering Committee, has been merged and now is a good point in time to explain the whole process and more recent changes.

As an additional motivation to understand the process, a widely awaited RFC draft on Nix Flakes has just been opened by edolstra.

For those familiar with the Rust RFC process, it will be obvious that parts of it have been more than just inspiration and it has mainly just been adapted to reflect the fact that we don’t have formal subteams.

The “Teams”

First of all a little terminology and explanation how the teams work. For each RFC we have two teams, the first being the RFC Steering Committee. Its sole purpose is to establish a team of 4-5 people for each RFC, the shepherd team, that help guide the RFC and the discussion around it to a point where it can easily be decided if it should be accepted or rejected. This team will generally be made up of different people for each RFC.

RFC Steering Committee (RFCSC)

This committee is responsible for forming an RFC Shepherd team from the available nominations on each RFC. This team also names the leader of the Shepherd team. This has to happen within 1 week after the PR has been opened. Until then the Steering Committee is responsible for guiding the discussion. In case of the Shepherding Team not doing its work the Steering Committee shall encourage them or step in and assign new Shepherds. They also are in charge of merging accepted and rejected RFCs. Generally by these expectations they should find time to meet once a week for about an hour.

They have no special responsibility with regard to the content of an RFC, they can weigh in on them, the same as any other community member, but are only in charge of:

• selecting the Shepherds unanimously
• supervising that the Shepherds are carrying out their work
• committing the final RFC

Shepherd Team

A team of 3-4 community members defined unanimously by the RFC Steering Committee, responsible for accepting or rejecting a specific RFC. This team is created per RFC from community members nominated in the discussion on that RFC.

This team should be people who are very familiar with the main components touched by the RFC. The author cannot be part of the Shepherd Team. In addition, at most half of the Shepherd Team can be part of the RFC Steering Committee.

The responsibility of the team is to guide the discussion as long as it is constructive, new points are brought up and the RFC is iterated on and from time to time summarise the current state of discussion. If this is the case no longer, then the Shepherd Team shall step in with a motion for FCP.

Shepherd Leader

The person in charge of the RFC process for a specific RFC, and responsible for ensuring the process is followed in a timely fashion. The Shepherd Leader has no special responsibility with regard to moving an undecided Shepherd Team to a certain decision.

Current Procedure

Writing the RFC

Generally the idea for the creation of an RFC is to copy the RFC template from the NixOS/rfcs GitHub repository and draft the PR before opening a PR. Preferably one should also try to find someone else proficient in the topic of the RFC and let them review it and discuss improvements. When an RFC is properly fleshed out the author should open a PR on GitHub to expand the discussion to the whole community.

Shepherd Nomination

After the PR is opened the RFCSC opens the RFC for shepherd nominations at the latest at their weekly meeting. Anyone can propose anyone for the shepherd team, self nominations are perfectly fine, too. Ideally people who work on parts the RFC affects or are otherwise affected by it, should end up on the team.

Discussion

After a week, if there are enough nominees who are willing to be on the team, or at the first meeting of the RFCSC where that is the case they select 4-5 of the nominees for shepherd team and appoint a leader. This team then guides the discussion to solutions to open issues and from time to time summarises the discussion. They are highly encouraged to meet up for short video conferences, ideally with the author, to discuss the best way to move the RFC further towards a decision.

Final Comment Period (FCP)

At a point where the discussion doesn’t seem to progress any further and a general opinion has been reached in it, the shepherd team calls the Final Comment Period of 10 days proposing either to accept and merge the RFC or to reject it. If no new points are brought up, livening up the discussion, the RFC is merged or closed after this period.

NEW: RFCSC Rotation

The above has all been in place since December, but now just recently another RFC has been merged, defining the rotation and selection of the RFCSC. Once a year the current committee selects the following one; in November each year a four week nomination period starts, where anyone can be nominated for membership of the succeeding RFCSC. Currently sitting members are not excluded from being nominated; generally, keeping a part of the existing team will probably make the transition smoother, but due to having to nominate oneself again, allows for reflection if enough commitment can still be made. In the first meeting of the committee in December the current members decide on their successors, ideally unanimously, otherwise by vote. The new committee formally starts their work in January but is encouraged to join the other meetings in December to improve the transition.