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.