nixos/rfcs
1
0
Fork 0
mirror of https://github.com/NixOS/rfcs.git synced 2025-12-17 14:31:17 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Describe the rejected state

Browse source
This commit is contained in:
zimbatm 2017-03-11 19:32:22 +00:00
parent c28db71a17
commit 9830d2d792
1 changed files with 12 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

20
rfcs/0000-rfc-process.md
View file

@ -87,19 +87,24 @@ consensus should emerge. This bit is left intentionnaly vague and should be
refined in the future. We don't have a technical commitee so controversial refined in the future. We don't have a technical commitee so controversial
changes will be rejected by default. 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 repo. 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: Whoever merges the RFC should do the following:
* Create a corresponding issue on the appropriate repo (NixOS/Nix,
NixOS/nixpkgs, ...).
* Fill in the remaining metadata in the RFC header, including links for the * Fill in the remaining metadata in the RFC header, including links for the
original pull request(s) and the newly created issue. original pull request(s) and the newly created issue.
* Commit everything. * Commit everything.
Once an RFC becomes active then authors may implement it and submit the If a RFC is rejected, whoever merges the RFC should do the following:
feature as a pull request to the Nix or nixpkgs repo. An 'accepted' RFC is not * Move the rfc to the rejected folder
a rubber stamp, and in particular still does not mean the feature will * Fill in the remaining metadata in the RFC header, including links for the
ultimately be merged; it does mean that in principle all the major original pull request(s) and the newly created issue.
stakeholders have agreed to the feature and are amenable to merging it. * Include a summary reason for the rejection
* Commit everything
## Role of the "co-author" ## Role of the "co-author"
@ -145,6 +150,5 @@ To be solved in the future:
1. Does this RFC strike a favorable balance between formality and agility? 1. Does this RFC strike a favorable balance between formality and agility?
2. Does this RFC successfully address the aforementioned issues with the current 2. Does this RFC successfully address the aforementioned issues with the current
informal RFC process? informal RFC process?
3. Should we retain rejected RFCs in the archive?
[PEP]: http://legacy.python.org/dev/peps/pep-0001/ [PEP]: http://legacy.python.org/dev/peps/pep-0001/