RFC-1: Request for comments (RFC) as early collaboration with our Ecosystem

This morning, I closed the first “real” RFCs:

While we wait for resolutions on those specific topics, I wanted to reflect a bit on what we learned from the first discussions. Overall, RFCs seem to be going well. Internally, we have additional topics lined up, and we’re creating more guidance as we learn, so each new one will be better and better tuned to a useful collaboration with the developer community. Externally, we had high participation that has lead to genuine learning and improvement.

Constructive input

So far, we have observed some commenting patterns that really pleased us. We saw a lot of examples of constructive comments. The following reflects some of the engagement patterns that were really helpful.

  • Asking for more clarification in areas where commenters need to understand more. We might not have the details now, or be ready to provide them while the RFC is open, but your questions will help us to write better RFCs over time and to know what we need to answer before we finish a project.
  • Suggesting what would make a problem worth solving.
  • Suggesting better solutions, or enhancing with your ideas about how to create more value.

Votes and vetoes

We saw some engagement that framed RFCs as the means to “veto” an idea. Clearly, that reflects the guidance I provided in “How to write good comments?” However, RFCs need to reflect “a bias for action”: here’s a problem; what can we do together to find a solution? While we’re utilizing some democratic methods to explore those topics, the ultimate decision lies with the author, not a vote from the community. To clarify our intent, RFC is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.

Prioritization

In recent discussion, I asserted that “priorities are out of scope”. While the RFC problem statement should convey value (and hence a sense of priority), meaningful discussion of priorities (plural) demands a discussion of relative trade-offs. For the RFCs, we’re not ready to have that conversation when we haven’t yet made enough work visible to discuss sequencing. Even when we achieve greater transparency as more projects get an RFC, there are still trade-offs that remain internal to Atlassian. Therefore, we assert that RFCs should be treated as independent of each other and that relative prioritization is “out of scope” in the RFC threads. Please keep the RFC comments to negotiating toward the most valuable thing to build.

We can have relative prioritization discussions based on other sources, in other categories. For example, it is valid to bring up the prioritization of our Cloud Roadmap or Forge Roadmap. In time, we hope the RFC process is so widely adopted that every RFC lands on a roadmap, and that we can have a discussion of priorities about the roadmap.

Proposed revision: How to write good comments?

Good comments focus on identifying serious flaws and providing constructive feedback. Participation should follow the developer community participation guidelines . We especially call out the need to keep conversation welcoming and safe by commenting on the idea not the people (especially the author). Keep it tidy by keeping on topic and respond at the appropriate level in the thread. If you are going to comment about the RFC itself, respond to the top level. Please, keep comments constructive to help empower the community. Even serious flaws should be explained in ways that help drive better outcomes for the community.

While the RFC problem statement should convey value (and hence a sense of priority), meaningful discussion of priorities (plural) demands a discussion of relative trade-offs. RFCs should be treated as independent of each other and that relative prioritization is “out of scope” in the RFC threads. Please keep the RFC comments to negotiating toward the most valuable thing to build.

  • Ask for more clarification in areas you need to understand better. We might not have the details now, or be ready to provide them while the RFC is open, but your questions will help us to write better RFCs over time and to know what we need to answer before we finish a project.
  • Suggest what would make a problem worth solving.
  • Suggest better solutions, or enhancing with your ideas about how to create more value.
7 Likes