RFC is a well-known style of specification, collaboration, and change management. Here are RFCs for the Atlassian Ecosystem.
RFC is a way for Atlassian to share what we’re thinking about with our valued developer community. As such, the ideas presented in this category are not commitments:
- We may not ship anything. Based on discussions here, or internal constraints, we may decide not to ship anything.
- We may not deliver on a specific date. Although we want to provide transparency to our ecosystem, we may need to shift priorities faster than we can communicate about them.
-
We may not deliver exactly as scoped. We may adjust scope as we learn in building out the real implementation. To paraphrase common military wisdom, “No plan survives first contact with the enemy.” Or in this case, first contact with the compiler.
An RFC is a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. While all feedback is welcome, we are mainly trying to obtain rough consensus and identify serious flaws; ideally comments are either 1 or the other. A serious flaw (red flag) is a problem in the RFC which would lead to not achieving the stated motivation of the RFC, meeting the ecosystem’s community standards, or the general goals of the Atlassian ecosystem. A serious flaw needs to be backed by evidence and it will be given deep consideration due to its ability to disrupt Atlassian, App developers, and our mutual customers.
RFCs will be posted by Atlassians. Anyone can comment, following our our developer community participation guidelines. As specialized reminder for RFCs:
- keep it welcoming and safe by commenting on the idea not the people (especially the author)
- keep it tidy by keeping on topic
- empower the community by keeping comments constructive