RFC process proposal #1
Conversation
tschneidereit
requested review from
tschneidereit,
alexcrichton,
bnjbvr,
joshtriplett and
npmccallum
There was a problem hiding this comment.
This looks and sounds great to me, thanks so much for writing all this up and brainstorming all of this!
The evolution of Rust's RFC process with a "stakeholder" feels pretty good to me in the context of the BA. I think it should provide us a way to have helpful design discussions without feeling the process just drags everything to a halt.
accepted/rfc-process.md
Outdated
|
|
||
| # 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. |
There was a problem hiding this comment.
There's a formal proposal for the MCP process at rust-lang/rfcs#2936 ; I would suggest linking to that.
Also, please expand "RFC" and "MCP" on first use; I'd suggest formatting that like this: [Major Change Process](...) (MCP).
There was a problem hiding this comment.
I'll expand the acronyms 👍
Re: the MCP link, I'd prefer to keep it pointed at the official documentation on the Forge, which post-dates the compiler team RFC (which was accepted a while back).
|
|
||
| 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 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. |
There was a problem hiding this comment.
Do we expect the stakeholder set to be completely unbounded in number? If so, can we say that explicitly? If not, how do we handle that?
There was a problem hiding this comment.
I'm not sure what you have in mind about "unbounded in number" here. I don't foresee a hard limit on the stakeholder count, but rather a policy around stakeholders that naturally results in a reasonable upper bound in practice. For example, a likely criterion for formal stakeholdership is being a major contributor to the project itself, a number which is likely to be self-limiting for other reasons.
All that said, I'm also wary of trying to specify too much about the stakeholder determination in this RFC, preferring to treat it as a modular detail ultimately owned by the TSC.
accepted/rfc-process.md
Outdated
|
|
||
| # 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. |
There was a problem hiding this comment.
Same comment as in the summary about where MCP links to.
|
|
||
| * 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. |
There was a problem hiding this comment.
I would suggest that our process should take inspiration from the current direction of Rust processes, and start with a more MCP-like template (focused on the problem statement and not just the proposal). There may also be value in adopting the processes for assigning a liaison, and having the option of designating a project group to shepherd complex proposals.
There was a problem hiding this comment.
So, it seems like a point of confusion here is that there are multiple notions of "MCP" in flight in the Rust community. There's the existing one for the Compiler team, which doesn't even have a problem statement section, and the one in the works for the language team.
I think what'd be helpful here is to get more concrete: is there something about the template, or some other part of the process, that is underemphasizing writing about the motivation?
Note also that there's an explicit separate template for early-stage ("draft") RFCs that pretty closely resembles the proposed Rust Lang Team MCP template.
re: liaisons and project groups, my feeling is that we are probably too early on in the BA for those ideas to apply well. (In particular, the total group of people writing or consuming RFCs is likely to be quite small at the outset, compared to where Rust was even back at the 1.0 days). I suspect that we'll want to evolve the RFC process over time as the unique needs of the BA become more clear.
There was a problem hiding this comment.
I agree that establishing processes for liaisons and project groups would be premature at this point. I could easily see a need for either or both in the future, but by then we should have a well-functioning TSC which can drive establishing those parts of a process.
accepted/rfc-process.md
Outdated
| * 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. |
There was a problem hiding this comment.
I like this very much; it's a good balance between "FCP starts right away" and "FCP doesn't start until almost everyone has signed off". It seems like a good fit given the other changes we've made to the process.
|
As a purely administrative matter, Mozilla is closed all of next week, so the timing is not fabulous for those of us who have not seen this previously. |
Ah, thank you for raising that. Would keeping the PR open until at least the end of the week after next address that issue? |
|
Yeah, should be fine. |
|
I do think there's value in defining at least the skeleton of further process for stakeholder disagreement now, rather than the first time we need it (when tensions and stakes may be higher); evidence from other communities (such as Rust) suggests we will eventually need it. (For the sake of clarity: this is not a blocking concern, just a suggestion for further revision. I think there's value in signing off on the RFC as written, and we can always sign off on a future revision as well.) The RFC as written looks good to me. Thanks for driving this, @aturon! |
|
@tschneidereit, I'm fine with the proposal but I don't think I have write permissions here and can't record the vote directly. |
|
|
||
| # Proposal | ||
|
|
||
| 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. |
There was a problem hiding this comment.
Is it expected for this process to deviate from Rust's one? In case of if either process changes, the statements "like Rust's" or "similarly to the one in Rust" might become incorrect. Is it possible to point this proposal to specific version of Rust's RFC process?
There was a problem hiding this comment.
Good point that those processes might change, and that these references might become stale as a result. I think that that's fine though, since over time it'll also become less important to be able to anchor expectations to related processes in other communities. But we could certainly include more stable links here; would you be up for looking them up, @yurydelendik?
Thank you for raising this, @joshtriplett. I agree that we'll need this, but there's a tradeoff between trying to get all related processes in place and getting this core process formally instated. We should certainly not put it off indefinitely :) I filed #6 to track this. |
Entering Final Call PeriodSince we have sign-off by members of multiple stakeholder groups and no blocking concerns have been raised, I'm moving this RFC to Final Call. That means it'll be merged in 10 days from now, or once the remaining stakeholder groups have signed off on it, provided no blocking concerns are raised in the meantime. |
|
I received a sign-off from the last missing stakeholder group in private message, so we have full approval, in addition to the 1-day FCP having lapsed :) With that, I'll merge this PR, at which point the RFC process is formally instated. |
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 and MCP processes to the Bytecode Alliance context.
Rendered proposal text