Introduce requirement for "buddy"

This commit is contained in:
zimbatm 2017-02-12 15:06:34 +00:00
parent 81cca13346
commit d7e0e45946

View file

@ -1,5 +1,6 @@
- Feature Name: rfc-process - Feature Name: rfc-process
- Start Date: 2017-02-12 - Start Date: 2017-02-12
- Authors: zimbatm, ???
- RFC PR: - RFC PR:
- Related Issue: - Related Issue:
@ -14,16 +15,10 @@ ecosystem is evolving in.
# Motivation # Motivation
[motivation]: #motivation [motivation]: #motivation
There are a number of GitHub issues, PRs and mailing-list discussions where There are a number of changes that are significant enough that they could
significant contribution was put in but then grind to a halt. Usually because benefit from wider community consensus before being implemented. Either
there is either not a clear desirable outcome, the direction taken is not because they introduce new concepts, big changes or are controversial enough
desired (PR) or the stakeholder doesn't have enough brain space available to that not everybody will agree on the direction to take.
think about the issue.
The motiviation for introducing this process is to avoid losing all that work.
By putting contributors through the RFC process for significant changes, it
should help clarify the path for contribution when the other routes aren't
suitable.
# Detailed design # Detailed design
[design]: #detailed-design [design]: #detailed-design
@ -50,6 +45,7 @@ on community norms, but may include the following.
- Removing language features - Removing language features
- Big restructuring of nixpkgs - Big restructuring of nixpkgs
- Introduction of new interfaces or functions - Introduction of new interfaces or functions
- A controversial change
Some changes do not require an RFC: Some changes do not require an RFC:
@ -63,10 +59,9 @@ submit an RFC first.
## What the process is ## What the process is
In short, to get a major feature added to the Nix ecosystem, one must first In short, to get a major feature added to the Nix ecosystem, one should first
get the RFC merged into the RFC repo as a markdown file. At that point the RFC go throught the RFC process in order to improve the likelyhood of inclusion.
is 'active' and may be implemented with the goal of eventual inclusion into Here are roughly the steps that one would take:
the Nix ecosystem.
* Fork the RFC repo https://github.com/NixOS/rfcs * Fork the RFC repo https://github.com/NixOS/rfcs
* Copy `0000-template.md` to `rfcs/0000-my-feature.md` (where * Copy `0000-template.md` to `rfcs/0000-my-feature.md` (where
@ -78,9 +73,9 @@ the design from the larger community.
are much more likely to make progress than those that don't receive any are much more likely to make progress than those that don't receive any
comments. comments.
Eventually, somebody on the [core team] will either accept the RFC by At this point, the person submitting the RFC should find at least one "buddy"
merging the pull request, at which point the RFC is 'active', or that will help him bring the RFC to reality. The goal is to improve the
reject it by closing the pull request. chances that the RFC is both desired and lilely to be implemented.
Whomever merges the RFC should do the following: Whomever merges the RFC should do the following: