How about a repo with a file per RFC in Bitbucket? Pull requests for changes. Cant get more transparent than that. Plus supports markdown.
[RESOLVED] RFC-1: Request for comments (RFC) as early collaboration with our Ecosystem
This approach wouldn’t result in a notification being triggered to thread participants. Maybe worth changing this to unlock a thread and have the author post an update then re-lock?
On schedule this time, I’m closing RFC-1. With 963 views as of today, we again nearly broke 1000! There were 75 likes and 10 commenters contributing 22 comments. With this “meta RFC” and some real topics, we learned a lot about how Atlassian can better leverage the developer community in better planning. I’ll be preparing a resolution to this topic over the next couple weeks. I need time to digest all the feedback but I’m certain that we’ll want to make a revision of this practice. Please stay tuned for resolution or before 24 March 2023.
What did we hear?
The RFC itself is very “meta”: it attempts to model what it describes. As such, it would be awkward to separate this resolution from the experience across all the RFCs so far.
- On the whole, we heard these RFCs are needed and useful. Indeed, an immediate question was how to get wide-spread participation, a la, “how will the Atlassian team know when to raise an RFC?”
- Hopes that governance would create more transparency. Even with this published RFC live, we have had some community threads that maybe should have been RFCs.
- So far, RFCs have been shallow on explaining the paths not taken; we’re not conveying “the chain of thought that led to the proposed solution”.
- Tracking changes to RFCs. The community needs to know when things change and quickly catch up.
As a community, I ask that you support our effort to spread this practice and that you keep prompting for RFCs.
What did we change?
While the RFCs were in discussion, we wrote additional internal guidance to supplement this public document. We recognize some flaws remain and simply ask that you do what feels natural. We will make improvements but we need more experience to drive appropriate prioritization.
What is coming next?
Even with these known but not serious flaws, we will continue with the RFC process. Having this RFC category in the community is better than not. We would like to have experience from 10 or more RFCs before we look at both process and technical improvements. If we don’t hit 10+ RFCs by June, we need to have a hard look at why. So, either way, please expect an RFC-on-RFC revision in June.