From 9fe54e6f62b9c4a386c2f8b08d5e4388a10a42f0 Mon Sep 17 00:00:00 2001 From: David Arnold Date: Wed, 19 May 2021 21:35:22 -0400 Subject: [PATCH 01/29] Start: Propose RFC Categories --- rfcs/0093-rfc-categories.md | 93 +++++++++++++++++++++++++++++++++++++ 1 file changed, 93 insertions(+) create mode 100644 rfcs/0093-rfc-categories.md diff --git a/rfcs/0093-rfc-categories.md b/rfcs/0093-rfc-categories.md new file mode 100644 index 000000000..afc33b9ee --- /dev/null +++ b/rfcs/0093-rfc-categories.md @@ -0,0 +1,93 @@ +--- +feature: rfc_categories +start-date: 2021-05-19 +author: David Arnold +co-authors: (find a buddy later to help out with the RFC) +shepherd-team: (names, to be nominated and accepted by RFC steering committee) +shepherd-leader: (name to be appointed by RFC steering committee) +related-issues: +--- + +# Summary +[summary]: #summary + +The RFC process is amended with means to categorize RFCs into one of: _feature_, +_information_ or _process_, where each category sets different accents that +improve the overall process. + +# Motivation +[motivation]: #motivation + +Some issues are not addressed by the community: + +There is no appropriate venue for it. + +Specifically, it is hard to propose a well coordinated experiment across the community, +document and acknowledge design issues, record proof-generated insight, but also to +amend the RFC process itself, the forum rules, the code of conduct or propose any other +other binding changes to community workflows or infrastructure. + +# Detailed design +[design]: #detailed-design + +Every RFC that is eligible for the RFC process is classified by the author into the +_information_, _process_ or _feature_ category. How those categories are defined in every +detail, can remain subjective, but the following should give a sufficient idea: + +- Informational RFCs + - Start a talk, meetup, or social networking account that will be expected to officially “represent nix” + - Document design issues, deciding to never implement a feature + - Proposing an experiment + - Recording a proof-generated insight +- Process RFCs + - Change the RFC process, the organization of the issue tracker or the support forum + - Changes to community workflows or other community infrastructure + - Amend the Code of Conduct +- Feature RFCs + - Anything that is currently covered by the RFC process and does not better fit into + any of the other two categories. + +Before this RFC reaches FCP, the RFC template is amended accordingly through this PR. + +# Examples and Interactions +[examples-and-interactions]: #examples-and-interactions + +This section illustrates the detailed design. This section should clarify all +confusion the reader has from the previous sections. It is especially important +to counterbalance the desired terseness of the detailed design; if you feel +your detailed design is rudely short, consider making this section longer +instead. + +# Drawbacks +[drawbacks]: #drawbacks + +No substantial drawback comes to my mind, that would not be an alibi for this section. + +# Alternatives +[alternatives]: #alternatives + +No alternative comes to my mind, that would not be an alibi for this section. + +# Unresolved questions +[unresolved]: #unresolved-questions + +At the point of initiating this RFC, the detailed changes to the template are not yet known. +They will be complemented at any suitable point before reaching FCP. + +# Future work +[future]: #future-work + +With the additional metadata proposed herein present in RFCs, we might start to find it useful +to present different RFC categories in different contexts. + +One such example can be to render +_Process RFCs_ within the governance section of the Discourse forum. + +Another example might be to formally frame the discussion differently according to the RFC category. +Since we can't know yet, I'm not proposing any of this in here. + +# Prior Art + +This RFC is primarily inspired by the [BORS RFC][bors-rfc] process. + +[bors-rfc]: https://bors.tech/rfcs/ From cd48c4dcacfc17445a71c748d0620cfa71ac13bf Mon Sep 17 00:00:00 2001 From: David Arnold Date: Thu, 20 May 2021 13:54:50 -0400 Subject: [PATCH 02/29] Add some "meat" (feedback @asymmetric) --- rfcs/0093-rfc-categories.md | 42 ++++++++++++++++++++++++++++++++----- 1 file changed, 37 insertions(+), 5 deletions(-) diff --git a/rfcs/0093-rfc-categories.md b/rfcs/0093-rfc-categories.md index afc33b9ee..737f5668e 100644 --- a/rfcs/0093-rfc-categories.md +++ b/rfcs/0093-rfc-categories.md @@ -13,26 +13,46 @@ related-issues: The RFC process is amended with means to categorize RFCs into one of: _feature_, _information_ or _process_, where each category sets different accents that -improve the overall process. +improve the overall outcome of the process. # Motivation [motivation]: #motivation -Some issues are not addressed by the community: +## Some issues are not addressed by the community -There is no appropriate venue for it. +There is no appropriate venue for it. When reading the current RFC process, it becomes +clear that it was made primarily with purely technical decisions in mind. It might only +be a peception, but this perception systemically skews what's being discussed and what +not. + +It is my perception that important topics are not adressed and settled by the community +at large in a standardized procedure. Specifically, it is hard to propose a well coordinated experiment across the community, document and acknowledge design issues, record proof-generated insight, but also to amend the RFC process itself, the forum rules, the code of conduct or propose any other other binding changes to community workflows or infrastructure. +## Some issues are not addressed by the appropriate angle + +Even if, in the past, people might have used the RFC Process to gather broader consensus +around some of the hard-to-propose topics exemplified in the previous paragraph, the +ensuing discussion still might have been framed in a non-suited way. + +By explicitly categorizing RFCs into one of the proposed categories, it will be immediatly +evident for participants that those RFCs are a) legitimate and b) require an evaluation +within the sensible boundaries of their categories. For example, it is hard to imagine, +that a proof-generated insight being recorded as an _Informational RFC_ would receive a +request for an actual proposal to improve the situation. In this example, gathering +broad consensus about acknowledgement becomes easier. It is hard to imagine, how such +an attempt would go smoothly within the current framing. + # Detailed design [design]: #detailed-design -Every RFC that is eligible for the RFC process is classified by the author into the +Every RFC that is eligible for the RFC process is classified by its author into the _information_, _process_ or _feature_ category. How those categories are defined in every -detail, can remain subjective, but the following should give a sufficient idea: +detail can remain subjective, but the following should give a sufficient idea: - Informational RFCs - Start a talk, meetup, or social networking account that will be expected to officially “represent nix” @@ -86,6 +106,18 @@ _Process RFCs_ within the governance section of the Discourse forum. Another example might be to formally frame the discussion differently according to the RFC category. Since we can't know yet, I'm not proposing any of this in here. +Once we have some experiences with those categories, we might also decide to: + +- differentiate categories, add more +- differentiate processes for different categories, for example, for a Process RFC that modifies + workflows, we could adopt a different workflow: + 1. Create a Process RFC + 1. Initial Comment Period + 1. Implement Prototype, request infrastructure for prototype + 1. Generate data & insights from Prototype and record them in the RFC + 1. Proceed to Final COmment Period + 1. Fully implement in production after RFC acceptation. + # Prior Art This RFC is primarily inspired by the [BORS RFC][bors-rfc] process. From fdc9d5d460cef2ed3c3650378eec6276d3bea157 Mon Sep 17 00:00:00 2001 From: David Arnold Date: Thu, 20 May 2021 14:07:49 -0400 Subject: [PATCH 03/29] Fixup wordings / typos --- rfcs/0093-rfc-categories.md | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/rfcs/0093-rfc-categories.md b/rfcs/0093-rfc-categories.md index 737f5668e..efd6f5d3d 100644 --- a/rfcs/0093-rfc-categories.md +++ b/rfcs/0093-rfc-categories.md @@ -22,30 +22,30 @@ improve the overall outcome of the process. There is no appropriate venue for it. When reading the current RFC process, it becomes clear that it was made primarily with purely technical decisions in mind. It might only -be a peception, but this perception systemically skews what's being discussed and what +be a perception, but this perception systemically skews what's being discussed and what not. -It is my perception that important topics are not adressed and settled by the community -at large in a standardized procedure. +As a result, important topics are not adressed and settled by the community at large +in a generally accepted procedure. Specifically, it is hard to propose a well coordinated experiment across the community, document and acknowledge design issues, record proof-generated insight, but also to amend the RFC process itself, the forum rules, the code of conduct or propose any other -other binding changes to community workflows or infrastructure. +binding changes to community workflows or infrastructure. ## Some issues are not addressed by the appropriate angle Even if, in the past, people might have used the RFC Process to gather broader consensus around some of the hard-to-propose topics exemplified in the previous paragraph, the -ensuing discussion still might have been framed in a non-suited way. +ensuing discussion still might have been framed in a way that is not best suited. -By explicitly categorizing RFCs into one of the proposed categories, it will be immediatly -evident for participants that those RFCs are a) legitimate and b) require an evaluation -within the sensible boundaries of their categories. For example, it is hard to imagine, -that a proof-generated insight being recorded as an _Informational RFC_ would receive a -request for an actual proposal to improve the situation. In this example, gathering -broad consensus about acknowledgement becomes easier. It is hard to imagine, how such -an attempt would go smoothly within the current framing. +By explicitly categorizing RFCs, it will be immediatly evident for participants that +those RFCs are a) legitimate and b) require an evaluation within the sensible boundaries +of their categories. For example, it is hard to imagine, that a proof-generated insight +being recorded as an _Informational RFC_ would receive a request for an actual proposal +to improve the situation. In this example, gathering broad consensus about acknowledgement +becomes easier. It is hard to imagine, how such an attempt would go smoothly within the +current framing. # Detailed design [design]: #detailed-design @@ -72,11 +72,11 @@ Before this RFC reaches FCP, the RFC template is amended accordingly through thi # Examples and Interactions [examples-and-interactions]: #examples-and-interactions -This section illustrates the detailed design. This section should clarify all -confusion the reader has from the previous sections. It is especially important -to counterbalance the desired terseness of the detailed design; if you feel -your detailed design is rudely short, consider making this section longer -instead. +The relevant examples and interactions are already exposed in the motivation section. +The detailed design does not require further exemplification, since it is intended to be +an authors personal best judgment without significant backlash on the categorization +that drives the categorization, not a specific set of criteria. I don't think its +feasible to develop such fixed set of creteria herin in a meaningful way. # Drawbacks [drawbacks]: #drawbacks From 141b575ca4dff601346dd8baefcbf0c0f652e42c Mon Sep 17 00:00:00 2001 From: David Arnold Date: Fri, 11 Jun 2021 15:10:55 -0500 Subject: [PATCH 04/29] Differentiate RFC templates --- 0000-template.md => 0000-template-feature.md | 30 ++++--- 0000-template-informational.md | 35 ++++++++ 0000-template-process.md | 92 ++++++++++++++++++++ 3 files changed, 145 insertions(+), 12 deletions(-) rename 0000-template.md => 0000-template-feature.md (58%) create mode 100644 0000-template-informational.md create mode 100644 0000-template-process.md diff --git a/0000-template.md b/0000-template-feature.md similarity index 58% rename from 0000-template.md rename to 0000-template-feature.md index 43569cf57..fee9f4570 100644 --- a/0000-template.md +++ b/0000-template-feature.md @@ -8,51 +8,57 @@ shepherd-leader: (name to be appointed by RFC steering committee) related-issues: (will contain links to implementation PRs) --- + + # Summary [summary]: #summary -One paragraph explanation of the feature. + # Motivation [motivation]: #motivation -Why are we doing this? What use cases does it support? What is the expected -outcome? + # Detailed design [design]: #detailed-design -This is the core, normative part of the RFC. Explain the design in enough + # Examples and Interactions [examples-and-interactions]: #examples-and-interactions -This section illustrates the detailed design. This section should clarify all + # Drawbacks [drawbacks]: #drawbacks -Why should we *not* do this? + # Alternatives [alternatives]: #alternatives -What other designs have been considered? What is the impact of not doing this? + # Unresolved questions [unresolved]: #unresolved-questions -What parts of the design are still TBD or unknowns? + # Future work [future]: #future-work -What future work, if any, would be implied or impacted by this feature -without being directly part of the work? + diff --git a/0000-template-informational.md b/0000-template-informational.md new file mode 100644 index 000000000..e8954ce02 --- /dev/null +++ b/0000-template-informational.md @@ -0,0 +1,35 @@ +--- +information: (fill me in with a unique ident, my_new_fact) +start-date: (fill me in with today's date, YYYY-MM-DD) +author: (name of the main author) +co-authors: (find a buddy later to help out with the RFC) +shepherd-team: (names, to be nominated and accepted by RFC steering committee) +shepherd-leader: (name to be appointed by RFC steering committee) +relates-to: + - [RFC 0000 my_other_information]() +--- + + + +# Summary +[summary]: #summary + + + +In order to address "X", I/we propose to "Y". + +# My Structure + + diff --git a/0000-template-process.md b/0000-template-process.md new file mode 100644 index 000000000..5aab813b0 --- /dev/null +++ b/0000-template-process.md @@ -0,0 +1,92 @@ +--- +process: (fill me in with a unique ident, my_new_process) +start-date: (fill me in with today's date, YYYY-MM-DD) +author: (name of the main author) +co-authors: (find a buddy later to help out with the RFC) +shepherd-team: (names, to be nominated and accepted by RFC steering committee) +shepherd-leader: (name to be appointed by RFC steering committee) +modifies: + - [RFC 0000 my_old_process]() +--- + + + +# Summary +[summary]: #summary + + + +In order to address "X", I/we propose to "Y". + +# Classification +[classification]: #classification + + + +- [ ] general habits and decision making +- [ ] core technical protocols & processes +- [ ] contributer efficiency support + +# Motivation +[motivation]: #motivation + + + +# Current Process +[as-is]: #current-process + + + +# Future Process +[to-be]: #future-process + + + +# Roles & Stakeholders + + + +# Pros & Cons +[evaluation]: #pros-and-cons + + + +## Pros + + +## Cons + + +# Conclusion +[conclusion]: #conclusion + + + +# Updates +[updates]: #updates + + From 986d268f27fec1bd2482ba084dda72542a750653 Mon Sep 17 00:00:00 2001 From: David Arnold Date: Fri, 11 Jun 2021 15:20:15 -0500 Subject: [PATCH 05/29] Move all "legacy" RFCs into correct categories --- {rfcs => feature}/0004-replace-unicode-quotes.md | 0 {rfcs => feature}/0023-musl-libc.md | 0 ...32-run-phase-changes-for-better-nix-shell-use.md | 0 {rfcs => feature}/0042-config-option.md | 0 {rfcs => feature}/0045-deprecate-url-syntax.md | 0 {rfcs => feature}/0046-platform-support-tiers.md | 0 {rfcs => feature}/0052-dynamic-ids.md | 0 {rfcs => feature}/0072-commonmark-docs.md | 0 .../0080-nixos-release-schedule.md | 0 .../0085-nixos-release-stablization.md | 0 {rfcs => process}/0001-rfc-process.md | 0 {rfcs => process}/0015-release-manager.md | 0 {rfcs => process}/0025-nix-core-team.md | 0 {rfcs => process}/0026-staging-workflow.md | 0 {rfcs => process}/0036-review-process.png | Bin .../0036-rfc-process-team-amendment.md | 0 {rfcs => process}/0036-rfc-process.png | Bin .../0039-unprivileged-maintainer-teams.md | 0 {rfcs => process}/0043-rfcsc-rotation.md | 0 {rfcs => process}/0044-disband-nix-core.md | 0 {rfcs => process}/0051-mark-stale-issues.md | 0 {rfcs => process}/0055-retired-committers.md | 0 .../0071-retired-committers-amendment.md | 0 {rfcs => process}/0093-rfc-categories.md | 0 24 files changed, 0 insertions(+), 0 deletions(-) rename {rfcs => feature}/0004-replace-unicode-quotes.md (100%) rename {rfcs => feature}/0023-musl-libc.md (100%) rename {rfcs => feature}/0032-run-phase-changes-for-better-nix-shell-use.md (100%) rename {rfcs => feature}/0042-config-option.md (100%) rename {rfcs => feature}/0045-deprecate-url-syntax.md (100%) rename {rfcs => feature}/0046-platform-support-tiers.md (100%) rename {rfcs => feature}/0052-dynamic-ids.md (100%) rename {rfcs => feature}/0072-commonmark-docs.md (100%) rename {rfcs => informational}/0080-nixos-release-schedule.md (100%) rename {rfcs => informational}/0085-nixos-release-stablization.md (100%) rename {rfcs => process}/0001-rfc-process.md (100%) rename {rfcs => process}/0015-release-manager.md (100%) rename {rfcs => process}/0025-nix-core-team.md (100%) rename {rfcs => process}/0026-staging-workflow.md (100%) rename {rfcs => process}/0036-review-process.png (100%) rename {rfcs => process}/0036-rfc-process-team-amendment.md (100%) rename {rfcs => process}/0036-rfc-process.png (100%) rename {rfcs => process}/0039-unprivileged-maintainer-teams.md (100%) rename {rfcs => process}/0043-rfcsc-rotation.md (100%) rename {rfcs => process}/0044-disband-nix-core.md (100%) rename {rfcs => process}/0051-mark-stale-issues.md (100%) rename {rfcs => process}/0055-retired-committers.md (100%) rename {rfcs => process}/0071-retired-committers-amendment.md (100%) rename {rfcs => process}/0093-rfc-categories.md (100%) diff --git a/rfcs/0004-replace-unicode-quotes.md b/feature/0004-replace-unicode-quotes.md similarity index 100% rename from rfcs/0004-replace-unicode-quotes.md rename to feature/0004-replace-unicode-quotes.md diff --git a/rfcs/0023-musl-libc.md b/feature/0023-musl-libc.md similarity index 100% rename from rfcs/0023-musl-libc.md rename to feature/0023-musl-libc.md diff --git a/rfcs/0032-run-phase-changes-for-better-nix-shell-use.md b/feature/0032-run-phase-changes-for-better-nix-shell-use.md similarity index 100% rename from rfcs/0032-run-phase-changes-for-better-nix-shell-use.md rename to feature/0032-run-phase-changes-for-better-nix-shell-use.md diff --git a/rfcs/0042-config-option.md b/feature/0042-config-option.md similarity index 100% rename from rfcs/0042-config-option.md rename to feature/0042-config-option.md diff --git a/rfcs/0045-deprecate-url-syntax.md b/feature/0045-deprecate-url-syntax.md similarity index 100% rename from rfcs/0045-deprecate-url-syntax.md rename to feature/0045-deprecate-url-syntax.md diff --git a/rfcs/0046-platform-support-tiers.md b/feature/0046-platform-support-tiers.md similarity index 100% rename from rfcs/0046-platform-support-tiers.md rename to feature/0046-platform-support-tiers.md diff --git a/rfcs/0052-dynamic-ids.md b/feature/0052-dynamic-ids.md similarity index 100% rename from rfcs/0052-dynamic-ids.md rename to feature/0052-dynamic-ids.md diff --git a/rfcs/0072-commonmark-docs.md b/feature/0072-commonmark-docs.md similarity index 100% rename from rfcs/0072-commonmark-docs.md rename to feature/0072-commonmark-docs.md diff --git a/rfcs/0080-nixos-release-schedule.md b/informational/0080-nixos-release-schedule.md similarity index 100% rename from rfcs/0080-nixos-release-schedule.md rename to informational/0080-nixos-release-schedule.md diff --git a/rfcs/0085-nixos-release-stablization.md b/informational/0085-nixos-release-stablization.md similarity index 100% rename from rfcs/0085-nixos-release-stablization.md rename to informational/0085-nixos-release-stablization.md diff --git a/rfcs/0001-rfc-process.md b/process/0001-rfc-process.md similarity index 100% rename from rfcs/0001-rfc-process.md rename to process/0001-rfc-process.md diff --git a/rfcs/0015-release-manager.md b/process/0015-release-manager.md similarity index 100% rename from rfcs/0015-release-manager.md rename to process/0015-release-manager.md diff --git a/rfcs/0025-nix-core-team.md b/process/0025-nix-core-team.md similarity index 100% rename from rfcs/0025-nix-core-team.md rename to process/0025-nix-core-team.md diff --git a/rfcs/0026-staging-workflow.md b/process/0026-staging-workflow.md similarity index 100% rename from rfcs/0026-staging-workflow.md rename to process/0026-staging-workflow.md diff --git a/rfcs/0036-review-process.png b/process/0036-review-process.png similarity index 100% rename from rfcs/0036-review-process.png rename to process/0036-review-process.png diff --git a/rfcs/0036-rfc-process-team-amendment.md b/process/0036-rfc-process-team-amendment.md similarity index 100% rename from rfcs/0036-rfc-process-team-amendment.md rename to process/0036-rfc-process-team-amendment.md diff --git a/rfcs/0036-rfc-process.png b/process/0036-rfc-process.png similarity index 100% rename from rfcs/0036-rfc-process.png rename to process/0036-rfc-process.png diff --git a/rfcs/0039-unprivileged-maintainer-teams.md b/process/0039-unprivileged-maintainer-teams.md similarity index 100% rename from rfcs/0039-unprivileged-maintainer-teams.md rename to process/0039-unprivileged-maintainer-teams.md diff --git a/rfcs/0043-rfcsc-rotation.md b/process/0043-rfcsc-rotation.md similarity index 100% rename from rfcs/0043-rfcsc-rotation.md rename to process/0043-rfcsc-rotation.md diff --git a/rfcs/0044-disband-nix-core.md b/process/0044-disband-nix-core.md similarity index 100% rename from rfcs/0044-disband-nix-core.md rename to process/0044-disband-nix-core.md diff --git a/rfcs/0051-mark-stale-issues.md b/process/0051-mark-stale-issues.md similarity index 100% rename from rfcs/0051-mark-stale-issues.md rename to process/0051-mark-stale-issues.md diff --git a/rfcs/0055-retired-committers.md b/process/0055-retired-committers.md similarity index 100% rename from rfcs/0055-retired-committers.md rename to process/0055-retired-committers.md diff --git a/rfcs/0071-retired-committers-amendment.md b/process/0071-retired-committers-amendment.md similarity index 100% rename from rfcs/0071-retired-committers-amendment.md rename to process/0071-retired-committers-amendment.md diff --git a/rfcs/0093-rfc-categories.md b/process/0093-rfc-categories.md similarity index 100% rename from rfcs/0093-rfc-categories.md rename to process/0093-rfc-categories.md From db237d502a5afb425cc1532769659485a72b35d8 Mon Sep 17 00:00:00 2001 From: David Arnold Date: Fri, 11 Jun 2021 15:44:55 -0500 Subject: [PATCH 06/29] Update Readme with RFC Categories (implied) changes --- README.md | 89 ++++++++++++++++++++++++++++++++++--------------------- 1 file changed, 56 insertions(+), 33 deletions(-) diff --git a/README.md b/README.md index 892e23595..2257aff21 100644 --- a/README.md +++ b/README.md @@ -1,15 +1,15 @@ # Nix RFCs (Request For Comments) -Many changes, including bug fixes and documentation improvements can be +Many ideas, 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. +Some ideas though are "substantial", and we ask that these be put through a +bit of a public process and produce a consensus among the Nix community. ## When this process is followed -This process is followed when one intends to make "substantial" changes to the -Nix ecosystem. What constitutes a "substantial" change is evolving based on +This process is followed when one intends to apply "substantial" ideas to the +Nix ecosystem. What constitutes a "substantial" idea is evolving based on community norms, but may include the following. * Any semantic or syntactic change to the language that is not a bug fix @@ -17,13 +17,23 @@ community norms, but may include the following. * Big restructuring of Nixpkgs * Expansions to the scope of Nixpkgs (new arch, major subprojects, ...) * Introduction of new interfaces or functions +* Making changes to important of formalised community processes +* Record important proof-generated insights that affect the whole community +* Propose an important experiment that affects the whole community +* Document important design issues that affect the whole community +* Start a talk/account/etc. that "officially represents the nix community" Certain changes do not require an RFC: * Adding, updating and removing packages in Nixpkgs * Fixing security updates and bugs that don't break interfaces +* Starting any talk/account/etc. that does not officially represent nix +* Making process changes to (language) sub-systems without being relevant + to the community as a whole +* Conducting experiments, recording insights or documenting design issues in + (language) sub-systems that don't affect the community as a whole. -Pull requests that contain any of the aforementioned 'substantial' changes may +Pull requests that contain any of the aforementioned 'substantial' ideas may be closed if there is no RFC connected to the proposed changes. ## Terminology @@ -73,28 +83,28 @@ the RFC has received ample discussion and enough of the tradeoffs have been discussed. The Shepherd Team will propose to either accept or reject the RFC after the FCP. +##### RFC Categories +In order to do do justice to the different aspects of documents that merit +generation of broad community consensus via the RFC process, we cassify each +RFC into _feature_, _process_ and _informational_ RFCs. All follow the same +high-level process as described above, but each category requires a different +"mode of discussion", templates, critarias and judgment that it is benefical +to the overall RFC process to identify those categories explicitly. + ## Process from Creation to Merge -*In short, to get a major change included in Nix or Nixpkgs, one must +*In short, to get a major change included in Nix, Nixpkgs or the Ecosystem, one must first get the RFC merged into the RFC repository as a markdown file under the -`rfcs` directory. At that point the RFC is accepted and may be implemented -with the goal of eventual inclusion into Nix or Nixpkgs.* - -0. Have a cool idea! -1. Fill in the RFC. Put care into the details: RFCs that do not present - convincing motivation, demonstrate understanding of the impact of the design, - or are disingenuous about the drawbacks or alternatives tend to be - poorly-received. You might want to create a PR in your fork of the RFCs - repository to help you flesh it out with a few supporters or chat/video - conference with a few people involved in the topic of the RFC. -2. In case your RFC is a technical proposal, you might want to prepare a - prototype of your idea to firstly make yourself aware of potential pitfalls - and also help reviewers understand the RFC. Code may be able to explain some - issues in short. +corresponding directory. At that point the RFC is accepted and may be implemented +with the goal of eventual inclusion into Nix, Nixpkgs or the Ecosystem.* + +0. Have a cool idea r an important information! +1. Identify its category: _feature_, _process_ or _informational_. +2. Start with the correct template and follow the instructions and comments. 3. Submit a pull request. As a pull request the RFC will receive design feedback from the larger community, and the author should be prepared to revise it in - response. + response. Leave them in draft while you're still actively working on them. 4. For the nomination process for potential members of the RFC Shepherd Team, that is specific to each RFC, anyone interested can either nominate another person or themselves to be a potential member of the RFC Shepherd Team. This @@ -152,28 +162,41 @@ with the goal of eventual inclusion into Nix or Nixpkgs.* ![RFC Process](./rfcs/0036-rfc-process.png) ![Review Process](./rfcs/0036-review-process.png) +### Tips + +###### Create Prototypes +In case your RFC is a technical proposal, you might want to prepare a +prototype of your idea to firstly make yourself aware of potential pitfalls +and also help reviewers understand the RFC. Code may be able to explain some +issues in short. + +###### Motivation First +In any case, it can be a good idea to elaborate the motivation first, while +leaving the PR in draft. This helps to ensure, that when the solution is +discussed in the future, interested participants can have a clear and refined +picture of the problem that you try to address. ## The RFC life-cycle -Once an RFC is accepted the authors may implement it and submit the feature as a -pull request to the Nix or Nixpkgs repo. Being accepted 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. In general though this means that the -implementation will be merged as long as there are no substantial technical +Once an RFC is accepted the authors may implement it and for example submit the +feature as a pull request to the Nix or Nixpkgs repo. Being accepted 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. In general though this means that +the implementation will be merged as long as there are no substantial technical objections to the implementation. Furthermore, the fact that a given RFC has been accepted implies nothing about what priority is assigned to its implementation, nor does it imply anything -about whether a Nix/Nixpkgs developer has been assigned the task of implementing -the feature. While it is not necessary that the author of the RFC also write the -implementation, it is by far the most effective way to see an RFC through to +about whether a Nix/Nixpkgs community member has been assigned the task of +implementing the RFC. While it is not necessary that the author of the RFC also +does the implementation, it is by far the most effective way to see an RFC through to completion: authors should not expect that other project developers will take on responsibility for implementing their accepted feature. Minor modifications to accepted RFCs can be done in follow-up pull requests. We -strive to write each RFC in a manner that it will reflect the final design of -the feature; but the nature of the process means that we cannot expect every +strive to write each RFC in a manner that it will reflect the final state of +the world; but the nature of the process means that we cannot expect every merged RFC to actually reflect what the end result will be after implementation. In general, once accepted, RFCs should not be substantially changed. Only very From 4478db4ae31bbfda264b9a2324adf5813d90ac1f Mon Sep 17 00:00:00 2001 From: David Arnold Date: Fri, 11 Jun 2021 19:18:52 -0500 Subject: [PATCH 07/29] Polish wording a bit, update where in order --- process/0093-rfc-categories.md | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/process/0093-rfc-categories.md b/process/0093-rfc-categories.md index efd6f5d3d..c65ca78ad 100644 --- a/process/0093-rfc-categories.md +++ b/process/0093-rfc-categories.md @@ -33,26 +33,24 @@ document and acknowledge design issues, record proof-generated insight, but also amend the RFC process itself, the forum rules, the code of conduct or propose any other binding changes to community workflows or infrastructure. -## Some issues are not addressed by the appropriate angle +## Some issues are not addressed from the appropriate angle Even if, in the past, people might have used the RFC Process to gather broader consensus -around some of the hard-to-propose topics exemplified in the previous paragraph, the -ensuing discussion still might have been framed in a way that is not best suited. +around some of those hard-to-propose topics, the ensuing discussion still might have been +framed in a way that is not best suited. This actually starts with the sctructure of the +template. By explicitly categorizing RFCs, it will be immediatly evident for participants that -those RFCs are a) legitimate and b) require an evaluation within the sensible boundaries -of their categories. For example, it is hard to imagine, that a proof-generated insight -being recorded as an _Informational RFC_ would receive a request for an actual proposal -to improve the situation. In this example, gathering broad consensus about acknowledgement -becomes easier. It is hard to imagine, how such an attempt would go smoothly within the -current framing. +those RFCs are a) legitimate and b) require an evaluation within the fair boundaries +of their categories. # Detailed design [design]: #detailed-design Every RFC that is eligible for the RFC process is classified by its author into the -_information_, _process_ or _feature_ category. How those categories are defined in every -detail can remain subjective, but the following should give a sufficient idea: +_information_, _process_ or _feature_ category. For each category a different template +is made available. How those categories are defined in every detail can remain +subjective, but the following should give a sufficient idea: - Informational RFCs - Start a talk, meetup, or social networking account that will be expected to officially “represent nix” @@ -67,7 +65,8 @@ detail can remain subjective, but the following should give a sufficient idea: - Anything that is currently covered by the RFC process and does not better fit into any of the other two categories. -Before this RFC reaches FCP, the RFC template is amended accordingly through this PR. +This RFC is accompanied by commits that implement it. Please refer to them for the detailed +design. # Examples and Interactions [examples-and-interactions]: #examples-and-interactions From be5eb702b1e0297a470f1e39926e137ead40f066 Mon Sep 17 00:00:00 2001 From: David Arnold Date: Sat, 12 Jun 2021 15:24:20 -0500 Subject: [PATCH 08/29] fixup: typo Co-authored-by: Moritz Hedtke <13287984+mohe2015@users.noreply.github.com> --- 0000-template-feature.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/0000-template-feature.md b/0000-template-feature.md index fee9f4570..93bd71aa3 100644 --- a/0000-template-feature.md +++ b/0000-template-feature.md @@ -10,7 +10,7 @@ related-issues: (will contain links to implementation PRs) From 653c373cd63fe0ee3b3dd32f4f19caf59400e142 Mon Sep 17 00:00:00 2001 From: David Arnold Date: Sat, 12 Jun 2021 15:24:30 -0500 Subject: [PATCH 09/29] fixup: typo Co-authored-by: Moritz Hedtke <13287984+mohe2015@users.noreply.github.com> --- README.md | 10 +++++----- process/0093-rfc-categories.md | 4 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index 2257aff21..aab441fcc 100644 --- a/README.md +++ b/README.md @@ -85,21 +85,21 @@ after the FCP. ##### RFC Categories In order to do do justice to the different aspects of documents that merit -generation of broad community consensus via the RFC process, we cassify each +generation of broad community consensus via the RFC process, we classify each RFC into _feature_, _process_ and _informational_ RFCs. All follow the same high-level process as described above, but each category requires a different -"mode of discussion", templates, critarias and judgment that it is benefical +"mode of discussion", templates, criteria and judgment that it is beneficial to the overall RFC process to identify those categories explicitly. ## Process from Creation to Merge -*In short, to get a major change included in Nix, Nixpkgs or the Ecosystem, one must +*In short, to get a major change included in Nix, Nixpkgs or the ecosystem, one must first get the RFC merged into the RFC repository as a markdown file under the corresponding directory. At that point the RFC is accepted and may be implemented -with the goal of eventual inclusion into Nix, Nixpkgs or the Ecosystem.* +with the goal of eventual inclusion into Nix, Nixpkgs or the Ecosystem. -0. Have a cool idea r an important information! +0. Have a cool idea or an important information! 1. Identify its category: _feature_, _process_ or _informational_. 2. Start with the correct template and follow the instructions and comments. 3. Submit a pull request. As a pull request the RFC will receive design feedback diff --git a/process/0093-rfc-categories.md b/process/0093-rfc-categories.md index c65ca78ad..39f44f502 100644 --- a/process/0093-rfc-categories.md +++ b/process/0093-rfc-categories.md @@ -75,7 +75,7 @@ The relevant examples and interactions are already exposed in the motivation sec The detailed design does not require further exemplification, since it is intended to be an authors personal best judgment without significant backlash on the categorization that drives the categorization, not a specific set of criteria. I don't think its -feasible to develop such fixed set of creteria herin in a meaningful way. +feasible to develop such fixed set of criteria herein in a meaningful way. # Drawbacks [drawbacks]: #drawbacks @@ -114,7 +114,7 @@ Once we have some experiences with those categories, we might also decide to: 1. Initial Comment Period 1. Implement Prototype, request infrastructure for prototype 1. Generate data & insights from Prototype and record them in the RFC - 1. Proceed to Final COmment Period + 1. Proceed to Final Comment Period 1. Fully implement in production after RFC acceptation. # Prior Art From 8359e656bfbed88b84984ebb263850dab9542aa6 Mon Sep 17 00:00:00 2001 From: David Arnold Date: Sun, 11 Jul 2021 07:27:05 -0500 Subject: [PATCH 10/29] Add Shepherds --- process/0093-rfc-categories.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/process/0093-rfc-categories.md b/process/0093-rfc-categories.md index 39f44f502..c1d31014e 100644 --- a/process/0093-rfc-categories.md +++ b/process/0093-rfc-categories.md @@ -3,8 +3,8 @@ feature: rfc_categories start-date: 2021-05-19 author: David Arnold co-authors: (find a buddy later to help out with the RFC) -shepherd-team: (names, to be nominated and accepted by RFC steering committee) -shepherd-leader: (name to be appointed by RFC steering committee) +shepherd-team: @kevnicox, @Mic92, @gytis-ivaskevicius +shepherd-leader: @kevincox related-issues: --- From b2d5489dd602a8bb83ded6a8df8ea8c23ea5500b Mon Sep 17 00:00:00 2001 From: David Arnold Date: Wed, 21 Jul 2021 11:52:16 -0500 Subject: [PATCH 11/29] Revert "Move all "legacy" RFCs into correct categories" This reverts commit 986d268f27fec1bd2482ba084dda72542a750653. --- {process => rfcs}/0001-rfc-process.md | 0 {feature => rfcs}/0004-replace-unicode-quotes.md | 0 {process => rfcs}/0015-release-manager.md | 0 {feature => rfcs}/0023-musl-libc.md | 0 {process => rfcs}/0025-nix-core-team.md | 0 {process => rfcs}/0026-staging-workflow.md | 0 ...32-run-phase-changes-for-better-nix-shell-use.md | 0 {process => rfcs}/0036-review-process.png | Bin .../0036-rfc-process-team-amendment.md | 0 {process => rfcs}/0036-rfc-process.png | Bin .../0039-unprivileged-maintainer-teams.md | 0 {feature => rfcs}/0042-config-option.md | 0 {process => rfcs}/0043-rfcsc-rotation.md | 0 {process => rfcs}/0044-disband-nix-core.md | 0 {feature => rfcs}/0045-deprecate-url-syntax.md | 0 {feature => rfcs}/0046-platform-support-tiers.md | 0 {process => rfcs}/0051-mark-stale-issues.md | 0 {feature => rfcs}/0052-dynamic-ids.md | 0 {process => rfcs}/0055-retired-committers.md | 0 .../0071-retired-committers-amendment.md | 0 {feature => rfcs}/0072-commonmark-docs.md | 0 .../0080-nixos-release-schedule.md | 0 .../0085-nixos-release-stablization.md | 0 {process => rfcs}/0093-rfc-categories.md | 0 24 files changed, 0 insertions(+), 0 deletions(-) rename {process => rfcs}/0001-rfc-process.md (100%) rename {feature => rfcs}/0004-replace-unicode-quotes.md (100%) rename {process => rfcs}/0015-release-manager.md (100%) rename {feature => rfcs}/0023-musl-libc.md (100%) rename {process => rfcs}/0025-nix-core-team.md (100%) rename {process => rfcs}/0026-staging-workflow.md (100%) rename {feature => rfcs}/0032-run-phase-changes-for-better-nix-shell-use.md (100%) rename {process => rfcs}/0036-review-process.png (100%) rename {process => rfcs}/0036-rfc-process-team-amendment.md (100%) rename {process => rfcs}/0036-rfc-process.png (100%) rename {process => rfcs}/0039-unprivileged-maintainer-teams.md (100%) rename {feature => rfcs}/0042-config-option.md (100%) rename {process => rfcs}/0043-rfcsc-rotation.md (100%) rename {process => rfcs}/0044-disband-nix-core.md (100%) rename {feature => rfcs}/0045-deprecate-url-syntax.md (100%) rename {feature => rfcs}/0046-platform-support-tiers.md (100%) rename {process => rfcs}/0051-mark-stale-issues.md (100%) rename {feature => rfcs}/0052-dynamic-ids.md (100%) rename {process => rfcs}/0055-retired-committers.md (100%) rename {process => rfcs}/0071-retired-committers-amendment.md (100%) rename {feature => rfcs}/0072-commonmark-docs.md (100%) rename {informational => rfcs}/0080-nixos-release-schedule.md (100%) rename {informational => rfcs}/0085-nixos-release-stablization.md (100%) rename {process => rfcs}/0093-rfc-categories.md (100%) diff --git a/process/0001-rfc-process.md b/rfcs/0001-rfc-process.md similarity index 100% rename from process/0001-rfc-process.md rename to rfcs/0001-rfc-process.md diff --git a/feature/0004-replace-unicode-quotes.md b/rfcs/0004-replace-unicode-quotes.md similarity index 100% rename from feature/0004-replace-unicode-quotes.md rename to rfcs/0004-replace-unicode-quotes.md diff --git a/process/0015-release-manager.md b/rfcs/0015-release-manager.md similarity index 100% rename from process/0015-release-manager.md rename to rfcs/0015-release-manager.md diff --git a/feature/0023-musl-libc.md b/rfcs/0023-musl-libc.md similarity index 100% rename from feature/0023-musl-libc.md rename to rfcs/0023-musl-libc.md diff --git a/process/0025-nix-core-team.md b/rfcs/0025-nix-core-team.md similarity index 100% rename from process/0025-nix-core-team.md rename to rfcs/0025-nix-core-team.md diff --git a/process/0026-staging-workflow.md b/rfcs/0026-staging-workflow.md similarity index 100% rename from process/0026-staging-workflow.md rename to rfcs/0026-staging-workflow.md diff --git a/feature/0032-run-phase-changes-for-better-nix-shell-use.md b/rfcs/0032-run-phase-changes-for-better-nix-shell-use.md similarity index 100% rename from feature/0032-run-phase-changes-for-better-nix-shell-use.md rename to rfcs/0032-run-phase-changes-for-better-nix-shell-use.md diff --git a/process/0036-review-process.png b/rfcs/0036-review-process.png similarity index 100% rename from process/0036-review-process.png rename to rfcs/0036-review-process.png diff --git a/process/0036-rfc-process-team-amendment.md b/rfcs/0036-rfc-process-team-amendment.md similarity index 100% rename from process/0036-rfc-process-team-amendment.md rename to rfcs/0036-rfc-process-team-amendment.md diff --git a/process/0036-rfc-process.png b/rfcs/0036-rfc-process.png similarity index 100% rename from process/0036-rfc-process.png rename to rfcs/0036-rfc-process.png diff --git a/process/0039-unprivileged-maintainer-teams.md b/rfcs/0039-unprivileged-maintainer-teams.md similarity index 100% rename from process/0039-unprivileged-maintainer-teams.md rename to rfcs/0039-unprivileged-maintainer-teams.md diff --git a/feature/0042-config-option.md b/rfcs/0042-config-option.md similarity index 100% rename from feature/0042-config-option.md rename to rfcs/0042-config-option.md diff --git a/process/0043-rfcsc-rotation.md b/rfcs/0043-rfcsc-rotation.md similarity index 100% rename from process/0043-rfcsc-rotation.md rename to rfcs/0043-rfcsc-rotation.md diff --git a/process/0044-disband-nix-core.md b/rfcs/0044-disband-nix-core.md similarity index 100% rename from process/0044-disband-nix-core.md rename to rfcs/0044-disband-nix-core.md diff --git a/feature/0045-deprecate-url-syntax.md b/rfcs/0045-deprecate-url-syntax.md similarity index 100% rename from feature/0045-deprecate-url-syntax.md rename to rfcs/0045-deprecate-url-syntax.md diff --git a/feature/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md similarity index 100% rename from feature/0046-platform-support-tiers.md rename to rfcs/0046-platform-support-tiers.md diff --git a/process/0051-mark-stale-issues.md b/rfcs/0051-mark-stale-issues.md similarity index 100% rename from process/0051-mark-stale-issues.md rename to rfcs/0051-mark-stale-issues.md diff --git a/feature/0052-dynamic-ids.md b/rfcs/0052-dynamic-ids.md similarity index 100% rename from feature/0052-dynamic-ids.md rename to rfcs/0052-dynamic-ids.md diff --git a/process/0055-retired-committers.md b/rfcs/0055-retired-committers.md similarity index 100% rename from process/0055-retired-committers.md rename to rfcs/0055-retired-committers.md diff --git a/process/0071-retired-committers-amendment.md b/rfcs/0071-retired-committers-amendment.md similarity index 100% rename from process/0071-retired-committers-amendment.md rename to rfcs/0071-retired-committers-amendment.md diff --git a/feature/0072-commonmark-docs.md b/rfcs/0072-commonmark-docs.md similarity index 100% rename from feature/0072-commonmark-docs.md rename to rfcs/0072-commonmark-docs.md diff --git a/informational/0080-nixos-release-schedule.md b/rfcs/0080-nixos-release-schedule.md similarity index 100% rename from informational/0080-nixos-release-schedule.md rename to rfcs/0080-nixos-release-schedule.md diff --git a/informational/0085-nixos-release-stablization.md b/rfcs/0085-nixos-release-stablization.md similarity index 100% rename from informational/0085-nixos-release-stablization.md rename to rfcs/0085-nixos-release-stablization.md diff --git a/process/0093-rfc-categories.md b/rfcs/0093-rfc-categories.md similarity index 100% rename from process/0093-rfc-categories.md rename to rfcs/0093-rfc-categories.md From e9bea2a6c0a0404056d4fac6de41a55ec9abb51e Mon Sep 17 00:00:00 2001 From: David Arnold Date: Wed, 21 Jul 2021 12:04:29 -0500 Subject: [PATCH 12/29] ... and use metadata instead as discussed in last shepherd meeting --- rfcs/0001-rfc-process.md | 1 + rfcs/0004-replace-unicode-quotes.md | 1 + rfcs/0015-release-manager.md | 1 + rfcs/0023-musl-libc.md | 1 + rfcs/0025-nix-core-team.md | 1 + rfcs/0026-staging-workflow.md | 1 + rfcs/0032-run-phase-changes-for-better-nix-shell-use.md | 1 + rfcs/0036-rfc-process-team-amendment.md | 1 + rfcs/0039-unprivileged-maintainer-teams.md | 1 + rfcs/0042-config-option.md | 1 + rfcs/0043-rfcsc-rotation.md | 1 + rfcs/0044-disband-nix-core.md | 1 + rfcs/0045-deprecate-url-syntax.md | 3 ++- rfcs/0046-platform-support-tiers.md | 1 + rfcs/0051-mark-stale-issues.md | 1 + rfcs/0052-dynamic-ids.md | 1 + rfcs/0055-retired-committers.md | 1 + rfcs/0071-retired-committers-amendment.md | 1 + rfcs/0072-commonmark-docs.md | 1 + rfcs/0080-nixos-release-schedule.md | 1 + rfcs/0085-nixos-release-stablization.md | 1 + rfcs/0093-rfc-categories.md | 1 + 22 files changed, 23 insertions(+), 1 deletion(-) diff --git a/rfcs/0001-rfc-process.md b/rfcs/0001-rfc-process.md index c554bd76b..38489209a 100644 --- a/rfcs/0001-rfc-process.md +++ b/rfcs/0001-rfc-process.md @@ -4,6 +4,7 @@ start-date: 2017-02-12 author: zimbatm co-authors: teh, MoreTea related-issues: https://github.com/zimbatm/rfcs/pull/2 +category: process --- # Summary diff --git a/rfcs/0004-replace-unicode-quotes.md b/rfcs/0004-replace-unicode-quotes.md index 87dca7e34..f64b0e8a3 100644 --- a/rfcs/0004-replace-unicode-quotes.md +++ b/rfcs/0004-replace-unicode-quotes.md @@ -7,6 +7,7 @@ related-issues: - https://github.com/NixOS/nix/pull/1140 - https://github.com/NixOS/nix/issues/915 - https://github.com/NixOS/nix/pull/910 +category: feature --- # Summary diff --git a/rfcs/0015-release-manager.md b/rfcs/0015-release-manager.md index 11b81c379..47900a28b 100644 --- a/rfcs/0015-release-manager.md +++ b/rfcs/0015-release-manager.md @@ -4,6 +4,7 @@ start-date: 2017-07-18 author: Robin Gloster (@globin) co-authors: Franz Pletz (@fpletz) related-issues: -- +category: process --- # Summary diff --git a/rfcs/0023-musl-libc.md b/rfcs/0023-musl-libc.md index d7e68511d..ebbe6167a 100644 --- a/rfcs/0023-musl-libc.md +++ b/rfcs/0023-musl-libc.md @@ -4,6 +4,7 @@ start-date: 2018-02-19 author: Will Dietz (@dtzWill) co-authors: Shea Levy (@shlevy) related-issues: 34645, 6221, ... +category: feature --- diff --git a/rfcs/0025-nix-core-team.md b/rfcs/0025-nix-core-team.md index c7cd73295..e3dc7b6a0 100644 --- a/rfcs/0025-nix-core-team.md +++ b/rfcs/0025-nix-core-team.md @@ -5,6 +5,7 @@ end-date: 2019-04-25 author: Graham Christensen co-authors: Daniel Peebles, Eelco Dolstra, Peter Simons, Shea Levy, Vladimír Čunát related-issues: #44 (disbands the team) +category: process --- # Superseded! diff --git a/rfcs/0026-staging-workflow.md b/rfcs/0026-staging-workflow.md index d4b336c81..41715e4e6 100644 --- a/rfcs/0026-staging-workflow.md +++ b/rfcs/0026-staging-workflow.md @@ -4,6 +4,7 @@ start-date: 2018-03-05 author: Vladimír Čunát (@vcunat) co-authors: Frederik Rietdijk (@FRidh) related-issues: +category: process --- # Summary diff --git a/rfcs/0032-run-phase-changes-for-better-nix-shell-use.md b/rfcs/0032-run-phase-changes-for-better-nix-shell-use.md index a5f821357..29ec559b4 100644 --- a/rfcs/0032-run-phase-changes-for-better-nix-shell-use.md +++ b/rfcs/0032-run-phase-changes-for-better-nix-shell-use.md @@ -6,6 +6,7 @@ co-authors: @dezgeg related-issues: https://github.com/dezgeg/nixpkgs/tree/better-run-phases shepherd-team: Samuel Dionne-Reil, John Ericson, Linus Heckemann shepherd-leader: Linus Heckemann +category: feature --- # Summary diff --git a/rfcs/0036-rfc-process-team-amendment.md b/rfcs/0036-rfc-process-team-amendment.md index 896219b30..2548eaac4 100644 --- a/rfcs/0036-rfc-process-team-amendment.md +++ b/rfcs/0036-rfc-process-team-amendment.md @@ -4,6 +4,7 @@ start-date: 2018-10-27 author: Robin Gloster co-authors: Graham Christensen related-issues: 1 (initial process), 38 (implementation) +category: process --- # Summary diff --git a/rfcs/0039-unprivileged-maintainer-teams.md b/rfcs/0039-unprivileged-maintainer-teams.md index bcdbb82cc..888167f10 100644 --- a/rfcs/0039-unprivileged-maintainer-teams.md +++ b/rfcs/0039-unprivileged-maintainer-teams.md @@ -4,6 +4,7 @@ start-date: 2019-01-16 author: Graham Christensen co-authors: zimbatm related-issues: https://github.com/NixOS/ofborg/pull/303 +category: process --- # Summary diff --git a/rfcs/0042-config-option.md b/rfcs/0042-config-option.md index ecefdcd68..989c4a641 100644 --- a/rfcs/0042-config-option.md +++ b/rfcs/0042-config-option.md @@ -6,6 +6,7 @@ co-authors: shepherd-leader: Jörg Thalheim shepherd-team: Jörg Thalheim, Eelco Dolstra, Robert Helgesson related-issues: https://github.com/NixOS/nixpkgs/pull/65728, https://github.com/NixOS/nixpkgs/pull/70138, https://github.com/NixOS/nixpkgs/pull/75584, TBD +category: feature --- # Summary diff --git a/rfcs/0043-rfcsc-rotation.md b/rfcs/0043-rfcsc-rotation.md index 0f3db37f5..3ef0a23cf 100644 --- a/rfcs/0043-rfcsc-rotation.md +++ b/rfcs/0043-rfcsc-rotation.md @@ -3,6 +3,7 @@ feature: rfcsc-rotation start-date: 2019-04-24 author: Robin Gloster , Simon Lackerbauer related-issues: 36 +category: process --- # Summary diff --git a/rfcs/0044-disband-nix-core.md b/rfcs/0044-disband-nix-core.md index be2700b83..2528117f6 100644 --- a/rfcs/0044-disband-nix-core.md +++ b/rfcs/0044-disband-nix-core.md @@ -4,6 +4,7 @@ start-date: 2019-04-25 author: Shea Levy co-authors: related-issues: NixOS/rfcs#25 +category: process --- # Summary diff --git a/rfcs/0045-deprecate-url-syntax.md b/rfcs/0045-deprecate-url-syntax.md index 78d12d411..4b74e0e8b 100644 --- a/rfcs/0045-deprecate-url-syntax.md +++ b/rfcs/0045-deprecate-url-syntax.md @@ -5,7 +5,8 @@ author: Michael Raskin co-authors: shepherd-leader: Eelco Dolstra shepherd-team: Eelco Dolstra, zimbatm, Silvan Mosberger -related-issues: +related-issues: +category: feature --- # Summary diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md index 59a02ea0c..25de02552 100644 --- a/rfcs/0046-platform-support-tiers.md +++ b/rfcs/0046-platform-support-tiers.md @@ -6,6 +6,7 @@ shepherd-team: Ryan Mulligan, Jonas Pfenniger, Graham Christensen, John Ericson shepherd-leader: John Ericson co-authors: Matthew Bauer related-issues: +category: feature --- # Summary diff --git a/rfcs/0051-mark-stale-issues.md b/rfcs/0051-mark-stale-issues.md index 6c3973cf3..36e126a19 100644 --- a/rfcs/0051-mark-stale-issues.md +++ b/rfcs/0051-mark-stale-issues.md @@ -6,6 +6,7 @@ co-authors: (find a buddy later to help our with the RFC) shepherd-team: @globin, @grahamc, and @peti shepherd-leader: @peti related-issues: (will contain links to implementation PRs) +category: process --- # Summary diff --git a/rfcs/0052-dynamic-ids.md b/rfcs/0052-dynamic-ids.md index 8b445bb2b..da3749c41 100644 --- a/rfcs/0052-dynamic-ids.md +++ b/rfcs/0052-dynamic-ids.md @@ -6,6 +6,7 @@ co-authors: shepherd-team: Arian van Putten, asymmetric, Eelco Dolstra, Jörg Thalheim, Ryan Mulligan shepherd-leader: Ryan Mulligan related-issues: https://github.com/NixOS/nixpkgs/pull/65698, https://github.com/NixOS/nixpkgs/pull/71055 +category: feature --- # Summary diff --git a/rfcs/0055-retired-committers.md b/rfcs/0055-retired-committers.md index 01e4157ad..b09d35932 100644 --- a/rfcs/0055-retired-committers.md +++ b/rfcs/0055-retired-committers.md @@ -6,6 +6,7 @@ co-authors: Graham Christensen shepherd-team: (names, to be nominated and accepted by RFC steering committee) shepherd-leader: (name to be appointed by RFC steering committee) related-issues: (will contain links to implementation PRs) +category: process --- # Summary diff --git a/rfcs/0071-retired-committers-amendment.md b/rfcs/0071-retired-committers-amendment.md index c90346587..8442d854b 100644 --- a/rfcs/0071-retired-committers-amendment.md +++ b/rfcs/0071-retired-committers-amendment.md @@ -6,6 +6,7 @@ co-authors: Graham Christensen (@grahamc), Jan Tojnar (@jtojnar) shepherd-team: @lheckemann, @tilpner, @alyssais shepherd-leader: @tilpner related-issues: 0055 +category: process --- # Summary diff --git a/rfcs/0072-commonmark-docs.md b/rfcs/0072-commonmark-docs.md index 087e32bb1..50dcec717 100644 --- a/rfcs/0072-commonmark-docs.md +++ b/rfcs/0072-commonmark-docs.md @@ -4,6 +4,7 @@ start-date: 2020-07-05 author: mboes shepherd-team: garbas, zimbatm, Kloenk shepherd-leader: Infinisil +category: feature --- # Summary diff --git a/rfcs/0080-nixos-release-schedule.md b/rfcs/0080-nixos-release-schedule.md index fd541d471..745009560 100644 --- a/rfcs/0080-nixos-release-schedule.md +++ b/rfcs/0080-nixos-release-schedule.md @@ -5,6 +5,7 @@ author: Jonathan Ringer (@jonringer) co-authors: Frederik Rietdijk (@FRidh) shepherd-team: @ryantm, @domenkozar and @garbas related-issues: +category: informational --- # Summary diff --git a/rfcs/0085-nixos-release-stablization.md b/rfcs/0085-nixos-release-stablization.md index 9b7d9219f..b6f3cf514 100644 --- a/rfcs/0085-nixos-release-stablization.md +++ b/rfcs/0085-nixos-release-stablization.md @@ -6,6 +6,7 @@ co-authors: shepherd-team: @ryantm, @garbas, @Mic92 shepherd-leader: @ryantm related-issues: [NixOS release schedule](https://github.com/NixOS/rfcs/pull/80) +category: informational --- # Summary diff --git a/rfcs/0093-rfc-categories.md b/rfcs/0093-rfc-categories.md index c1d31014e..95872edb7 100644 --- a/rfcs/0093-rfc-categories.md +++ b/rfcs/0093-rfc-categories.md @@ -6,6 +6,7 @@ co-authors: (find a buddy later to help out with the RFC) shepherd-team: @kevnicox, @Mic92, @gytis-ivaskevicius shepherd-leader: @kevincox related-issues: +category: process --- # Summary From d8172a6a3cfc6ab2be52df7a517c7b839fba2280 Mon Sep 17 00:00:00 2001 From: David Arnold Date: Wed, 21 Jul 2021 13:28:24 -0500 Subject: [PATCH 13/29] Exemplify and extend motivation ("more meat") --- rfcs/0093-rfc-categories.md | 36 ++++++++++++++++++++++++++++++++---- 1 file changed, 32 insertions(+), 4 deletions(-) diff --git a/rfcs/0093-rfc-categories.md b/rfcs/0093-rfc-categories.md index 95872edb7..e64aefb42 100644 --- a/rfcs/0093-rfc-categories.md +++ b/rfcs/0093-rfc-categories.md @@ -26,7 +26,7 @@ clear that it was made primarily with purely technical decisions in mind. It mig be a perception, but this perception systemically skews what's being discussed and what not. -As a result, important topics are not adressed and settled by the community at large +As a result, important topics might not be adressed and settled by the community at large in a generally accepted procedure. Specifically, it is hard to propose a well coordinated experiment across the community, @@ -34,22 +34,46 @@ document and acknowledge design issues, record proof-generated insight, but also amend the RFC process itself, the forum rules, the code of conduct or propose any other binding changes to community workflows or infrastructure. +**For example**, the [flake RFC](https://github.com/NixOS/rfcs/pull/49), which by many is +considered a failed RFC process, might have benefited from a framework to transition into +a general experiment in the form of an _informational_ RFC as soon as it had become +clear that it won't be accepted as a _feature_ RFC. Its subsequent closure has rendered +the entire flake experiment to a largely undocumented, unstructured, and intransparent +process that still elicites strong opinions within the community. Clarity over RFC options +and venues _might_ have helped mitigate this situation. + ## Some issues are not addressed from the appropriate angle Even if, in the past, people might have used the RFC Process to gather broader consensus around some of those hard-to-propose topics, the ensuing discussion still might have been -framed in a way that is not best suited. This actually starts with the sctructure of the +framed in a way that is not best suited. This actually starts with the structure of the template. By explicitly categorizing RFCs, it will be immediatly evident for participants that those RFCs are a) legitimate and b) require an evaluation within the fair boundaries of their categories. +**For example**, [RFC31](https://github.com/NixOS/rfcs/pull/31), a feature RFC, then was +closed and superseded by [RFC46](https://github.com/NixOS/rfcs/pull/46), which ended up +being an informational RFC with certain inclination towards a process RFC, that was accepted. +RFC46 is a prime example of the usefulness of "documenting language", as the RFC relates to +its purpose. Having an explicit categorization is expected to suggest making use of these +venues to a broder RFC author base. + +## Add structure to an increasingly used RFC process + +As the RFC process will be more widely used by a growing community, it becomes necesary to +structure and differentiate the process further to remain as efficient and accessible as +possible. Adding a category metadata and differentiate the templates will help to better +accomodate the multiple aspects that might require a "Request For Comment" from the broader +community. It is expected that we identify more useful categories and nuances to the process +as its usage increases. + # Detailed design [design]: #detailed-design Every RFC that is eligible for the RFC process is classified by its author into the -_information_, _process_ or _feature_ category. For each category a different template +_informational_, _process_ or _feature_ category. For each category a different template is made available. How those categories are defined in every detail can remain subjective, but the following should give a sufficient idea: @@ -57,7 +81,7 @@ subjective, but the following should give a sufficient idea: - Start a talk, meetup, or social networking account that will be expected to officially “represent nix” - Document design issues, deciding to never implement a feature - Proposing an experiment - - Recording a proof-generated insight + - Recording a proof-generated insight - Process RFCs - Change the RFC process, the organization of the issue tracker or the support forum - Changes to community workflows or other community infrastructure @@ -66,6 +90,10 @@ subjective, but the following should give a sufficient idea: - Anything that is currently covered by the RFC process and does not better fit into any of the other two categories. +Authors are advised to choose the most prevalent category for their classification. For +example, if an informational RFC requires some changes to the community infrastructure, +but still mainly proposes an experiment, it would go into the "informationl" category. + This RFC is accompanied by commits that implement it. Please refer to them for the detailed design. From bca690e28a944044933bdd5abc87ea42613f29d1 Mon Sep 17 00:00:00 2001 From: David Arnold Date: Wed, 21 Jul 2021 13:34:10 -0500 Subject: [PATCH 14/29] Update templates & clarify "stakeholder" --- 0000-template-feature.md | 1 + 0000-template-informational.md | 1 + 0000-template-process.md | 11 +++++++++-- 3 files changed, 11 insertions(+), 2 deletions(-) diff --git a/0000-template-feature.md b/0000-template-feature.md index 93bd71aa3..1b2464b7e 100644 --- a/0000-template-feature.md +++ b/0000-template-feature.md @@ -6,6 +6,7 @@ co-authors: (find a buddy later to help out with the RFC) shepherd-team: (names, to be nominated and accepted by RFC steering committee) shepherd-leader: (name to be appointed by RFC steering committee) related-issues: (will contain links to implementation PRs) +category: feature --- # Roles & Stakeholders - +costs imposed (mostly in time, can be negative) to the community. + +Typical stakeholders involve: maintainers, end users, corporate users +--> # Pros & Cons [evaluation]: #pros-and-cons From 3017cb6a62964a82dbb8d6ea1d4dec4f4780fc87 Mon Sep 17 00:00:00 2001 From: David Arnold Date: Wed, 21 Jul 2021 13:34:27 -0500 Subject: [PATCH 15/29] fix RFC46 categorization after having a closer look --- rfcs/0046-platform-support-tiers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md index 25de02552..67fd5ef57 100644 --- a/rfcs/0046-platform-support-tiers.md +++ b/rfcs/0046-platform-support-tiers.md @@ -6,7 +6,7 @@ shepherd-team: Ryan Mulligan, Jonas Pfenniger, Graham Christensen, John Ericson shepherd-leader: John Ericson co-authors: Matthew Bauer related-issues: -category: feature +category: informational --- # Summary From 0a7063ae85e6378ae92d417d57149133006edd47 Mon Sep 17 00:00:00 2001 From: David Arnold Date: Wed, 21 Jul 2021 13:43:54 -0500 Subject: [PATCH 16/29] Examples & Interactions wording --- rfcs/0093-rfc-categories.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/rfcs/0093-rfc-categories.md b/rfcs/0093-rfc-categories.md index e64aefb42..0fae96a34 100644 --- a/rfcs/0093-rfc-categories.md +++ b/rfcs/0093-rfc-categories.md @@ -100,11 +100,10 @@ design. # Examples and Interactions [examples-and-interactions]: #examples-and-interactions -The relevant examples and interactions are already exposed in the motivation section. +The relevant examples and interactions are exposed in the motivation section. The detailed design does not require further exemplification, since it is intended to be -an authors personal best judgment without significant backlash on the categorization -that drives the categorization, not a specific set of criteria. I don't think its -feasible to develop such fixed set of criteria herein in a meaningful way. +an authors personal best judgment that drives the categorization, not a specific set of criteria. +I don't think its feasible to develop such fixed set of criteria herein in a meaningful way. # Drawbacks [drawbacks]: #drawbacks From 9861b53b8fceaea11f6f63583056a7973516660f Mon Sep 17 00:00:00 2001 From: David Arnold Date: Wed, 21 Jul 2021 14:30:36 -0500 Subject: [PATCH 17/29] Update 0000-template-informational.md Co-authored-by: asymmetric --- 0000-template-informational.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/0000-template-informational.md b/0000-template-informational.md index dd2913bd1..c2625443b 100644 --- a/0000-template-informational.md +++ b/0000-template-informational.md @@ -33,4 +33,4 @@ In order to address "X", I/we propose to "Y". # My Structure +judgement for your particular case. --> From defa62de816cb66bf9d71891c4596b03befb9f27 Mon Sep 17 00:00:00 2001 From: David Arnold Date: Wed, 21 Jul 2021 14:31:31 -0500 Subject: [PATCH 18/29] Update 0000-template-process.md Co-authored-by: asymmetric --- 0000-template-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/0000-template-process.md b/0000-template-process.md index ab563a71b..39ac3dd83 100644 --- a/0000-template-process.md +++ b/0000-template-process.md @@ -89,7 +89,7 @@ Typical stakeholders involve: maintainers, end users, corporate users # Conclusion [conclusion]: #conclusion - # Updates From 5a91b5f49d37db19e7d2f0543da1c7a8d2f3b3f3 Mon Sep 17 00:00:00 2001 From: David Arnold Date: Wed, 21 Jul 2021 14:32:57 -0500 Subject: [PATCH 19/29] Update README.md Co-authored-by: asymmetric --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index aab441fcc..fee3742f7 100644 --- a/README.md +++ b/README.md @@ -164,7 +164,7 @@ with the goal of eventual inclusion into Nix, Nixpkgs or the Ecosystem. ### Tips -###### Create Prototypes +#### Create Prototypes In case your RFC is a technical proposal, you might want to prepare a prototype of your idea to firstly make yourself aware of potential pitfalls and also help reviewers understand the RFC. Code may be able to explain some From f6b1f0e12eca3ab3f9b6724a8d6bdc0a126ef999 Mon Sep 17 00:00:00 2001 From: David Arnold Date: Mon, 26 Jul 2021 10:16:01 -0500 Subject: [PATCH 20/29] fix: wordings Co-authored-by: Kevin Cox --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index fee3742f7..16da4e97c 100644 --- a/README.md +++ b/README.md @@ -86,7 +86,7 @@ after the FCP. ##### RFC Categories In order to do do justice to the different aspects of documents that merit generation of broad community consensus via the RFC process, we classify each -RFC into _feature_, _process_ and _informational_ RFCs. All follow the same +RFC as _feature_, _process_ or _informational_. All follow the same high-level process as described above, but each category requires a different "mode of discussion", templates, criteria and judgment that it is beneficial to the overall RFC process to identify those categories explicitly. From c5817cd0053d9493f29739c86e8c782abab958e9 Mon Sep 17 00:00:00 2001 From: David Arnold Date: Mon, 26 Jul 2021 10:35:40 -0500 Subject: [PATCH 21/29] fix: wordings Co-authored-by: Kevin Cox --- rfcs/0093-rfc-categories.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0093-rfc-categories.md b/rfcs/0093-rfc-categories.md index 0fae96a34..46100a4cc 100644 --- a/rfcs/0093-rfc-categories.md +++ b/rfcs/0093-rfc-categories.md @@ -38,7 +38,7 @@ binding changes to community workflows or infrastructure. considered a failed RFC process, might have benefited from a framework to transition into a general experiment in the form of an _informational_ RFC as soon as it had become clear that it won't be accepted as a _feature_ RFC. Its subsequent closure has rendered -the entire flake experiment to a largely undocumented, unstructured, and intransparent +the entire flake experiment to a largely undocumented, unstructured, and opaque process that still elicites strong opinions within the community. Clarity over RFC options and venues _might_ have helped mitigate this situation. From 9649d54c1f61108ed64215457db0357994e0038c Mon Sep 17 00:00:00 2001 From: David Arnold Date: Mon, 26 Jul 2021 10:36:32 -0500 Subject: [PATCH 22/29] fixup: typo Co-authored-by: Kevin Cox --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 16da4e97c..aaa499ee8 100644 --- a/README.md +++ b/README.md @@ -195,7 +195,7 @@ completion: authors should not expect that other project developers will take on responsibility for implementing their accepted feature. Minor modifications to accepted RFCs can be done in follow-up pull requests. We -strive to write each RFC in a manner that it will reflect the final state of +strive to write each RFC in a manner that it will reflect the final state of the world; but the nature of the process means that we cannot expect every merged RFC to actually reflect what the end result will be after implementation. From e817588ad644c95e2b90b11f6e4864e07b99a611 Mon Sep 17 00:00:00 2001 From: David Arnold Date: Mon, 26 Jul 2021 10:37:12 -0500 Subject: [PATCH 23/29] fix: wordings Co-authored-by: Kevin Cox --- rfcs/0093-rfc-categories.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0093-rfc-categories.md b/rfcs/0093-rfc-categories.md index 46100a4cc..a2f013742 100644 --- a/rfcs/0093-rfc-categories.md +++ b/rfcs/0093-rfc-categories.md @@ -13,7 +13,7 @@ category: process [summary]: #summary The RFC process is amended with means to categorize RFCs into one of: _feature_, -_information_ or _process_, where each category sets different accents that +_information_ or _process_, where each category sets different expectations for reviewers that improve the overall outcome of the process. # Motivation From 91a7376f849ffe3f740077945423f23c8aef103e Mon Sep 17 00:00:00 2001 From: David Arnold Date: Mon, 26 Jul 2021 10:37:45 -0500 Subject: [PATCH 24/29] fix: wordings Co-authored-by: Kevin Cox --- rfcs/0093-rfc-categories.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0093-rfc-categories.md b/rfcs/0093-rfc-categories.md index a2f013742..db8015c29 100644 --- a/rfcs/0093-rfc-categories.md +++ b/rfcs/0093-rfc-categories.md @@ -22,7 +22,7 @@ improve the overall outcome of the process. ## Some issues are not addressed by the community There is no appropriate venue for it. When reading the current RFC process, it becomes -clear that it was made primarily with purely technical decisions in mind. It might only +clear that it was made primarily for technical decisions. It might only be a perception, but this perception systemically skews what's being discussed and what not. From dee0b8174d744185095ddd55075327510891921b Mon Sep 17 00:00:00 2001 From: David Arnold Date: Mon, 26 Jul 2021 10:38:29 -0500 Subject: [PATCH 25/29] fix: wordings Co-authored-by: Kevin Cox --- rfcs/0093-rfc-categories.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0093-rfc-categories.md b/rfcs/0093-rfc-categories.md index db8015c29..2e5600647 100644 --- a/rfcs/0093-rfc-categories.md +++ b/rfcs/0093-rfc-categories.md @@ -12,7 +12,7 @@ category: process # Summary [summary]: #summary -The RFC process is amended with means to categorize RFCs into one of: _feature_, +The RFC process is amended to categorize RFCs into one of: _feature_, _information_ or _process_, where each category sets different expectations for reviewers that improve the overall outcome of the process. From 51456893e13f5729e8dd9187307ff4255c78e309 Mon Sep 17 00:00:00 2001 From: David Arnold Date: Sun, 29 Aug 2021 19:15:43 -0500 Subject: [PATCH 26/29] Revert readme related changes --- README.md | 89 +++++++++++++++++++++---------------------------------- 1 file changed, 33 insertions(+), 56 deletions(-) diff --git a/README.md b/README.md index aaa499ee8..892e23595 100644 --- a/README.md +++ b/README.md @@ -1,15 +1,15 @@ # Nix RFCs (Request For Comments) -Many ideas, including bug fixes and documentation improvements can be +Many changes, including bug fixes and documentation improvements can be implemented and reviewed via the normal GitHub pull request workflow. -Some ideas though are "substantial", and we ask that these be put through a -bit of a public process and produce a consensus among the Nix community. +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. ## When this process is followed -This process is followed when one intends to apply "substantial" ideas to the -Nix ecosystem. What constitutes a "substantial" idea is evolving based on +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. * Any semantic or syntactic change to the language that is not a bug fix @@ -17,23 +17,13 @@ community norms, but may include the following. * Big restructuring of Nixpkgs * Expansions to the scope of Nixpkgs (new arch, major subprojects, ...) * Introduction of new interfaces or functions -* Making changes to important of formalised community processes -* Record important proof-generated insights that affect the whole community -* Propose an important experiment that affects the whole community -* Document important design issues that affect the whole community -* Start a talk/account/etc. that "officially represents the nix community" Certain changes do not require an RFC: * Adding, updating and removing packages in Nixpkgs * Fixing security updates and bugs that don't break interfaces -* Starting any talk/account/etc. that does not officially represent nix -* Making process changes to (language) sub-systems without being relevant - to the community as a whole -* Conducting experiments, recording insights or documenting design issues in - (language) sub-systems that don't affect the community as a whole. -Pull requests that contain any of the aforementioned 'substantial' ideas may +Pull requests that contain any of the aforementioned 'substantial' changes may be closed if there is no RFC connected to the proposed changes. ## Terminology @@ -83,28 +73,28 @@ the RFC has received ample discussion and enough of the tradeoffs have been discussed. The Shepherd Team will propose to either accept or reject the RFC after the FCP. -##### RFC Categories -In order to do do justice to the different aspects of documents that merit -generation of broad community consensus via the RFC process, we classify each -RFC as _feature_, _process_ or _informational_. All follow the same -high-level process as described above, but each category requires a different -"mode of discussion", templates, criteria and judgment that it is beneficial -to the overall RFC process to identify those categories explicitly. - ## Process from Creation to Merge -*In short, to get a major change included in Nix, Nixpkgs or the ecosystem, one must +*In short, to get a major change included in Nix or Nixpkgs, one must first get the RFC merged into the RFC repository as a markdown file under the -corresponding directory. At that point the RFC is accepted and may be implemented -with the goal of eventual inclusion into Nix, Nixpkgs or the Ecosystem. - -0. Have a cool idea or an important information! -1. Identify its category: _feature_, _process_ or _informational_. -2. Start with the correct template and follow the instructions and comments. +`rfcs` directory. At that point the RFC is accepted and may be implemented +with the goal of eventual inclusion into Nix or Nixpkgs.* + +0. Have a cool idea! +1. Fill in the RFC. Put care into the details: RFCs that do not present + convincing motivation, demonstrate understanding of the impact of the design, + or are disingenuous about the drawbacks or alternatives tend to be + poorly-received. You might want to create a PR in your fork of the RFCs + repository to help you flesh it out with a few supporters or chat/video + conference with a few people involved in the topic of the RFC. +2. In case your RFC is a technical proposal, you might want to prepare a + prototype of your idea to firstly make yourself aware of potential pitfalls + and also help reviewers understand the RFC. Code may be able to explain some + issues in short. 3. Submit a pull request. As a pull request the RFC will receive design feedback from the larger community, and the author should be prepared to revise it in - response. Leave them in draft while you're still actively working on them. + response. 4. For the nomination process for potential members of the RFC Shepherd Team, that is specific to each RFC, anyone interested can either nominate another person or themselves to be a potential member of the RFC Shepherd Team. This @@ -162,41 +152,28 @@ with the goal of eventual inclusion into Nix, Nixpkgs or the Ecosystem. ![RFC Process](./rfcs/0036-rfc-process.png) ![Review Process](./rfcs/0036-review-process.png) -### Tips - -#### Create Prototypes -In case your RFC is a technical proposal, you might want to prepare a -prototype of your idea to firstly make yourself aware of potential pitfalls -and also help reviewers understand the RFC. Code may be able to explain some -issues in short. - -###### Motivation First -In any case, it can be a good idea to elaborate the motivation first, while -leaving the PR in draft. This helps to ensure, that when the solution is -discussed in the future, interested participants can have a clear and refined -picture of the problem that you try to address. ## The RFC life-cycle -Once an RFC is accepted the authors may implement it and for example submit the -feature as a pull request to the Nix or Nixpkgs repo. Being accepted 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. In general though this means that -the implementation will be merged as long as there are no substantial technical +Once an RFC is accepted the authors may implement it and submit the feature as a +pull request to the Nix or Nixpkgs repo. Being accepted 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. In general though this means that the +implementation will be merged as long as there are no substantial technical objections to the implementation. Furthermore, the fact that a given RFC has been accepted implies nothing about what priority is assigned to its implementation, nor does it imply anything -about whether a Nix/Nixpkgs community member has been assigned the task of -implementing the RFC. While it is not necessary that the author of the RFC also -does the implementation, it is by far the most effective way to see an RFC through to +about whether a Nix/Nixpkgs developer has been assigned the task of implementing +the feature. While it is not necessary that the author of the RFC also write the +implementation, it is by far the most effective way to see an RFC through to completion: authors should not expect that other project developers will take on responsibility for implementing their accepted feature. Minor modifications to accepted RFCs can be done in follow-up pull requests. We -strive to write each RFC in a manner that it will reflect the final state of -the world; but the nature of the process means that we cannot expect every +strive to write each RFC in a manner that it will reflect the final design of +the feature; but the nature of the process means that we cannot expect every merged RFC to actually reflect what the end result will be after implementation. In general, once accepted, RFCs should not be substantially changed. Only very From 2268ea8512d3f492e2ab4123ba5a4368060e0fb6 Mon Sep 17 00:00:00 2001 From: David Arnold Date: Sun, 29 Aug 2021 19:24:29 -0500 Subject: [PATCH 27/29] Re-add related readme changes --- README.md | 51 ++++++++++++++++++++++++++++----------------------- 1 file changed, 28 insertions(+), 23 deletions(-) diff --git a/README.md b/README.md index 892e23595..f4fd30fdb 100644 --- a/README.md +++ b/README.md @@ -1,10 +1,10 @@ # Nix RFCs (Request For Comments) -Many changes, including bug fixes and documentation improvements can be +Many ideas, 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. +Some ideas though are "substantial", and we ask that these be put through a +bit of a public process and produce a consensus among the Nix community. ## When this process is followed @@ -17,13 +17,18 @@ community norms, but may include the following. * Big restructuring of Nixpkgs * Expansions to the scope of Nixpkgs (new arch, major subprojects, ...) * Introduction of new interfaces or functions +* Making changes to important of formalised community processes +* Record important proof-generated insights that affect the whole community +* Propose an important experiment that affects the whole community +* Document important design issues that affect the whole community +* Start a talk/account/etc. that "officially represents the nix community" Certain changes do not require an RFC: * Adding, updating and removing packages in Nixpkgs * Fixing security updates and bugs that don't break interfaces -Pull requests that contain any of the aforementioned 'substantial' changes may +Pull requests that contain any of the aforementioned 'substantial' ideas may be closed if there is no RFC connected to the proposed changes. ## Terminology @@ -73,25 +78,25 @@ the RFC has received ample discussion and enough of the tradeoffs have been discussed. The Shepherd Team will propose to either accept or reject the RFC after the FCP. +##### RFC Categories +In order to do do justice to the different aspects of documents that merit +generation of broad community consensus via the RFC process, we classify each +RFC as _feature_, _process_ or _informational_. All follow the same +high-level process as described above, but each category requires a different +"mode of discussion", templates, criteria and judgment that it is beneficial +to the overall RFC process to identify those categories explicitly. + ## Process from Creation to Merge -*In short, to get a major change included in Nix or Nixpkgs, one must +*In short, to get a major change included in Nix, Nixpkgs or the ecosystem, one must first get the RFC merged into the RFC repository as a markdown file under the `rfcs` directory. At that point the RFC is accepted and may be implemented -with the goal of eventual inclusion into Nix or Nixpkgs.* - -0. Have a cool idea! -1. Fill in the RFC. Put care into the details: RFCs that do not present - convincing motivation, demonstrate understanding of the impact of the design, - or are disingenuous about the drawbacks or alternatives tend to be - poorly-received. You might want to create a PR in your fork of the RFCs - repository to help you flesh it out with a few supporters or chat/video - conference with a few people involved in the topic of the RFC. -2. In case your RFC is a technical proposal, you might want to prepare a - prototype of your idea to firstly make yourself aware of potential pitfalls - and also help reviewers understand the RFC. Code may be able to explain some - issues in short. +with the goal of eventual inclusion into Nix, Nixpkgs or the Ecosystem. + +0. Have a cool idea or an important information! +1. Identify its category: _feature_, _process_ or _informational_. +2. Start with the correct template and follow the instructions and comments. 3. Submit a pull request. As a pull request the RFC will receive design feedback from the larger community, and the author should be prepared to revise it in response. @@ -165,15 +170,15 @@ objections to the implementation. Furthermore, the fact that a given RFC has been accepted implies nothing about what priority is assigned to its implementation, nor does it imply anything -about whether a Nix/Nixpkgs developer has been assigned the task of implementing -the feature. While it is not necessary that the author of the RFC also write the -implementation, it is by far the most effective way to see an RFC through to +about whether a Nix/Nixpkgs community member has been assigned the task of +implementing the RFC. While it is not necessary that the author of the RFC also +does the implementation, it is by far the most effective way to see an RFC through to completion: authors should not expect that other project developers will take on responsibility for implementing their accepted feature. Minor modifications to accepted RFCs can be done in follow-up pull requests. We -strive to write each RFC in a manner that it will reflect the final design of -the feature; but the nature of the process means that we cannot expect every +strive to write each RFC in a manner that it will reflect the final state of +the world; but the nature of the process means that we cannot expect every merged RFC to actually reflect what the end result will be after implementation. In general, once accepted, RFCs should not be substantially changed. Only very From 6ed720b0ada5992b8eeb74d691075836e7a858a2 Mon Sep 17 00:00:00 2001 From: David Arnold Date: Sun, 29 Aug 2021 19:26:48 -0500 Subject: [PATCH 28/29] Fix metadata --- 0000-template-feature.md | 2 +- 0000-template-informational.md | 2 +- 0000-template-process.md | 2 +- rfcs/0001-rfc-process.md | 2 +- rfcs/0004-replace-unicode-quotes.md | 2 +- rfcs/0015-release-manager.md | 2 +- rfcs/0023-musl-libc.md | 2 +- rfcs/0025-nix-core-team.md | 2 +- rfcs/0026-staging-workflow.md | 2 +- rfcs/0032-run-phase-changes-for-better-nix-shell-use.md | 2 +- rfcs/0036-rfc-process-team-amendment.md | 2 +- rfcs/0039-unprivileged-maintainer-teams.md | 2 +- rfcs/0042-config-option.md | 2 +- rfcs/0043-rfcsc-rotation.md | 2 +- rfcs/0044-disband-nix-core.md | 2 +- rfcs/0045-deprecate-url-syntax.md | 2 +- rfcs/0046-platform-support-tiers.md | 2 +- rfcs/0051-mark-stale-issues.md | 2 +- rfcs/0052-dynamic-ids.md | 2 +- rfcs/0055-retired-committers.md | 2 +- rfcs/0071-retired-committers-amendment.md | 2 +- rfcs/0072-commonmark-docs.md | 2 +- rfcs/0080-nixos-release-schedule.md | 2 +- rfcs/0085-nixos-release-stablization.md | 2 +- rfcs/0093-rfc-categories.md | 2 +- 25 files changed, 25 insertions(+), 25 deletions(-) diff --git a/0000-template-feature.md b/0000-template-feature.md index 1b2464b7e..c4909879b 100644 --- a/0000-template-feature.md +++ b/0000-template-feature.md @@ -1,5 +1,5 @@ --- -feature: (fill me in with a unique ident, my_awesome_feature) +identifier: (fill me in with a unique ident, my_awesome_feature) start-date: (fill me in with today's date, YYYY-MM-DD) author: (name of the main author) co-authors: (find a buddy later to help out with the RFC) diff --git a/0000-template-informational.md b/0000-template-informational.md index c2625443b..34ff6e4ff 100644 --- a/0000-template-informational.md +++ b/0000-template-informational.md @@ -1,5 +1,5 @@ --- -information: (fill me in with a unique ident, my_new_fact) +identifier: (fill me in with a unique ident, my_new_fact) start-date: (fill me in with today's date, YYYY-MM-DD) author: (name of the main author) co-authors: (find a buddy later to help out with the RFC) diff --git a/0000-template-process.md b/0000-template-process.md index 39ac3dd83..fd6f7e552 100644 --- a/0000-template-process.md +++ b/0000-template-process.md @@ -1,5 +1,5 @@ --- -process: (fill me in with a unique ident, my_new_process) +identifier: (fill me in with a unique ident, my_new_process) start-date: (fill me in with today's date, YYYY-MM-DD) author: (name of the main author) co-authors: (find a buddy later to help out with the RFC) diff --git a/rfcs/0001-rfc-process.md b/rfcs/0001-rfc-process.md index 38489209a..8f8fca9b1 100644 --- a/rfcs/0001-rfc-process.md +++ b/rfcs/0001-rfc-process.md @@ -1,5 +1,5 @@ --- -feature: rfc-process +identifier: rfc-process start-date: 2017-02-12 author: zimbatm co-authors: teh, MoreTea diff --git a/rfcs/0004-replace-unicode-quotes.md b/rfcs/0004-replace-unicode-quotes.md index f64b0e8a3..a999983ba 100644 --- a/rfcs/0004-replace-unicode-quotes.md +++ b/rfcs/0004-replace-unicode-quotes.md @@ -1,5 +1,5 @@ --- -feature: replace-unicode-quotes +identifier: replace-unicode-quotes start-date: 2017-03-19 author: layus co-authors: zimbatm diff --git a/rfcs/0015-release-manager.md b/rfcs/0015-release-manager.md index 47900a28b..20fb93d67 100644 --- a/rfcs/0015-release-manager.md +++ b/rfcs/0015-release-manager.md @@ -1,5 +1,5 @@ --- -feature: release-manager-nixos +identifier: release-manager-nixos start-date: 2017-07-18 author: Robin Gloster (@globin) co-authors: Franz Pletz (@fpletz) diff --git a/rfcs/0023-musl-libc.md b/rfcs/0023-musl-libc.md index ebbe6167a..9d042129b 100644 --- a/rfcs/0023-musl-libc.md +++ b/rfcs/0023-musl-libc.md @@ -1,5 +1,5 @@ --- -feature: musl-libc +identifier: musl-libc start-date: 2018-02-19 author: Will Dietz (@dtzWill) co-authors: Shea Levy (@shlevy) diff --git a/rfcs/0025-nix-core-team.md b/rfcs/0025-nix-core-team.md index e3dc7b6a0..a8bf3c271 100644 --- a/rfcs/0025-nix-core-team.md +++ b/rfcs/0025-nix-core-team.md @@ -1,5 +1,5 @@ --- -feature: nix-core-team +identifier: nix-core-team start-date: 2018-01-31 end-date: 2019-04-25 author: Graham Christensen diff --git a/rfcs/0026-staging-workflow.md b/rfcs/0026-staging-workflow.md index 41715e4e6..3b68e059c 100644 --- a/rfcs/0026-staging-workflow.md +++ b/rfcs/0026-staging-workflow.md @@ -1,5 +1,5 @@ --- -feature: staging-workflow +identifier: staging-workflow start-date: 2018-03-05 author: Vladimír Čunát (@vcunat) co-authors: Frederik Rietdijk (@FRidh) diff --git a/rfcs/0032-run-phase-changes-for-better-nix-shell-use.md b/rfcs/0032-run-phase-changes-for-better-nix-shell-use.md index 29ec559b4..a8def8d79 100644 --- a/rfcs/0032-run-phase-changes-for-better-nix-shell-use.md +++ b/rfcs/0032-run-phase-changes-for-better-nix-shell-use.md @@ -1,5 +1,5 @@ --- -feature: run-phase-changes-for-better-nix-shell-use +identifier: run-phase-changes-for-better-nix-shell-use start-date: 2018-08-26 author: @globin co-authors: @dezgeg diff --git a/rfcs/0036-rfc-process-team-amendment.md b/rfcs/0036-rfc-process-team-amendment.md index 2548eaac4..ed7153044 100644 --- a/rfcs/0036-rfc-process-team-amendment.md +++ b/rfcs/0036-rfc-process-team-amendment.md @@ -1,5 +1,5 @@ --- -feature: rfc-process-team-amendment +identifier: rfc-process-team-amendment start-date: 2018-10-27 author: Robin Gloster co-authors: Graham Christensen diff --git a/rfcs/0039-unprivileged-maintainer-teams.md b/rfcs/0039-unprivileged-maintainer-teams.md index 888167f10..dbc4052f5 100644 --- a/rfcs/0039-unprivileged-maintainer-teams.md +++ b/rfcs/0039-unprivileged-maintainer-teams.md @@ -1,5 +1,5 @@ --- -feature: unprivileged-maintainer-teams +identifier: unprivileged-maintainer-teams start-date: 2019-01-16 author: Graham Christensen co-authors: zimbatm diff --git a/rfcs/0042-config-option.md b/rfcs/0042-config-option.md index 989c4a641..0735c2735 100644 --- a/rfcs/0042-config-option.md +++ b/rfcs/0042-config-option.md @@ -1,5 +1,5 @@ --- -feature: config-option +identifier: config-option start-date: 2019-03-10 author: Silvan Mosberger co-authors: diff --git a/rfcs/0043-rfcsc-rotation.md b/rfcs/0043-rfcsc-rotation.md index 3ef0a23cf..c13df1d1d 100644 --- a/rfcs/0043-rfcsc-rotation.md +++ b/rfcs/0043-rfcsc-rotation.md @@ -1,5 +1,5 @@ --- -feature: rfcsc-rotation +identifier: rfcsc-rotation start-date: 2019-04-24 author: Robin Gloster , Simon Lackerbauer related-issues: 36 diff --git a/rfcs/0044-disband-nix-core.md b/rfcs/0044-disband-nix-core.md index 2528117f6..0f011c755 100644 --- a/rfcs/0044-disband-nix-core.md +++ b/rfcs/0044-disband-nix-core.md @@ -1,5 +1,5 @@ --- -feature: disband-nix-core +identifier: disband-nix-core start-date: 2019-04-25 author: Shea Levy co-authors: diff --git a/rfcs/0045-deprecate-url-syntax.md b/rfcs/0045-deprecate-url-syntax.md index 4b74e0e8b..482271a5a 100644 --- a/rfcs/0045-deprecate-url-syntax.md +++ b/rfcs/0045-deprecate-url-syntax.md @@ -1,5 +1,5 @@ --- -feature: deprecate_url_syntax +identifier: deprecate_url_syntax start-date: 2019-04-28 author: Michael Raskin co-authors: diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md index 67fd5ef57..1669fa465 100644 --- a/rfcs/0046-platform-support-tiers.md +++ b/rfcs/0046-platform-support-tiers.md @@ -1,5 +1,5 @@ --- -feature: platform_support_tiers +identifier: platform_support_tiers start-date: 2019-04-28 author: Michael Raskin shepherd-team: Ryan Mulligan, Jonas Pfenniger, Graham Christensen, John Ericson diff --git a/rfcs/0051-mark-stale-issues.md b/rfcs/0051-mark-stale-issues.md index 36e126a19..0e917085d 100644 --- a/rfcs/0051-mark-stale-issues.md +++ b/rfcs/0051-mark-stale-issues.md @@ -1,5 +1,5 @@ --- -feature: mark-stale-issues +identifier: mark-stale-issues start-date: 2019-08-24 author: Ryan Mulligan co-authors: (find a buddy later to help our with the RFC) diff --git a/rfcs/0052-dynamic-ids.md b/rfcs/0052-dynamic-ids.md index da3749c41..0178e9550 100644 --- a/rfcs/0052-dynamic-ids.md +++ b/rfcs/0052-dynamic-ids.md @@ -1,5 +1,5 @@ --- -feature: dynamic-ids +identifier: dynamic-ids start-date: 2019-09-05 author: Silvan Mosberger co-authors: diff --git a/rfcs/0055-retired-committers.md b/rfcs/0055-retired-committers.md index b09d35932..e4a6f74d6 100644 --- a/rfcs/0055-retired-committers.md +++ b/rfcs/0055-retired-committers.md @@ -1,5 +1,5 @@ --- -feature: retired-committers +identifier: retired-committers start-date: 2019-08-25 author: Till Höppner co-authors: Graham Christensen diff --git a/rfcs/0071-retired-committers-amendment.md b/rfcs/0071-retired-committers-amendment.md index 8442d854b..c25fe0d27 100644 --- a/rfcs/0071-retired-committers-amendment.md +++ b/rfcs/0071-retired-committers-amendment.md @@ -1,5 +1,5 @@ --- -feature: retired-committers-amendment +identifier: retired-committers-amendment start-date: 2020-07-09 author: worldofpeace co-authors: Graham Christensen (@grahamc), Jan Tojnar (@jtojnar) diff --git a/rfcs/0072-commonmark-docs.md b/rfcs/0072-commonmark-docs.md index 50dcec717..4c38d5c7c 100644 --- a/rfcs/0072-commonmark-docs.md +++ b/rfcs/0072-commonmark-docs.md @@ -1,5 +1,5 @@ --- -feature: commonmark-docs +identifier: commonmark-docs start-date: 2020-07-05 author: mboes shepherd-team: garbas, zimbatm, Kloenk diff --git a/rfcs/0080-nixos-release-schedule.md b/rfcs/0080-nixos-release-schedule.md index 745009560..d786d1e04 100644 --- a/rfcs/0080-nixos-release-schedule.md +++ b/rfcs/0080-nixos-release-schedule.md @@ -1,5 +1,5 @@ --- -feature: nixos-release-schedule +identifier: nixos-release-schedule start-date: 2020-11-28 author: Jonathan Ringer (@jonringer) co-authors: Frederik Rietdijk (@FRidh) diff --git a/rfcs/0085-nixos-release-stablization.md b/rfcs/0085-nixos-release-stablization.md index b6f3cf514..caa7e31f0 100644 --- a/rfcs/0085-nixos-release-stablization.md +++ b/rfcs/0085-nixos-release-stablization.md @@ -1,5 +1,5 @@ --- -feature: nixos-release-stablization +identifier: nixos-release-stablization start-date: 2021-01-17 author: Jonathan Ringer (@jonringer) co-authors: diff --git a/rfcs/0093-rfc-categories.md b/rfcs/0093-rfc-categories.md index 2e5600647..af38b3e7f 100644 --- a/rfcs/0093-rfc-categories.md +++ b/rfcs/0093-rfc-categories.md @@ -1,5 +1,5 @@ --- -feature: rfc_categories +identifier: rfc_categories start-date: 2021-05-19 author: David Arnold co-authors: (find a buddy later to help out with the RFC) From 140779e276dde5206841ff167de1138fcd2a3ff5 Mon Sep 17 00:00:00 2001 From: David Arnold Date: Sun, 29 Aug 2021 20:01:55 -0500 Subject: [PATCH 29/29] Add index as suggested to make this RFC immediately more useful --- INDEX.md | 28 ++++++++++++++++++++++++++++ README.md | 3 ++- 2 files changed, 30 insertions(+), 1 deletion(-) create mode 100644 INDEX.md diff --git a/INDEX.md b/INDEX.md new file mode 100644 index 000000000..ef7bf5d9f --- /dev/null +++ b/INDEX.md @@ -0,0 +1,28 @@ +# Feature RFCs +- [replace-unicode-quotes](rfcs/0004-replace-unicode-quotes.md) +- [musl-libc](rfcs/0023-musl-libc.md) +- [run-phase-changes-for-better-nix-shell-use](rfcs/0032-run-phase-changes-for-better-nix-shell-use.md) +- [config-option](rfcs/0042-config-option.md) +- [deprecate_url_syntax](rfcs/0045-deprecate-url-syntax.md) +- [dynamic-ids](rfcs/0052-dynamic-ids.md) +- [commonmark-docs](rfcs/0072-commonmark-docs.md) + +# Process RFCs +- [rfc-process](rfcs/0001-rfc-process.md) +- [release-manager-nixos](rfcs/0015-release-manager.md) +- [nix-core-team](rfcs/0025-nix-core-team.md) +- [staging-workflow](rfcs/0026-staging-workflow.md) +- [rfc-process-team-amendment](rfcs/0036-rfc-process-team-amendment.md) +- [unprivileged-maintainer-teams](rfcs/0039-unprivileged-maintainer-teams.md) +- [rfcsc-rotation](rfcs/0043-rfcsc-rotation.md) +- [disband-nix-core](rfcs/0044-disband-nix-core.md) +- [mark-stale-issues](rfcs/0051-mark-stale-issues.md) +- [retired-committers](rfcs/0055-retired-committers.md) +- [retired-committers-amendment](rfcs/0071-retired-committers-amendment.md) +- [rfc_categories](rfcs/0093-rfc-categories.md) + +# Informational RFCs +- [platform_support_tiers](rfcs/0046-platform-support-tiers.md) +- [nixos-release-schedule](rfcs/0080-nixos-release-schedule.md) +- [nixos-release-stablization](rfcs/0085-nixos-release-stablization.md) + diff --git a/README.md b/README.md index f4fd30fdb..740da6e88 100644 --- a/README.md +++ b/README.md @@ -146,7 +146,8 @@ with the goal of eventual inclusion into Nix, Nixpkgs or the Ecosystem. 11. In most cases, the FCP period is quiet, and the RFC is either merged or closed. However, sometimes substantial new arguments or ideas are raised, the FCP is canceled, and the RFC goes back into development mode. -12. In case of acceptance, the RFC Steering Committee merges the PR. +12. In case of acceptance, the RFC Steering Committee merges the PR and adds it + to the [INDEX.md](./INDEX.md). Otherwise the RFC's pull request is closed. If no consensus can be reached on the RFC but the idea in general is accepted, it gets closed, too. A note is added that is should be proposed again, when the