From 19fbe0ca66bc2a23e79e23796afbfd764ba89c41 Mon Sep 17 00:00:00 2001 From: Nick Fitzgerald Date: Wed, 6 Mar 2019 13:32:18 -0800 Subject: [PATCH 1/5] Add an amendment to the RFC process --- README.md | 69 ++++++++++++++- text/001-the-rfc-process.md | 6 ++ text/009-rfc-process-addendum.md | 142 +++++++++++++++++++++++++++++++ 3 files changed, 214 insertions(+), 3 deletions(-) create mode 100644 text/009-rfc-process-addendum.md 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..6d40a6d --- /dev/null +++ b/text/009-rfc-process-addendum.md @@ -0,0 +1,142 @@ +- Start Date: 2019-03-06 +- RFC PR: (leave this empty) +- 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. + +# 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. There is a fundamental trade off +between shipping and team member availability at play. Because of how young the +Wasm space is, and how quickly it moves, we are inclined to err towards the +shipping side of this trade off. + +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. + +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, 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. + +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? From 068e358cb6b93f5cbb8795064b6c49d15b9a627b Mon Sep 17 00:00:00 2001 From: Nick Fitzgerald Date: Wed, 6 Mar 2019 13:38:59 -0800 Subject: [PATCH 2/5] Add RFC PR link --- text/009-rfc-process-addendum.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/009-rfc-process-addendum.md b/text/009-rfc-process-addendum.md index 6d40a6d..dd26cf1 100644 --- a/text/009-rfc-process-addendum.md +++ b/text/009-rfc-process-addendum.md @@ -1,5 +1,5 @@ - Start Date: 2019-03-06 -- RFC PR: (leave this empty) +- RFC PR: https://github.com/rustwasm/rfcs/pull/9 - Tracking Issue: (leave this empty) # Summary From c9c0f05db4a07a81745fd70799f6f81f128733e6 Mon Sep 17 00:00:00 2001 From: Nick Fitzgerald Date: Wed, 6 Mar 2019 16:41:12 -0800 Subject: [PATCH 3/5] Move motivational-y text from rationale to the motivation section --- text/009-rfc-process-addendum.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/text/009-rfc-process-addendum.md b/text/009-rfc-process-addendum.md index dd26cf1..198f803 100644 --- a/text/009-rfc-process-addendum.md +++ b/text/009-rfc-process-addendum.md @@ -20,6 +20,15 @@ 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 @@ -122,15 +131,6 @@ 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. -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, 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. - 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). From a193ca40eefab956e0eaa440b94d4175c3f83794 Mon Sep 17 00:00:00 2001 From: Nick Fitzgerald Date: Wed, 20 Mar 2019 10:43:47 -0700 Subject: [PATCH 4/5] Remove discussion of wasm domain and erring towards shipping --- text/009-rfc-process-addendum.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/text/009-rfc-process-addendum.md b/text/009-rfc-process-addendum.md index 198f803..0c960e3 100644 --- a/text/009-rfc-process-addendum.md +++ b/text/009-rfc-process-addendum.md @@ -118,10 +118,7 @@ Here are some example timelines for RFCs with team members X, Y, and Z. 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. There is a fundamental trade off -between shipping and team member availability at play. Because of how young the -Wasm space is, and how quickly it moves, we are inclined to err towards the -shipping side of this trade off. +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 From ec4033c65f5b98db0d24c1c4bf0e31b4040b1870 Mon Sep 17 00:00:00 2001 From: Nick Fitzgerald Date: Wed, 20 Mar 2019 10:44:18 -0700 Subject: [PATCH 5/5] Remove commented out text from RFC template --- text/009-rfc-process-addendum.md | 7 ------- 1 file changed, 7 deletions(-) diff --git a/text/009-rfc-process-addendum.md b/text/009-rfc-process-addendum.md index 0c960e3..5cfcda0 100644 --- a/text/009-rfc-process-addendum.md +++ b/text/009-rfc-process-addendum.md @@ -108,13 +108,6 @@ Here are some example timelines for RFCs with team members X, Y, and Z. # 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