[RFC 0093] Propose RFC Categories #93
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,58 +1,65 @@ | ||
| --- | ||
| 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) | ||
| 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 | ||
| --- | ||
|
|
||
| <!-- | ||
| If you are proposing a feature to Nix, Nixpkgs, Hydra or any other | ||
| software developed by the nix community, this is the template | ||
| you want to use. | ||
| --> | ||
|
|
||
| # 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 | ||
| detail for somebody familiar with the ecosystem to understand, and implement. | ||
| This should get into specifics and corner-cases. Yet, this section should also | ||
| be terse, avoiding redundancy even at the cost of clarity. --> | ||
|
|
||
| # 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 | ||
|
|
||
| <!-- 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? --> | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,36 @@ | ||
| --- | ||
| 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) | ||
| 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]() | ||
| category: informational | ||
| --- | ||
|
|
||
| <!-- | ||
| If you are seeking to gather consensus on a fact, or seek general acceptance about | ||
| a new information, then use this template. | ||
| The fact or information should be sufficiently important to require an RFC process | ||
| Some examples are, without being an exhaustive list: | ||
|
|
||
| - Start a talk, meetup, or social networking account that will be expected to | ||
| officially “represent nix” | ||
|
Comment on lines
+19
to
+20
There was a problem hiding this comment. This seems to happen so infrequently that I'm not sure it's a good example of something we should change the RFC process for. There was a problem hiding this comment. In this context of a template comment, I think, it does add to give the reader an aproximate sense of what can be considered informational. Removing it, IMO, would not further the reader's understanding, here. There was a problem hiding this comment. I think the point is that there are a lot of rare types of things, but together they are not so infrequent. I agree that this category is somewhat vague and "miscellaneous" but I think that is useful to have. Worst case we find this category isn't useful, and split, merge or remove it. I think that with the current proposal the changing of categories (or removing them altogether) is cheap if we don't find value. |
||
| - Document design issues, or recording the decision to _not_ act upon something. | ||
|
There was a problem hiding this comment. Isn't a design issue also a technical one? I imagine someone would propose a design in a standard RFC, and whether it gets accepted or rejected, we have a "paper-trail" of the discussion and its conclusion. Why would we need a separate RFC to "enshrine" the output of the discussion? Who would write that? What happens to the design decisions that no one writes an informational RFC about? In general, can't we document designs in the documentation? And what are examples of things we would not act upon, but write an informational RFC about? There was a problem hiding this comment. The problem with current RFCs are that they start from a "change" (hence also change -> idea renaming). However, there currently doesn't seem to be a venue for officializing tribal practice. Such acknowledgments not always root in a failed proposal for change. I don't have any good examples. This is an exemplary list item for the general concept of informational RFCs. I have redacted this list (or taken from bors) to convey a general idea of what could be "informational". I didn't intent to make every item water tight. Maybe "informational" is indeed a misnomer, on the other hand going through past RFCs, there are a few that seem to somehow fit into this category, for example RFC46. I'd rather be concerned if the reader get's a general and useful enough idea of what could be informational RFCs. I guess the defining element is that they are not centered around a proposed action but around generating consensus about a proposed "fact"/"information". |
||
| - Proposing an experiment. | ||
|
There was a problem hiding this comment. This seems like a strange loophole. If the experiment is technical, then it should be a technical RFC, shouldn't it? There was a problem hiding this comment. "feature" RFCs are intended to record official changes to |
||
| - Record high-stake proof-generated insight. | ||
|
There was a problem hiding this comment. I don't understand what this means. I'd either remove it or reword it to make it clearer. |
||
| --> | ||
|
|
||
| # Summary | ||
| [summary]: #summary | ||
|
|
||
| <!-- One paragraph to resume this document. --> | ||
|
|
||
| In order to address "X", I/we propose to "Y". | ||
|
|
||
| # My Structure | ||
|
|
||
| <!-- This template does not have a recommended structure, please use your best | ||
| judgement for your particular case. --> | ||
|
There was a problem hiding this comment. We should probably at least keep a "Motivation" section. Even if that motivation is "To disseminate information with no further explicit action." |
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,99 @@ | ||
| --- | ||
| 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) | ||
| 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]() | ||
| category: process | ||
| --- | ||
|
|
||
| <!-- | ||
| If you are proposing to change a process with regard of how the nix community | ||
| conducts, then use this template. Some examples are, without being an exhaustive list: | ||
|
|
||
| - Change the RFC process, the organization of the issue tracker or the forum | ||
| - Change community workflows or other comunity infrastructure | ||
| - Amend the code of conduct and similar high level normative documents | ||
|
Comment on lines
+17
to
+19
There was a problem hiding this comment. What do we gain by having these process changes live in a separate namespace than the technical ones? There was a problem hiding this comment. Most importantly: a different template that focuses on process change. The hope is also, that participants will be assisted in having more informed discussion by the acknowledging explicitly the rfc category all by itself. |
||
| --> | ||
|
|
||
| # Summary | ||
| [summary]: #summary | ||
|
|
||
| <!-- One paragraph to resume this document (motivation and future process). --> | ||
|
|
||
| In order to address "X", I/we propose to "Y". | ||
|
|
||
| # Classification | ||
| [classification]: #classification | ||
|
|
||
| <!-- Please check the relevant boxes (typically one) -- or add your own. --> | ||
|
|
||
| - [ ] general habits and decision making | ||
| - [ ] core technical protocols & processes | ||
| - [ ] contributer efficiency support | ||
|
|
||
| # Motivation | ||
| [motivation]: #motivation | ||
|
|
||
| <!-- What's wrong? Please feel encouraged to benchmark us against other | ||
| (open source or other) ecosystems. --> | ||
|
|
||
| # Current Process | ||
| [as-is]: #current-process | ||
|
|
||
| <!-- Describe the current process as it is observed out in the wild. | ||
| If there has been a previous RFC for this process, please mention it, | ||
| but prefer the state of the world "as-is". In a final paragraph, please | ||
| describe its shortcomings and how they relate to the motivation. | ||
|
|
||
| Make use of BPMN 2.0 notation, if you'd find that useful. --> | ||
|
There was a problem hiding this comment. I'll clarify that, There was a problem hiding this comment. How well does this integrate into markdown/github? There was a problem hiding this comment.
Reading through https://gitlab.com/gitlab-org/gitlab/-/issues/22365, it might be that https://kroki.io/ is a suitable answer that at least circles around your question. I think it makes sense to put a practical suggestion here on how to include such a diagram. Processes without diagrams are like bread without butter. |
||
|
|
||
| # Future Process | ||
| [to-be]: #future-process | ||
|
|
||
| <!-- Describe the future process how you imagine it to be. | ||
| In a final paragraph, please describe how this would satisfy the motivation. | ||
| Please be explicit, if it only party addresses the motivation. | ||
|
|
||
| Make use of BPMN 2.0 notation, if you'd find that useful. --> | ||
|
|
||
| # Roles & Stakeholders | ||
|
|
||
| <!-- | ||
| Stakeholders are people who have an interest in the outcome of this RFC. | ||
|
|
||
| Please describe in abstract terms the roles involved in this process | ||
| and how they are affected by this process change. Plotting estimated | ||
| / abstract time requirements of _as-is_ against _to-be_ is a plus. | ||
| The idea is to get a better sense of the stakeholders of this process | ||
| and their respective interestes and estimate the associated total | ||
| costs imposed (mostly in time, can be negative) to the community. | ||
|
Comment on lines
+68
to
+73
There was a problem hiding this comment. I do appreciate the fact that having a separate "process" category allows us to add guidelines to this document, thereby making it clearer what is expected. I am not sure that I would want to go through this kind of jargon to want to do that though. I'd remove mentions of BPMN, plotting time requirements and even of the word "stakeholders". The corporate-sounding language rubs me the wrong way, personally. There was a problem hiding this comment. I think usage of language should be both neutral and concise. We concluded in the shepherd meeting, that stakeholder is the most concise english word available here, even though originating from a organizational-philosophical context. I think time burdon have repetedly come up as a counter argument in many process amendements, especially time requirements on maintainers. In my opinion, suggesting to explicitly treat maintainer's interests and conscientiously assess time requirements that any change places on them might help to promote better informed discussions. |
||
|
|
||
| Typical stakeholders involve: maintainers, end users, corporate users | ||
| --> | ||
|
|
||
| # Pros & Cons | ||
| [evaluation]: #pros-and-cons | ||
|
|
||
| <!-- Within your judgment, prefer bullet points over prose. --> | ||
|
|
||
| ## Pros | ||
|
|
||
|
|
||
| ## Cons | ||
|
|
||
|
|
||
| # Conclusion | ||
| [conclusion]: #conclusion | ||
|
|
||
| <!-- In the greater scheme of things, to what degree does your proposal | ||
| satisfy the motivation. Is it meaningful? Is it important? Is it urgent? --> | ||
|
|
||
| # Updates | ||
| [updates]: #updates | ||
|
|
||
| <!-- This space is reserved for linking or in-lining future updates to this | ||
| process --> | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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) | ||
|
|
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,9 +1,10 @@ | ||
| --- | ||
| identifier: rfc-process | ||
| start-date: 2017-02-12 | ||
| author: zimbatm | ||
| co-authors: teh, MoreTea | ||
| related-issues: https://github.com/zimbatm/rfcs/pull/2 | ||
| category: process | ||
| --- | ||
|
|
||
| # Summary | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,12 +1,13 @@ | ||
| --- | ||
| identifier: replace-unicode-quotes | ||
| start-date: 2017-03-19 | ||
| author: layus | ||
| co-authors: zimbatm | ||
| 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 | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,9 +1,10 @@ | ||
| --- | ||
| identifier: release-manager-nixos | ||
| start-date: 2017-07-18 | ||
| author: Robin Gloster (@globin) | ||
| co-authors: Franz Pletz (@fpletz) | ||
| related-issues: -- | ||
| category: process | ||
| --- | ||
|
|
||
| # Summary | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@blaggacao Please update the shepherd-team/shepherd-leader.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the template, not the RFC itself.