mirror of
https://github.com/NixOS/rfcs.git
synced 2025-12-01 06:31:11 +01:00
Introduce requirement for "buddy"
This commit is contained in:
parent
81cca13346
commit
d7e0e45946
1 changed files with 12 additions and 17 deletions
|
|
@ -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:
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue