Document the community RFC process #116386
Conversation
This adds documentation about how the community RFC process works, based on how the community typically runs RFCs. The goal is to roughly document the process as-is and then post a follow-up explaining how the new governance model ties in to the RFC process. From there, we can discuss any changes to the process we would like to make via... an RFC.
AaronBallman
requested review from
cyndyishida,
dwblaikie,
echristo,
llvm-beanz,
rnk and
tstellar
There was a problem hiding this comment.
There should probably be an RFC / discourse thread for this?
At least the acceptance process described here doesn't match existing practice, at least for LLVM. I don't think I've ever seen an LLVM RFC being explicitly accepted or rejected by someone on Discourse. Instead RFCs essentially get accepted by dint of the implementing PR being approved.
I do generally like the idea of making RFC acceptance/rejection more explicit, but I don't think we can frame that as documenting existing practice.
I think that's the second stage of this where we try to make changes to the existing process to make it better. I worry that a Discourse thread would be unproductive (and an RFC would be confusing as this isn't really trying to propose changes).
This is the existing practice in Clang, so it can be framed this way to some extent IMO. That said, I can relax the wording to not say "explicit" about acceptance. Would something along the lines of this make you more comfortable?
|
|
Hi folks, do we wish to push this PR to main/gather more feedback? |
Thank you for reviving this thread, it fell off my radar entirely! I've rebased the PR and made some modifications to hopefully address the concerns from @nikic. |
|
In #136198 , I rewrote a section of the developer policy to try to cover RFCs. Aaron reviewed it. :) Blame says the original text was by @isanbard , but I retitled the section from "Making a Major Change" to "Proposing Major Changes (RFCs)" to try to capture most of what you added. I think it's worth splitting our the RFC process into it's own doc, but I want to make sure everything is cross-referenced and to incorporate any ideas or insights I had into the new doc. |
| If the proposal gets little or no engagement by the community, it is a sign that | ||
| the proposal does not have consensus and is rejected. Engagement means comments | ||
| on the proposal. If there are few or no comments but the are a lot of people | ||
| pressing the like/heart button on the post, maintainers can make a value |
There was a problem hiding this comment.
Since you wrote this, now we have area teams who are formally responsible for reviewing RFCs to determine if they are wedged. I'd say it's up to the relevant team to make the determination between "no objections, this seems like something obviously good in our judgement, let's do it" or "it seems like there's no interest, and the costs are significant, so we shouldn't do it, unless there's further interest."
5 participants
This adds documentation about how the community RFC process works, based on how the community typically runs RFCs. The goal is to roughly document the process as-is and then post a follow-up explaining how the new governance model ties in to the RFC process. From there, we can discuss any changes to the process we would like to make via... an RFC.