Bug 1879663 - Address Tom's feedback

docs/rfcs/0000-template.md

@@ -1,13 +1,13 @@
 ---
 layout: page
-title: <your title>
-permalink: /docs/rfcs/<file-name>
+title: your title
+permalink: /docs/rfcs/file-name
 ---
 
-* RFC PR: [<PR #>](https://github.com/mozilla-mobile/android-components/pull/<#>)
+* RFC PR: [PR #](https://github.com/mozilla-mobile/android-components/pull/#)
 * Start date: YYYY-MM-DD (Day of proposal posting.)
-* End date: YYYY-MM-DD (Initial deadline for feedback, subject to blocking changes required. The proposal can be merged immediately after stakeholder approval.)
-* Stakeholders: <github-username>, <github-username>
+* End date: YYYY-MM-DD (Last day for general feedback. However, the proposal can be merged immediately after all stakeholders approve.)
+* Stakeholders: github-username, github-username
 
 ## Summary
 
@@ -22,23 +22,22 @@ open bugs, records of performance metrics, and other empirical data are benefici
 
 This section should include a high-level walkthrough of the steps required to implement the proposal.
 
-## Reference-level explanation
+## Reference-level explanation (optional)
 
-This optional section should include a detailed walkthrough of technical steps or code changes that 
+This section should include a detailed walkthrough of technical steps or code changes that 
 will be required to implement the proposal. Code samples and prototypes are beneficial to include here.
 
-## Drawbacks
+## Drawbacks (optional)
 
-This section should include any drawbacks to the proposal. This section can be considered optional, but is highly encouraged in order to facilitate healthy debate.
+This section should include any drawbacks to the proposal.
 
 ## Rationale and alternatives
 
 This section should include any alternative proposals considered, as well as the rationale for why
-they were not selected for the proposal. This section can be considered optional, but is highly encouraged in order to facilitate healthy debate.
+they were not selected for the proposal.
 
-## Resources and Docs
+## Resources and Docs (optional)
 
-Optional section with links to:
 - Any (internal or external) similar proposals  or other documentation that shares concepts with the proposal.
 - Links to artifacts generated as part of the proposal, such as additional documentation or follow-up bugs.
 

docs/rfcs/0013-rfc-process-updates.md

@@ -30,8 +30,19 @@ This proposal suggests improving the RFC process by introducing the following:
 - An initial deadline recorded in each proposal.
 - A renaming of the the "Prior Art" section to "Resources and Docs" and wording to indicate that proposals can also include additional documentation.
 
+## Rationale and alternatives
+
+The RFC process has been successful in some cases, but has not been consistently followed. This proposal aims to make the process more accessible and clear, by introducing high-level concepts in the README and a clear template. These documents can be more easily treated as living documents, and updated with any future changes to the process.
+
+### Amend RFC 0001 with additional template information
+- This was not included in the proposal in order to keep past RFCs consistent and free of modern context, and so that past RFCs do not become treated as living documents. 
+
 ## Resources and Docs
 
 [README](./README.md), a new artifact that includes guidelines and advice on when RFCs are appropriate and how to contribute them.
 [0000 RFC Template](./0000-template.md), a new artifact that provides a clear starting point for proposals.
 [Follow-up bug for updating CODEOWNERS](https://bugzilla.mozilla.org/show_bug.cgi?id=1881373), so that stakeholders can be found more easily.
+
+## Unresolved questions
+- Will this result in an easier process for contributors to follow?
+- Will this result in more engagement with RFCs?

docs/rfcs/README.md

@@ -21,16 +21,17 @@ RFC process provides, as well as a brief guide on how to draft them.
 
 ## How to contribute an RFC
 
-There is a [template](./0000-template.md) that can be useful for structure. While drafting
-a proposal, consider the scope of your changes. Generally, the higher the impact the changes will have
-on downstream consumers of APIs, other teams, or users the more detail the RFC should include. Detail
-would be things like example use cases, prototypes, and considered alternatives.
+There is a [template](./0000-template.md) that can be a useful guide for structure.
 
-### Resources and Docs
+While drafting a proposal, consider the scope of your changes. Generally, the level of detail should match the level of 
+impact the changes will have on downstream consumers of APIs, other teams, or users.
 
-Include additional documentation artifacts that may be useful in the context of the RFC as part of the
-patch, as well as external references to similar proposals or other documentation that shares concepts
-with your proposal.
+Once a proposal is drafted:
+
+1. Choose a deadline for general feedback.
+2. Select and communicate with stakeholders.
+3. Share the RFC more broadly through Slack and mailing lists for general feedback (like firefox-android-team@ and firefox-mobile@).
+4. Build consensus and integrate feedback.
 
 ### Stakeholders
 
@@ -41,7 +42,6 @@ Stakeholders should be active in the RFC process - they should ask to be replace
 
 ### Deadlines
 
-An initial deadline should be included in each RFC. This should usually be at least a week, so plan accordingly. 
-For more substantial changes, it can be useful to push that to 2 or 3 weeks so that there is more opportunity for feedback from people that are not stakeholders.
-Blocking feedback can push these deadlines back, but they should be updated appropriately so that interested parties have a clear understanding of timelines.
+A deadline for feedback should be included in each RFC. This should usually be at least a week, so plan accordingly. 
+For more substantial changes, it can be useful to plan for 2 or 3 weeks so that there is more opportunity for feedback from people that are not stakeholders.
 If a proposal is approved by all stakeholders earlier than the deadline, the proposal can be merged immediately.