From faefe0b825f0e94a4a7f0ae4e2b3e325cfd0a34b Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Fri, 26 Jun 2020 17:14:58 -0700 Subject: [PATCH 01/13] RFC process proposal --- accepted/rfc-process.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 accepted/rfc-process.md diff --git a/accepted/rfc-process.md b/accepted/rfc-process.md new file mode 100644 index 0000000..e69de29 From 42132290bc8f72925753a02dabd00678777a942a Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Fri, 26 Jun 2020 17:27:56 -0700 Subject: [PATCH 02/13] Make stakeholder groups more flexible --- accepted/rfc-process.md | 112 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 112 insertions(+) diff --git a/accepted/rfc-process.md b/accepted/rfc-process.md index e69de29..2c104b5 100644 --- a/accepted/rfc-process.md +++ b/accepted/rfc-process.md @@ -0,0 +1,112 @@ +# RFC process for the Bytecode Alliance + +# Summary + +As the Bytecode Alliance grows, we need more formalized ways of communicating about and reaching consensus on major changes to core projects. This document proposes to adapt ideas from Rust’s [RFC](https://github.com/rust-lang/rfcs/) and [MCP](https://forge.rust-lang.org/compiler/mcp.html) processes to the Bytecode Alliance context. + +# Motivation + +There are two primary motivations for creating an RFC process for the Bytecode Alliance: + +* **Coordination with stakeholders**. Core BA projects have a growing set of stakeholders building on top of the projects, but not necessarily closely involved in day-to-day development. This group will only grow as the BA brings on more members. An RFC process makes it easier to communicate _possible major changes_ that stakeholders may care about, and gives them a chance to weigh in. + +* **Coordination within a project**. As the BA grows, we hope and expect that projects will be actively developed by multiple organizations, rather than just by a “home” organization. While day-to-day activity can be handled through issues, pull requests, and regular meetings, having a dedicated RFC venue makes it easier to separate out discussions with far-ranging consequences that all project developers may have an interest in. + + +# Proposal + +The design of this RFC process draws ideas from Rust’s [RFC](https://github.com/rust-lang/rfcs/) and [MCP](https://forge.rust-lang.org/compiler/mcp.html) processes, adapting to the BA and trying to keep things lightweight. + + +## Stakeholders + +Each core BA project has a formal set of **stakeholders**. These are individuals, organized into groups by project and/or member organization. Stakeholders can block proposals, and conversely having explicit sign-off from at least one individual within each stakeholder group is a sufficient (but not necessary) condition for immediately accepting a proposal. + +The process for determining core BA projects and their stakeholder set is defined by the TSC. + +## Structure and workflow + +### Creating and discussing an RFC + +* We have a dedicated bytecodealliance/rfcs repo that houses _all_ RFCs for core BA projects, much like Rust’s rfcs repo that is shared between all Rust teams. +* The rfcs repo will be structured similarly to the one in Rust: + * A template markdown file laying out the format of RFCs, like [Rust’s](https://github.com/rust-lang/rfcs/blob/master/0000-template.md) but simplified. + * A subdirectory holding the text of all accepted RFCs, like [Rust’s](https://github.com/rust-lang/rfcs/tree/master/text). +* New RFCs are submitted via pull request, and both technical and process discussion happens via the comment thread. +* The RFC is tagged with a **project label**, corresponding to the BA project it targets. This tagging informs tooling about the relevant stakeholder set. + +### Making a decision: merge or close + +* When discussion has stabilized around the main points of contention, any stakeholder can make a **motion to finalize**, using a special comment syntax understood by tooling. This motion comes with a disposition: merge or close. +* In response to the motion to finalize, a bot will post a special comment with a **stakeholder checklist**. + * This list includes the GitHub handle for each individual stakeholder, organized into stakeholder groups. + * The individual who filed the motion to finalize is automatically checked off. +* Once _any_ stakeholder from a _different_ group has signed off, the RFC will move into a 10 day **final comment period** (FCP), long enough to ensure that other stakeholders have at least a full business week to respond. +* During FCP, any stakeholder can raise an **objection** using a syntax understood by the bot. Doing so aborts FCP and labels the RFC as `blocked-by-stakeholder` until the objection is formally resolved (again using a special comment syntax). +* Finally, the RFC is automatically merged/close if either: + * The FCP elapses without any objections. + * A stakeholder from _each_ group has signed off, short-cutting the waiting period. + +## What goes into an RFC? + +RFCs will follow a format inspired by Rust, but significantly simplified. RFCs are markdown files containing the following sections (which will be laid out in a template file): + +* **Summary**. A ~one paragraph overview of the RFC. +* **Motivation**. What problem does the RFC solve? +* **Proposal**. The meat of the RFC. +* **Rationale and alternatives**. A discussion of tradeoffs: why was the proposal chosen, rather than alternatives? +* **Open questions**. Often an RFC is initially created with a broad proposal but some gaps that need community input to fill in. + +### Draft RFCs + +It is encouraged to use the RFC process to discuss ideas early in the design phase, before a _full_ proposal is ready. Such RFCs should be marked as [a draft PR](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests#draft-pull-requests), and contain the following sections: + +* **Motivation**. What problem are you ultimately hoping to solve? +* **Proposal sketch**. At least a short sketch of a possible approach. Beginning discussion without _any_ proposal tends to be unproductive. +* **Open questions**. This section is especially important for draft RFCs: it’s where you highlight the key issues you are hoping that discussion will address. + +RFCs cannot be merged in draft form. Before any motion to merge, the draft should be revised to include all required RFC sections, and the PR should be changed to a standard GitHub PR. + +## What requires an RFC? + +When should you open an RFC, rather than just writing code and opening a traditional PR? + +* When the work involves changes that will significantly affect stakeholders or project contributors. Each project may provide more specific guidance. Examples include: + * Major architectural changes + * Major new features + * Simple changes that have significant downstream impact + * Changes that could affect guarantees or level of support, e.g. removing support for a target platform + * Changes that could affect mission alignment, e.g. by changing properties of the security model +* When the work is substantial and you want to get early feedback on your approach. + +# Rationale and alternatives + +## Stakeholder and FCP approach + +This proposal tries to strike a good balance between being able to move quickly, and making sure stakeholder consent is represented. + +The core thinking is that getting active signoff from at least one person from a different stakeholder group, together with the original motion to finalize, is sufficient evidence that an RFC has received external vetting. The additional 10 day period gives all stakeholders the opportunity to review the proposal; if there are any concerns, or even just a desire to take more time to review, any stakeholder can file an objection. And on the other hand, proposals can move even more quickly with signoff from each group. + +In total, this setup allows proposals to move more quickly than either Rust’s RFC or MCP processes, due to the less stringent review requirements and ability to end FCP with enough signoff. At the same time, the default FCP waiting period and objection facility should provide stakeholders with enough notice and tools to slow things down when needed. + + +## Organizations vs individuals + +Motion through the FCP process is gated at the stakeholder group level, but the actual check-off process is tied to individuals. There are reasons for both: + +* **Gated by group**. The goal of the signoff process is to provide a “stakeholder consent” check before finalizing an RFC. We view a signoff from _any_ member of an organization or project as a fair representation of that organization or projects’s interests, and expect individuals to act accordingly. +* **Individual sign-off**. Despite being gated by groups, we call out individuals by GitHub handle for review. Doing so helps avoid diffusion of responsibility: if we instead merely had a checkbox per organization, it could easily create a situation where no particular individual felt “on duty” to review. In addition, tracking which individual approved the review provides an important process record in case that individual fails to represent their group's interests. + +## Comparison to Rust’s RFC and MCP processes + +The Rust RFC process has successfully governed the development of the language from before 1.0, and covers an enormous range of subprojects, including the language design, tooling, the compiler, documentation, and even the Rust web site. It is a proven model and variations of the process have been adopted by several other large projects. Its workflow is simple and fits entirely within GitHub, which is already the central point of coordination within the BA. And given the central role of Rust within the BA, it’s a model that members are likely to already be familiar with. + +That said, a major difference in design is the notion of **stakeholders** and how they impact the decision-making process. Here we borrow some thinking from Rust’s lightweight MCP process, allowing a decision to go forward after getting buy-in from just one stakeholder within a different group -- but still requiring a waiting period to do so. A further innovation is that getting sign off from within _all_ groups immediately concludes FCP. That was not possible in the Rust community, where the set of stakeholders is unbounded. + +The most common complaint about the Rust RFC process is that it is, in some ways, a victim of its own success: RFC comment threads can quickly become overwhelming. While this may eventually become an issue for the BA as well, we have some additional recourse: we have a clear membership model which will allow us to prioritize concerns from member organizations, and take action when individuals outside of any organization overwhelm comment threads. + +We could instead follow Rust’s MCP model and use Zulip streams for RFC discussion. However, that introduces a more complex workflow (spanning multiple systems) and leaves a less permanent and less accessible record of discussion. + +# Open questions + +None at this time. \ No newline at end of file From b9b8c10b9cbd562c295e5b27b9e90995b7da7ed0 Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Fri, 26 Jun 2020 17:30:01 -0700 Subject: [PATCH 03/13] Clarify how stakeholder groups will originate, prior to the TSC --- accepted/rfc-process.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/accepted/rfc-process.md b/accepted/rfc-process.md index 2c104b5..d5818ed 100644 --- a/accepted/rfc-process.md +++ b/accepted/rfc-process.md @@ -12,17 +12,15 @@ There are two primary motivations for creating an RFC process for the Bytecode A * **Coordination within a project**. As the BA grows, we hope and expect that projects will be actively developed by multiple organizations, rather than just by a “home” organization. While day-to-day activity can be handled through issues, pull requests, and regular meetings, having a dedicated RFC venue makes it easier to separate out discussions with far-ranging consequences that all project developers may have an interest in. - # Proposal The design of this RFC process draws ideas from Rust’s [RFC](https://github.com/rust-lang/rfcs/) and [MCP](https://forge.rust-lang.org/compiler/mcp.html) processes, adapting to the BA and trying to keep things lightweight. - ## Stakeholders Each core BA project has a formal set of **stakeholders**. These are individuals, organized into groups by project and/or member organization. Stakeholders can block proposals, and conversely having explicit sign-off from at least one individual within each stakeholder group is a sufficient (but not necessary) condition for immediately accepting a proposal. -The process for determining core BA projects and their stakeholder set is defined by the TSC. +The process for determining core BA projects and their stakeholder set will ultimately be defined by the Technical Steering Committee, once it is in place. Until then, the current BA Steering Committee will be responsible for creating a provisional stakeholder arrangement, as well as deciding whether to accept this RFC. ## Structure and workflow @@ -89,7 +87,6 @@ The core thinking is that getting active signoff from at least one person from a In total, this setup allows proposals to move more quickly than either Rust’s RFC or MCP processes, due to the less stringent review requirements and ability to end FCP with enough signoff. At the same time, the default FCP waiting period and objection facility should provide stakeholders with enough notice and tools to slow things down when needed. - ## Organizations vs individuals Motion through the FCP process is gated at the stakeholder group level, but the actual check-off process is tied to individuals. There are reasons for both: From 14765ba0ec32a01c7899ebc8b7017fa0bb4507ec Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Thu, 2 Jul 2020 16:03:02 -0700 Subject: [PATCH 04/13] Expand acronyms --- accepted/rfc-process.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/accepted/rfc-process.md b/accepted/rfc-process.md index d5818ed..22bfa79 100644 --- a/accepted/rfc-process.md +++ b/accepted/rfc-process.md @@ -2,7 +2,7 @@ # Summary -As the Bytecode Alliance grows, we need more formalized ways of communicating about and reaching consensus on major changes to core projects. This document proposes to adapt ideas from Rust’s [RFC](https://github.com/rust-lang/rfcs/) and [MCP](https://forge.rust-lang.org/compiler/mcp.html) processes to the Bytecode Alliance context. +As the Bytecode Alliance (BA) grows, we need more formalized ways of communicating about and reaching consensus on major changes to core projects. This document proposes to adapt ideas from Rust’s [RFC](https://github.com/rust-lang/rfcs/) and [MCP](https://forge.rust-lang.org/compiler/mcp.html) processes to the Bytecode Alliance context. # Motivation @@ -14,7 +14,7 @@ There are two primary motivations for creating an RFC process for the Bytecode A # Proposal -The design of this RFC process draws ideas from Rust’s [RFC](https://github.com/rust-lang/rfcs/) and [MCP](https://forge.rust-lang.org/compiler/mcp.html) processes, adapting to the BA and trying to keep things lightweight. +The design of this RFC process draws ideas from Rust’s [Request for Comment](https://github.com/rust-lang/rfcs/) (RFC) and [Major Change Proposal](https://forge.rust-lang.org/compiler/mcp.html) (MCP) processes, adapting to the BA and trying to keep things lightweight. ## Stakeholders From 4e1a57a8dd64643abc165c8bb336c339b4984f7d Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Thu, 2 Jul 2020 16:04:24 -0700 Subject: [PATCH 05/13] Allow for external stakeholders --- accepted/rfc-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/accepted/rfc-process.md b/accepted/rfc-process.md index 22bfa79..3223bc2 100644 --- a/accepted/rfc-process.md +++ b/accepted/rfc-process.md @@ -18,7 +18,7 @@ The design of this RFC process draws ideas from Rust’s [Request for Comment](h ## Stakeholders -Each core BA project has a formal set of **stakeholders**. These are individuals, organized into groups by project and/or member organization. Stakeholders can block proposals, and conversely having explicit sign-off from at least one individual within each stakeholder group is a sufficient (but not necessary) condition for immediately accepting a proposal. +Each core BA project has a formal set of **stakeholders**. These are individuals, organized into groups by project and/or member organization. Stakeholders can block proposals, and conversely having explicit sign-off from at least one individual within each stakeholder group is a sufficient (but not necessary) condition for immediately accepting a proposal. Stakeholders are not necessarily members of the BA. The process for determining core BA projects and their stakeholder set will ultimately be defined by the Technical Steering Committee, once it is in place. Until then, the current BA Steering Committee will be responsible for creating a provisional stakeholder arrangement, as well as deciding whether to accept this RFC. From 50566a282ce246fd4aa4ae102a6f68aeb158c7b8 Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Thu, 2 Jul 2020 16:12:39 -0700 Subject: [PATCH 06/13] Allow for RFCs to target multiple projects --- accepted/rfc-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/accepted/rfc-process.md b/accepted/rfc-process.md index 3223bc2..ff25d45 100644 --- a/accepted/rfc-process.md +++ b/accepted/rfc-process.md @@ -31,7 +31,7 @@ The process for determining core BA projects and their stakeholder set will ulti * A template markdown file laying out the format of RFCs, like [Rust’s](https://github.com/rust-lang/rfcs/blob/master/0000-template.md) but simplified. * A subdirectory holding the text of all accepted RFCs, like [Rust’s](https://github.com/rust-lang/rfcs/tree/master/text). * New RFCs are submitted via pull request, and both technical and process discussion happens via the comment thread. -* The RFC is tagged with a **project label**, corresponding to the BA project it targets. This tagging informs tooling about the relevant stakeholder set. +* The RFC is tagged with **project labels**, corresponding to the BA project(s) it targets. This tagging informs tooling about the relevant stakeholder set. ### Making a decision: merge or close From 4959225ae6e9b8bd66cb1b9f16703566ebc3d04c Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Thu, 2 Jul 2020 16:15:10 -0700 Subject: [PATCH 07/13] Add tooling details --- accepted/rfc-process.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/accepted/rfc-process.md b/accepted/rfc-process.md index ff25d45..84f677f 100644 --- a/accepted/rfc-process.md +++ b/accepted/rfc-process.md @@ -77,6 +77,10 @@ When should you open an RFC, rather than just writing code and opening a traditi * Changes that could affect mission alignment, e.g. by changing properties of the security model * When the work is substantial and you want to get early feedback on your approach. +## Tooling + +The proposal above assumes the presence of tooling to manage the GitHub workflow around RFCs. The intent is to use Rust's [rfcbot](https://github.com/rust-lang/rfcbot-rs). It will need some modifications to support the proposed workflow; these can hopefully land upstream so we can share the tool with the Rust community, but otherwise the BA will maintain its own fork. + # Rationale and alternatives ## Stakeholder and FCP approach From 807a28e7579281f1edf2c187ac74511f468dbd2f Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Thu, 2 Jul 2020 16:20:55 -0700 Subject: [PATCH 08/13] Increase emphasis on draft RFCs --- accepted/rfc-process.md | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/accepted/rfc-process.md b/accepted/rfc-process.md index 84f677f..379486c 100644 --- a/accepted/rfc-process.md +++ b/accepted/rfc-process.md @@ -36,6 +36,7 @@ The process for determining core BA projects and their stakeholder set will ulti ### Making a decision: merge or close * When discussion has stabilized around the main points of contention, any stakeholder can make a **motion to finalize**, using a special comment syntax understood by tooling. This motion comes with a disposition: merge or close. + * N.B.: an RFC may be closed for reasons of timing or other project management concerns. The project team should make clear under what conditions, if any, a similar RFC would be reconsidered. * In response to the motion to finalize, a bot will post a special comment with a **stakeholder checklist**. * This list includes the GitHub handle for each individual stakeholder, organized into stakeholder groups. * The individual who filed the motion to finalize is automatically checked off. @@ -47,17 +48,13 @@ The process for determining core BA projects and their stakeholder set will ulti ## What goes into an RFC? -RFCs will follow a format inspired by Rust, but significantly simplified. RFCs are markdown files containing the following sections (which will be laid out in a template file): +In general, an RFC is a single markdown file with a number of required sections. Many RFCs should begin as _drafts_, to encourage early discussion about the approach and only a sketch of a proposal. Full RFCs contain a fleshed-out proposal and more discussion around rationale and alternatives. -* **Summary**. A ~one paragraph overview of the RFC. -* **Motivation**. What problem does the RFC solve? -* **Proposal**. The meat of the RFC. -* **Rationale and alternatives**. A discussion of tradeoffs: why was the proposal chosen, rather than alternatives? -* **Open questions**. Often an RFC is initially created with a broad proposal but some gaps that need community input to fill in. +Template files for both draft and full RFCs will be available in the repository root. ### Draft RFCs -It is encouraged to use the RFC process to discuss ideas early in the design phase, before a _full_ proposal is ready. Such RFCs should be marked as [a draft PR](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests#draft-pull-requests), and contain the following sections: +It is encouraged to use the RFC process to discuss ideas early in the design phase, before a _full_ proposal is ready. Such RFCs should be marked as [a draft PR](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests#draft-pull-requests), and contain a markdown file with the following sections: * **Motivation**. What problem are you ultimately hoping to solve? * **Proposal sketch**. At least a short sketch of a possible approach. Beginning discussion without _any_ proposal tends to be unproductive. @@ -65,6 +62,16 @@ It is encouraged to use the RFC process to discuss ideas early in the design pha RFCs cannot be merged in draft form. Before any motion to merge, the draft should be revised to include all required RFC sections, and the PR should be changed to a standard GitHub PR. +### Full RFCs + +Full RFCs are markdown files containing the following sections (which will be laid out in a template file): + +* **Summary**. A ~one paragraph overview of the RFC. +* **Motivation**. What problem does the RFC solve? +* **Proposal**. The meat of the RFC. +* **Rationale and alternatives**. A discussion of tradeoffs: why was the proposal chosen, rather than alternatives? +* **Open questions**. Often an RFC is initially created with a broad proposal but some gaps that need community input to fill in. + ## What requires an RFC? When should you open an RFC, rather than just writing code and opening a traditional PR? @@ -73,7 +80,7 @@ When should you open an RFC, rather than just writing code and opening a traditi * Major architectural changes * Major new features * Simple changes that have significant downstream impact - * Changes that could affect guarantees or level of support, e.g. removing support for a target platform + * Changes that could affect guarantees or level of support, e.g. removing or adding support for a target platform * Changes that could affect mission alignment, e.g. by changing properties of the security model * When the work is substantial and you want to get early feedback on your approach. From c28c70b9d64d9e872c3ba41e5d796c01f7297960 Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Thu, 2 Jul 2020 16:23:29 -0700 Subject: [PATCH 09/13] Discuss stakeholder role at a higher level --- accepted/rfc-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/accepted/rfc-process.md b/accepted/rfc-process.md index 379486c..13b11b4 100644 --- a/accepted/rfc-process.md +++ b/accepted/rfc-process.md @@ -18,7 +18,7 @@ The design of this RFC process draws ideas from Rust’s [Request for Comment](h ## Stakeholders -Each core BA project has a formal set of **stakeholders**. These are individuals, organized into groups by project and/or member organization. Stakeholders can block proposals, and conversely having explicit sign-off from at least one individual within each stakeholder group is a sufficient (but not necessary) condition for immediately accepting a proposal. Stakeholders are not necessarily members of the BA. +Each core BA project has a formal set of **stakeholders**. These are individuals, organized into groups by project and/or member organization. Stakeholders are not necessarily members of the BA. Formally, stakeholder review is required for RFCs to be accepted, and stakeholders can likewise block the process from proceeding. The process for determining core BA projects and their stakeholder set will ultimately be defined by the Technical Steering Committee, once it is in place. Until then, the current BA Steering Committee will be responsible for creating a provisional stakeholder arrangement, as well as deciding whether to accept this RFC. From 6d1307918e783fbe6bebaae77239c329ca82a011 Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Thu, 2 Jul 2020 16:23:47 -0700 Subject: [PATCH 10/13] Clarify FCP length --- accepted/rfc-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/accepted/rfc-process.md b/accepted/rfc-process.md index 13b11b4..f2ca874 100644 --- a/accepted/rfc-process.md +++ b/accepted/rfc-process.md @@ -40,7 +40,7 @@ The process for determining core BA projects and their stakeholder set will ulti * In response to the motion to finalize, a bot will post a special comment with a **stakeholder checklist**. * This list includes the GitHub handle for each individual stakeholder, organized into stakeholder groups. * The individual who filed the motion to finalize is automatically checked off. -* Once _any_ stakeholder from a _different_ group has signed off, the RFC will move into a 10 day **final comment period** (FCP), long enough to ensure that other stakeholders have at least a full business week to respond. +* Once _any_ stakeholder from a _different_ group has signed off, the RFC will move into a 10 calendar day **final comment period** (FCP), long enough to ensure that other stakeholders have at least a full business week to respond. * During FCP, any stakeholder can raise an **objection** using a syntax understood by the bot. Doing so aborts FCP and labels the RFC as `blocked-by-stakeholder` until the objection is formally resolved (again using a special comment syntax). * Finally, the RFC is automatically merged/close if either: * The FCP elapses without any objections. From 1cd3323fddaa7ba7794ff5be23cc95ad6a517eaa Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Thu, 2 Jul 2020 16:25:52 -0700 Subject: [PATCH 11/13] Add open question re: indefinite blocking --- accepted/rfc-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/accepted/rfc-process.md b/accepted/rfc-process.md index f2ca874..96332c1 100644 --- a/accepted/rfc-process.md +++ b/accepted/rfc-process.md @@ -117,4 +117,4 @@ We could instead follow Rust’s MCP model and use Zulip streams for RFC discuss # Open questions -None at this time. \ No newline at end of file +* As written, an individual stakeholder can block acceptance of an RFC indefinitely. In the Rust community, such an arrangement has sometimes caused problems, leading to a secondary process that kicks in after a waiting period, and requires an _additional_ stakeholder to approve continued blocking. Should we consider building in such a mechanism now, or add it to the process only if it becomes necessary later? \ No newline at end of file From c6d22804ed5998958f105db427fd97e57b44d51a Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Thu, 2 Jul 2020 16:28:04 -0700 Subject: [PATCH 12/13] Clarify how process RFCs are approved --- accepted/rfc-process.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/accepted/rfc-process.md b/accepted/rfc-process.md index 96332c1..c16012c 100644 --- a/accepted/rfc-process.md +++ b/accepted/rfc-process.md @@ -88,6 +88,10 @@ When should you open an RFC, rather than just writing code and opening a traditi The proposal above assumes the presence of tooling to manage the GitHub workflow around RFCs. The intent is to use Rust's [rfcbot](https://github.com/rust-lang/rfcbot-rs). It will need some modifications to support the proposed workflow; these can hopefully land upstream so we can share the tool with the Rust community, but otherwise the BA will maintain its own fork. +## Approval of this RFC and future process-related RFCs + +This RFC, and any future RFCs targeting similar process-related questions, will go before the Bytecode Alliance Steering Committee (eventually replaced by the Technical Steering Committee, once that group has been formed). + # Rationale and alternatives ## Stakeholder and FCP approach From d1a7db726f0a418cf317e9cd3ce426f4be829d2c Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Fri, 31 Jul 2020 16:29:16 -0700 Subject: [PATCH 13/13] Revisions to stakeholder concept --- accepted/rfc-process.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/accepted/rfc-process.md b/accepted/rfc-process.md index c16012c..f3a943d 100644 --- a/accepted/rfc-process.md +++ b/accepted/rfc-process.md @@ -8,7 +8,7 @@ As the Bytecode Alliance (BA) grows, we need more formalized ways of communicati There are two primary motivations for creating an RFC process for the Bytecode Alliance: -* **Coordination with stakeholders**. Core BA projects have a growing set of stakeholders building on top of the projects, but not necessarily closely involved in day-to-day development. This group will only grow as the BA brings on more members. An RFC process makes it easier to communicate _possible major changes_ that stakeholders may care about, and gives them a chance to weigh in. +* **Coordination with stakeholders**. Core BA projects have a growing set of stakeholders using and contributing to foundational projects, often from varied organizations or teams. An RFC process makes it easier to communicate _possible major changes_ that stakeholders may care about, and gives them a chance to weigh in. * **Coordination within a project**. As the BA grows, we hope and expect that projects will be actively developed by multiple organizations, rather than just by a “home” organization. While day-to-day activity can be handled through issues, pull requests, and regular meetings, having a dedicated RFC venue makes it easier to separate out discussions with far-ranging consequences that all project developers may have an interest in. @@ -115,10 +115,10 @@ The Rust RFC process has successfully governed the development of the language f That said, a major difference in design is the notion of **stakeholders** and how they impact the decision-making process. Here we borrow some thinking from Rust’s lightweight MCP process, allowing a decision to go forward after getting buy-in from just one stakeholder within a different group -- but still requiring a waiting period to do so. A further innovation is that getting sign off from within _all_ groups immediately concludes FCP. That was not possible in the Rust community, where the set of stakeholders is unbounded. -The most common complaint about the Rust RFC process is that it is, in some ways, a victim of its own success: RFC comment threads can quickly become overwhelming. While this may eventually become an issue for the BA as well, we have some additional recourse: we have a clear membership model which will allow us to prioritize concerns from member organizations, and take action when individuals outside of any organization overwhelm comment threads. +A common complaint about the Rust RFC process is that it is, in some ways, a victim of its own success: RFC comment threads can quickly become overwhelming. While this may eventually become an issue for the BA as well, we have some additional recourse in this proposal: we have a clear stakeholder model which will allow us to prioritize concerns from stakeholders, and take action when individuals who are not formal stakeholders overwhelm comment threads. We could instead follow Rust’s MCP model and use Zulip streams for RFC discussion. However, that introduces a more complex workflow (spanning multiple systems) and leaves a less permanent and less accessible record of discussion. # Open questions -* As written, an individual stakeholder can block acceptance of an RFC indefinitely. In the Rust community, such an arrangement has sometimes caused problems, leading to a secondary process that kicks in after a waiting period, and requires an _additional_ stakeholder to approve continued blocking. Should we consider building in such a mechanism now, or add it to the process only if it becomes necessary later? \ No newline at end of file +* As written, an individual stakeholder can block acceptance of an RFC indefinitely. In the Rust community, such an arrangement has sometimes caused problems, leading to a secondary process that kicks in after a waiting period, and requires an _additional_ stakeholder to approve continued blocking. Should we consider building in such a mechanism now, or add it to the process only if it becomes necessary later?