Nix proposes an RFC process for substantial changes
The first RFC proposes a design-review path for changes that stall in ordinary issues and pull requests. It separates agreement on a design from the later decision to merge its implementation.
A substantial contribution can stop progressing even when somebody has already written code. The desired outcome may be unclear, reviewers may disagree about direction, or the people needed for a decision may lack time to reconstruct the context. On February 12, 2017, zimbatm opened Nix RFC pull request 1 to propose a more consistent route through that problem. The initial proposal frames the process as a way to avoid losing work when existing contribution channels reach an impasse.
This is a proposal about how to reach design agreement. It does not itself introduce a language feature or alter an installed NixOS system. Its practical effect, if adopted, would be to make some decisions explicit before contributors commit further implementation effort. The cost is another review step, which the draft acknowledges can itself hinder contribution.
I am interested in Nix because declarative systems make desired state inspectable. The same preference makes a written account of a proposed change appealing. A configuration language and a shared package collection need decisions whose reasoning remains available after the immediate discussion has ended.
The draft identifies changes that need design agreement
The initial text proposes an RFC for substantial changes across the Nix language, packages and operating system. Its examples include semantic or syntactic language changes that are not bug fixes, removal of language features and major restructuring of Nixpkgs. New interfaces or functions can also qualify.
That scope is important because an RFC process can become unmanageable if it covers every edit. The draft leaves ordinary package additions, updates and removals outside the requirement. It also excludes additions visible only to developers of Nix rather than users. Bug fixes and documentation improvements can continue through normal pull-request review.
The boundary is explicitly expected to evolve through community norms. That leaves judgement in the process, but it still gives contributors concrete examples. A package version update and a change to language semantics have different coordination costs. Requiring the same preparatory document for both would ignore that difference.
The draft also says an implementation pull request may be closed with a request for an RFC first. That is a significant workflow consequence. It asks an author to establish agreement on the design before treating an already written implementation as the primary object of review.
A document supplies the missing context
The author starts by copying a template into the RFC directory and submitting it as a pull request. The review then concerns the design, including corner cases and examples, rather than only the code that implements one interpretation. Feedback is meant to become part of the document as the proposal changes.
This changes what a reviewer must recover from a discussion. A long issue thread may contain several competing motivations and abandoned approaches. A revised RFC can state the current proposal in one place. Its alternatives and drawbacks explain why the selected approach is worth considering without requiring every reader to infer the decision from scattered comments.
The initial proposal itself contains unfinished language inherited from its template. That is consistent with its status as a starting point for discussion. It would be misleading to treat every procedural detail in this first revision as a settled rule already binding on the project.
The pull-request introduction says the proposal draws heavily on the Rust community's process and should be adapted to Nix. Reusing a known document structure helps begin the discussion, but the author also identifies a practical difference. The community cannot assume that paid staff will implement every accepted design, so support for an idea and availability to perform the work are separate questions.
Active does not mean implemented
Under the initial draft, merging an RFC makes it active. Authors may then implement it and submit the implementation to the appropriate project repository. The draft explicitly says that active status is not a guarantee that the resulting feature will ultimately merge.
This distinction preserves two different reviews. The design review establishes that the major stakeholders are in principle willing to consider the feature. Implementation review still has to evaluate the actual change. A design can be acceptable while a particular implementation remains incomplete or unsuitable.
The proposed merge procedure records an RFC identifier and links the document to its original discussion and an issue in the implementation repository. That gives later work a reference without requiring it to duplicate the entire design conversation. It also gives a reader a way to move between the accepted description and its concrete implementation work.
I regard that traceability as one of the proposal's strongest practical benefits. Knowing that a choice was discussed is less useful than being able to find the problem statement and its alternatives. The document can supply that context to somebody who was not present when the conversation took place.
The process has its own unresolved design questions
The draft asks whether it strikes a useful balance between formality and agility. It also asks whether rejected proposals should remain in an archive. Those questions affect the maintenance burden as well as how much historical reasoning a future contributor can recover.
Retaining a rejected design can explain why an attractive approach was declined, but it also requires readers to distinguish historical proposals from active guidance. A more formal process can make serious proposals easier to compare, yet discourage small contributions if the boundary is unclear. The initial text names those tradeoffs instead of presenting the document as a cost-free improvement.
The alternatives section also identifies retaining the informal process as a valid option. A stricter process could draw on Python proposals, but the draft does not assume that greater formality necessarily improves the result.
The immediate proposal is therefore narrower than a complete governance settlement. It offers a written design-review route for changes that need broader agreement, while leaving normal contribution paths available for routine work. Its usefulness will depend on whether reviewers can turn that written context into decisions and whether contributors can identify when the extra step applies to their change.