nixos/rfcs
1
0
Fork 0
mirror of https://github.com/NixOS/rfcs.git synced 2025-11-09 03:56:11 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Typo fixes

Browse source
This commit is contained in:
Eelco Dolstra 2017-03-28 14:40:19 +02:00
parent cff5922776
commit d439f087e7
No known key found for this signature in database
GPG key ID: 8170B4726D7198DE
1 changed files with 12 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

20
README.md
View file

@ -19,13 +19,13 @@ community norms, but may include the following.
* Any semantic or syntactic change to the language that is not a bug fix * Any semantic or syntactic change to the language that is not a bug fix
* Removing language features * Removing language features
* Big restructuring of nixpkgs * Big restructuring of Nixpkgs
* Expansions to the scope of nixpkgs (new arch, major subprojects, ...) * Expansions to the scope of Nixpkgs (new arch, major subprojects, ...)
* Introduction of new interfaces or functions * Introduction of new interfaces or functions
Certain changes do not require an RFC: Certain changes do not require an RFC:
* Adding, updating and removing packages in nixpkgs * Adding, updating and removing packages in Nixpkgs
* Fixing security updates and bugs that don't break interfaces * Fixing security updates and bugs that don't break interfaces
Pull requests that contain any of the aforementioned 'substantial' changes may be closed if there is no RFC connected to the proposed changes. Pull requests that contain any of the aforementioned 'substantial' changes may be closed if there is no RFC connected to the proposed changes.
@ -33,14 +33,14 @@ Pull requests that contain any of the afore mentioned 'substantial' changes may
## Description of the process ## Description of the process
In short, to get a major feature added to the Nix ecosystem, one should first 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 likelyhood of inclusion. go through the RFC process in order to improve the likelihood of inclusion.
Here are roughly the steps that one would take: Here are roughly the steps that one would take:
* Fork the RFC repo https://github.com/NixOS/rfcs * Fork the RFC repository https://github.com/NixOS/rfcs
* Copy `0000-template.md` to `rfcs/0000-my-feature.md` (where 'my-feature' is * Copy `0000-template.md` to `rfcs/0000-my-feature.md` (where 'my-feature' is
descriptive. don't assign an RFC number yet). descriptive. don't assign an RFC number yet).
* Fill in the RFC * Fill in the RFC
* Submit a pull request. Rename the rfcs with the PR number. (eg: PR #123 would * Submit a pull request. Rename the RFC with the PR number. (eg: PR #123 would
be `rfcs/0123-my-feature.md`) be `rfcs/0123-my-feature.md`)
At this point, the person submitting the RFC should find at least one "co-author" At this point, the person submitting the RFC should find at least one "co-author"
@ -48,16 +48,16 @@ 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. 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 Once the author is happy with the state of the RFC, they should seek for
wider community review by stating the readyness of the work. Advertisement on wider community review by stating the readiness of the work. Advertisement on
the mailing-list and IRC is an acceptable way of doing that. 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 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 consensus should emerge. This bit is left intentionally 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 committee 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 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 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 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 merged; it does mean that in principle all the major stakeholders have agreed
to the feature and are amenable to merging it. to the feature and are amenable to merging it.
@ -69,7 +69,7 @@ Whoever merges the RFC should do the following:
* Commit everything. * Commit everything.
If a RFC is rejected, whoever merges the RFC should do the following: If a RFC is rejected, whoever merges the RFC should do the following:
* Move the rfc to the rejected folder * Move the RFC to the rejected folder
* 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.
* Include a summary reason for the rejection * Include a summary reason for the rejection