diff --git a/README.md b/README.md index 8707474..3cb2be9 100644 --- a/README.md +++ b/README.md @@ -15,12 +15,75 @@ direction the ecosystem is evolving in. ## The RFC Process -When does a change require an RFC? How does an RFC get approved or rejected? -What is the RFC life cycle? +> When does a change require an RFC? How does an RFC get approved or rejected? +> What is the RFC life cycle? -[These questions are answered in RFC 001][rfc-001]. +[These questions were initially answered in RFC 001][rfc-001] and then later +[amended in RFC 009][rfc-009]. The canonical RFC process is documented here: + +- Fork the [RFC repository][rfc-repo]. +- Copy `000-template.md` to `text/000-my-feature.md` (where "my-feature" is + descriptive. Don't assign an RFC number yet). +- 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. +- 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. +- Each new RFC pull request will be triaged in the next Rust and WebAssembly + domain working group meeting and assigned to one or more of the [`@rustwasm/*` + teams][teams]. +- Build consensus and integrate feedback. RFCs that have broad support are + much more likely to make progress than those that don't receive any + comments. Feel free to reach out to the RFC assignee in particular to get + help identifying stakeholders and obstacles. +- The team(s) will discuss the RFC pull request, as much as possible in the + comment thread of the pull request itself. Offline discussion will be + summarized on the pull request comment thread. +- RFCs rarely go through this process unchanged, especially as alternatives + and drawbacks are shown. You can make edits, big and small, to the RFC to + clarify or change the design, but make changes as new commits to the pull + request, and leave a comment on the pull request explaining your changes. + Specifically, do not squash or rebase commits after they are visible on the + pull request. +- At some point, a member of the subteam will propose a "motion for final + comment period" (FCP), along with a *disposition* for the RFC (merge, close, + or postpone). + - This step is taken when enough of the tradeoffs have been discussed that the + team(s) are in a position to make a decision. That does not require + consensus amongst all participants in the RFC thread (which may be + impossible). However, the argument supporting the disposition on the RFC + needs to have already been clearly articulated, and there should not be a + strong consensus *against* that position outside of the team(s). Team + members use their best judgment in taking this step, and the FCP itself + ensures there is ample time and notification for stakeholders to push back + if it is made prematurely. + - For RFCs with lengthy discussion, the motion to FCP should be preceded by a + *summary comment* trying to lay out the current state of the discussion and + major tradeoffs/points of disagreement. + - Before actually entering FCP, members of the team(s) must sign off; this is + often the point at which many team members first review the RFC in full + depth. + - Team members have fourteen calendar days to formally respond. The + response may be one of: + - Signing off on entering FCP by checking their checkbox. + - Lodging a concern that must be addressed before the RFC can enter FCP. + - Requesting a time extension, which extends the time-to-respond period from + fourteen days to 28 days from the FCP proposal date. + If a team member has not responded by the end of the time-to-respond period, + then it is considered that they have deferred the FCP decision to the other + team members. +- The FCP lasts seven calendar days. It is also advertised widely, e.g. in an + issue of ["This Week in Rust and WebAssembly" on the Rust and WebAssembly + blog](https://rustwasm.github.io/). This way all stakeholders have a chance to + lodge any final objections before a decision is reached. +- 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. [rfc-001]: https://rustwasm.github.io/rfcs/001-the-rfc-process.html +[rfc-009]: https://rustwasm.github.io/rfcs/009-rfc-process-addendum.html ## License [License]: #license diff --git a/text/001-the-rfc-process.md b/text/001-the-rfc-process.md index 5e3a2f4..ceefede 100644 --- a/text/001-the-rfc-process.md +++ b/text/001-the-rfc-process.md @@ -90,6 +90,12 @@ the RFC process, it may be closed with a polite request to submit an RFC first. ## The RFC process step by step +> NOTE: this process was [amended in RFC +> 009](https://rustwasm.github.io/rfcs/009-rfc-process-addendum.html) and the +> canonical, up-to-date process is now defined in [the `README.md` of the +> `rustwasm/rfcs` +> repository](https://github.com/rustwasm/rfcs/blob/master/README.md#the-rfc-process). + - Fork the [RFC repository][rfc-repo]. - Copy `000-template.md` to `text/000-my-feature.md` (where "my-feature" is descriptive. Don't assign an RFC number yet). diff --git a/text/009-rfc-process-addendum.md b/text/009-rfc-process-addendum.md new file mode 100644 index 0000000..5cfcda0 --- /dev/null +++ b/text/009-rfc-process-addendum.md @@ -0,0 +1,132 @@ +- Start Date: 2019-03-06 +- RFC PR: https://github.com/rustwasm/rfcs/pull/9 +- Tracking Issue: (leave this empty) + +# Summary +[summary]: #summary + +Amend our RFC process so that if one team member of the working group is +unavailable, the whole RFC process is not halted at a stand still. Concretely, +if after fourteen calendar days a team member has not formally responded to +a proposal that an RFC enter its final comment period (FCP), then they +automatically defer the FCP decision to the other team members. + +# Motivation +[motivation]: #motivation + +A key goal of this RFC process amendment is that if a team member is busy or +otherwise unavailable, they can be accommodated, and they still have the +opportunity to provide input on the RFC and the FCP proposal. However, they must +communicate to the other team members, and if they fail to do that, as a last +resort it does not halt RFC progress. + +I'd like to emphasize that the intention of this amendment is **not** to provide +a way to ram RFCs through the RFC process. It is only to provide a release valve +for the current RFC procedure's failure mode where if a single team member is +unavailable or otherwise unresponsive, then the whole RFC process grinds to a +halt. Additionally, this amendment does not remove the ability for team members +to file their own post facto amendments to RFCs for which they were unavailable, +nor does it remove their ability to engage in the original RFC and FCP proposal +discussion or raise FCP-blocking concerns. + +# Stakeholders +[stakeholders]: #stakeholders + +The stakeholders are the members of this working group, and the WG core team in +particular. + +# Detailed Explanation +[detailed-explanation]: #detailed-explanation + +We add this amendment to our RFC process's FCP proposal step: + +> Once a team member proposes that an RFC enter its final comment period, the +> other team members have fourteen calendar days to formally respond. The +> response may be one of: +> +> * Signing off on entering FCP by checking their checkbox. +> * Lodging a concern that must be addressed before the RFC can enter FCP. +> * Requesting a time extension, which extends the time-to-respond period from +> fourteen days to 28 days from the FCP proposal date. +> +> If a team member has not responded by the end of the time-to-respond period, +> then it is considered that they have deferred the FCP decision to the other +> team members. + +## Examples + +Here are some example timelines for RFCs with team members X, Y, and Z. + +### All Members Sign Off on FCP + +* 2019-01-01: The RFC is written and proposed. Community discussion begins. +* 2019-01-10: Consensus has formed, and X proposes that the RFC enter its FCP + with disposition to merge. +* 2019-01-12: Y signs off on the FCP proposal. +* 2019-01-17: Z signs off on the FCP proposal. All team members have now signed + off, and the RFC enters FCP. +* 2019-01-24: The seven-day FCP period has passed without additional concerns + being raised, so the RFC is merged. + +### X Does Not Respond to the FCP Proposal + +* 2019-01-01: The RFC is written and proposed. Community discussion begins. +* 2019-01-10: Consensus has formed, and Z proposes that the RFC enter its FCP + with disposition to merge. +* 2019-01-12: Y signs off on the FCP proposal. +* 2019-01-24: X has not responded to the FCP in fourteen days, so they + automatically defer to Y and Z. The RFC enters its FCP. +* 2019-01-31: The seven-day FCP period has passed without additional concerns + being raised, so the RFC is merged. + +### Y Requests a Time-to-Respond Extension and then Later Responds + +* 2019-01-01: The RFC is written and proposed. Community discussion begins. +* 2019-01-10: Consensus has formed, and X proposes that the RFC enter its FCP + with disposition to merge. +* 2019-01-12: Z signs off on the FCP proposal. +* 2019-01-15: Y is going on vacation and hasn't had a chance to give the RFC + deep consideration. They request a time-to-respond extension. +* 2019-01-28: Y comes back from vacation, considers the RFC, and signs off on + it. All team members have now signed off and the RFC enters FCP. +* 2019-02-05: The seven-day FCP period has passed without additional concerns + being raised, so the RFC is merged. + +### Z Requests a Time-to-Respond Extension and then Fails to Respond + +* 2019-01-01: The RFC is written and proposed. Community discussion begins. +* 2019-01-10: Consensus has formed, and X proposes that the RFC enter its FCP + with disposition to merge. +* 2019-01-12: Y signs off on the FCP proposal. +* 2019-01-13: Z requests a time-to-respond extension. +* 2019-02-11: It has been 28 days since the date of the FCP proposal, and Z has + still not responded. Therefore, they automatically defer to X and Y. The RFC + enters its FCP. +* 2019-02-18: The seven-day FCP period has passed without additional concerns + being raised, so the RFC is merged. + +# Drawbacks, Rationale, and Alternatives +[alternatives]: #drawbacks-rationale-and-alternatives + +The primary drawback to this RFC is that it enables going forward with RFCs that +have not been considered by every team member. The alternative, and our current +state of affairs, is delaying the RFC until every team member has signed off on +the RFC regardless how long that might take. + +This RFC amendment also identifies a variable we can tweak: how long to wait for +a response before considering an unavailable team member to have deferred to the +other team members' collective judgment. Right now it is effectively set to +"infinite time", and this RFC proposes fourteen days, with the option to extend +it to 28 days. We could potentially change those numbers to seven days and +fourteen days, or to 28 and 56 days. We could potentially remove the extension +option and have only a single time-to-respond limit. + +As far as prior art goes, the main Rust RFC process ran into similar problems +that this amendment is attempting to solve, and [adopted a similar mechanism for +entering FCP](https://github.com/anp/rfcbot-rs/pull/188). + +# Unresolved Questions +[unresolved]: #unresolved-questions + +- Does a fourteen day time-to-respond, with the option of extending it to 28 + days sound good? Should we tweak these numbers a little?