Nix moves its development mailing list to nix-devel

A design document cannot attract wider review if contributors do not know where its announcement belongs. On July 12, 2017, the project announces the move of the nix-dev mailing list to nix-devel on Google Groups. The announcement is brief, giving the old name and the new destination. Its practical significance is clearer beside the project's RFC process, which explicitly uses mailing-list announcements to bring proposals to the wider community.

The RFC process text available by this point separates preparing a proposal from inviting broader review. Once an author is satisfied with the document, advertising its readiness on the mailing list and IRC is an acceptable next step. The list is therefore part of the route by which a design receives attention, even when the actual document and review remain in a pull request.

I value the explicit configuration model in Nix, and the same preference applies to project decisions. A recorded proposal is useful only if the people affected can find it and participate. A clear announcement of the new discussion venue helps preserve that connection when a communication service changes.

Announcement and review have different jobs

The RFC process asks authors to submit a document to the RFC repository and find at least one co-author. The co-author helps move the document along, responds to inquiries and handles minor issues so that community discussion can focus on design. Wider advertisement follows that preparation.

This gives the mailing list a specific role. It directs attention to a proposal that has reached a state suitable for broader discussion. It does not replace the written design or make the announcement itself an implementation review. A reader receiving the announcement still needs the linked context to evaluate the proposed change.

The separation reduces ambiguity about where a decision's details should live. A short notice can explain why a proposal matters and point to its document. The document can accumulate corrections and alternatives during review. Moving the announcement venue changes how readers discover that work, while the repository continues to hold the proposed design.

That is why a list migration matters even to somebody who mostly reads source changes. The absence of a code diff does not mean the development workflow is unaffected. A contributor using an obsolete destination may fail to reach the audience expected by the process, despite having prepared the document correctly.

Substantial changes need an audience beyond their author

The process identifies semantic or syntactic language changes, removal of language features and major Nixpkgs restructuring as examples of substantial work. It also includes expansions to Nixpkgs' scope and new interfaces. These changes can affect people who are not watching the particular implementation files.

Ordinary package additions, updates and removals do not require that extra RFC step. Security updates and bug fixes that preserve interfaces also remain outside it. That distinction makes wider advertisement especially relevant for the changes that cross several users' or maintainers' concerns.

The process does not turn popularity into an automatic merge rule. It says an accepted RFC means the major stakeholders agree in principle, while the implementation still needs its own pull request. It also acknowledges that the way discussion reaches consensus remains intentionally vague and needs refinement.

I regard that distinction as necessary when reading a development list. An announcement asks for attention, and agreement on a design establishes a direction. Neither is evidence that a working feature has already shipped. The source document preserves those separate stages explicitly.

A new destination does not establish archive policy

The July announcement confirms the move and links the Google Groups destination. It does not explain the reason for selecting the service, specify a forwarding period or say that historical messages have been imported. Those operational questions cannot be answered merely by knowing the new list's name.

That limit matters when following older references. A historical discussion can explain a prior decision, while the new venue tells a contributor where development discussion is moving. The existence of a new destination does not itself prove that an older thread will appear under the same identifier there.

The distinction also helps keep citations precise. A proposal should link the discussion that supports its account of the design. A current announcement should identify the place intended to reach current readers. Treating those as separate references avoids requiring one URL to represent both historical evidence and present participation.

Written proposals preserve context across the move

The RFC process asks a rejected proposal to retain a summary reason for rejection, and an accepted proposal retains links in its metadata. That record can help a contributor understand why work did or did not proceed without reconstructing every conversation from the mailing list alone.

The July change supplies a new place to announce that continuing work. Contributors can use nix-devel for the development-list role identified in the announcement, while keeping the design and its review context in the RFC workflow. The move changes a communication dependency whose address matters to the people expected to take part.