Name: rfcs
Owner: Nix/Nixpkgs/NixOS
Description: The Nix community RFCs
Created: 2017-02-11 15:41:27.0
Updated: 2018-04-06 10:01:21.0
Pushed: 2018-04-24 18:55:51.0
Size: 40
Language: null
GitHub Committers
| User | Most Recent Commit | # Commits |
|---|
Other Committers
| User | Most Recent Commit | # Commits |
|---|
Many changes, including bug fixes and documentation improvements can be implemented and reviewed via the normal GitHub pull request workflow.
Some changes though are “substantial”, and we ask that these be put through a bit of a design process and produce a consensus among the Nix community.
This is the bulk of the RFC. Explain the design in enough detail for somebody familiar with the ecosystem to understand, and implement. This should get into specifics and corner-cases, and include examples of how the feature is used.
This process is followed when one intends to make “substantial” changes to the Nix ecosystem. What constitutes a “substantial” change is evolving based on community norms, but may include the following.
Certain changes do not require an RFC:
Pull requests that contain any of the aforementioned 'substantial' changes may be closed if there is no RFC connected to the proposed changes.
In short, to get a major feature added to the Nix ecosystem, one should first go through the RFC process in order to improve the likelihood of inclusion. Here are roughly the steps that one would take:
0000-template.md to rfcs/0000-my-feature.md (where 'my-feature' is
descriptive. don't assign an RFC number yet).rfcs/0123-my-feature.md)At this point, the person submitting the RFC should find at least one “co-author” that will help them bring the RFC to completion. The goal is to improve the chances that the RFC is both desired and likely to be implemented.
Once the author is happy with the state of the RFC, they should seek for wider community review by stating the readiness of the work. Advertisement on the mailing-list and IRC is an acceptable way of doing that.
After a number of rounds of review the discussion should settle and a general consensus should emerge. This bit is left intentionally vague and should be refined in the future. We don't have a technical committee so controversial changes will be rejected by default.
If a RFC is accepted then authors may implement it and submit the feature as a pull request to the Nix or Nixpkgs repository. An 'accepted' RFC is not a rubber stamp, and in particular still does not mean the feature will ultimately be merged; it does mean that in principle all the major stakeholders have agreed to the feature and are amenable to merging it.
Whoever merges the RFC should do the following:
If a RFC is rejected, whoever merges the RFC should do the following:
The goal for assigning a “co-author” is to help move the RFC along.
The co-author should:
The co-author doesn't necessarily have to agree with all the points of the RFC but should generally be satisfied that the proposed additions are a good thing for the community.
All contributions are licensed by their respective authors under the CC-BY-SA 4.0 License.