Differentiate RFC templates

0000-template.md → 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)
 ---
 
+<!--
+If you are proposing a feature to Nix, Nixpkgs, Hydra or any other
+software developped by the nix community, this is the template
+you want to use.
+-->
+
 # Summary
 [summary]: #summary
 
-One paragraph explanation of the feature.
+<!-- 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?
+<!-- 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
+<!-- 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.
+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
+<!-- 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.
+instead. -->
 
 # Drawbacks
 [drawbacks]: #drawbacks
 
-Why should we *not* do this?
+<!-- Why should we *not* do this? -->
 
 # Alternatives
 [alternatives]: #alternatives
 
-What other designs have been considered? What is the impact of not doing this?
+<!-- 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?
+<!-- 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?
+<!-- What future work, if any, would be implied or impacted by this feature
+without being directly part of the work? -->

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]()
+---
+
+<!--
+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”
+- Document design issues, or recording the decision to _not_ act upon something.
+- Proposing an experiment.
+- Record high-stake proof-generated insight.
+-->
+
+# 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
+judgment for your particular case. -->

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]()
+---
+
+<!--
+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
+-->
+
+# 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. -->
+
+# 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
+
+<!-- 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.-->
+
+# 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 wat 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 -->