RFCs are a way for Atlassian to share what we’re working on with our valued developer community.
It’s 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. It 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.
Please respect our community guidelines: 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. Thanks!
We’re working on a Partner Early Access Program to share and collaborate on features early with our developer community. This program will help Atlassian and its Partners stay aligned and deliver more value, faster to our Cloud customers.
- Publish : Aug 11, 2023
- Discuss : Aug 28, 2023
- Resolve : Sep 5, 2023
Atlassian is constantly releasing new features to its Cloud products. When we ship these features, it has the potential to impact our app developer Partners and the Customers who rely on them. The earlier we can bring Partners along on that journey, the lower risk of that impact.
Today, Atlassian has no accepted standard for when to provide early access to new features to our developer community, where developers can learn about new features, and how they can engage with early access features (develop atop of, provide bug reports, etc.)
For our Partners, the lack of standards prevents visibility into what is changing, where to provide feedback, and how to meaningfully contribute. In situations where they are given the opportunity for access, it’s a bespoke and somewhat manual process. When developers are not given access, they’re playing catchup when Atlassian finally ships these new features. This increases likelihood Partners are missing needed capabilities to deliver value to customers or will be impacted negatively when released.
For our Customers, the lack of coordination between Atlassian and its Partners can mean, at best, delays in new value to their Atlassian products and, at worst, broken experiences with apps the rely on. Customers expect Atlassian to coordinate major changes with our Partners to provide a more seamless experience.
For Atlassian, the lack of a standard for how we run early access means that many teams can’t effectively engage with developers because it’s high-friction. For those who try to leverage existing solutions, the fragmented process diverts resources away from delivering the friction.
Atlassian’s continued company, customer, and partner growth, make scaling early access a high priority.
First, prior art. There are existing solutions that address various parts of this early access problem:
- Developer Community EAP: Atlassian has an “Early Access Program” category with EAP subcategories that participants can join and discuss the upcoming feature. This provides value in initiating and engaging in conversation around the upcoming feature.
- Requests for Comments (RFCs): like this one, were launched earlier this year to solicit early feedback from developers. The solution has proved useful in incorporating the Partner voice earlier in product development but does not extend well to once the feature is being built. RFCs don’t provide close coordination and technical access.
- Developer Canary Program: In 2022, Atlassian launched Developer Canaries to progressively roll out new features to developer instances prior to them being released to customers. It relies on two Assistant apps - for Jira Cloud and Confluence Cloud - to identify the instances to roll GA features out. This has been very successful though mostly in ensuring changes don’t break instances at GA, which is too late for developers to meaningfully collaborate on the feature.
- Developer Changelog: In 2022, Atlassian also launched the Developer Changelog which created the standard types and a dedicated location for various change-type communications.
Our proposed solution - the Atlassian Partner Early Access Program (PEAP) - will leverage and lean into the value of these existing solutions while providing additional features to form a cohesive program.
This Program will deliver both internal guidance on how and when to run EAPs as well as provide tooling to make it far easier for Atlassian teams to create and manage their EAPs.
The program will be publicly discoverable by developers - potentially in developers.atlassian.com - where information about the program (participating products, how to get started, etc.) will be shared. Joining the program will require an Atlassian account, installation of the relevant Assistant apps (the same as used by the Developer Canary Program), and agreement to program terms and conditions.
New PEAPs will be announced using the existing Developer Changelog under a new
EARLY ACCESS change type. Developers will be encouraged to subscribe to the Changelog to discover recently announced EAPs.
Once signed up, developers will be able to view a list of the planned, current, and closed Early Access features in their Assistant apps.
- Developers can identify and find EAPs relevant to them (search, product logos, status)
- Developers can read descriptions and the linked technical documentation to learn more about the EAP and how the feature works.
- Developers can activate the feature on their developer instance.
- In future milestones we will likely want to deliver a dedicated UI, outside of the Assistant apps, to discover and activate EAPs. Leveraging the existing apps allows us to deliver PEAP much more quickly and iteratively.
- Private EAPs are something Atlassian needs to, at times, rely on to protect confidential information and maximize marketing moments. The initial version of this program will focus on support for EAPs that are public and open to everyone. We expect to be the default type.
After sharing access to the feature and its documentation, it’s essential that Atlassian team receive helpful feedback from developers while in early access. To do this at scale, we’ll automatically create a new CDAC category for each EAP where developers in the EAP can engage directly with the Atlassian team working on the feature through threads within that category. Our solution will explore other ways we can encourage collaboration during early access.
For this Program to be successful, we need this to work for both Atlassian and our Partners. We’re keen to learn more about:
- Whether you see any serious flaws in this RFC that would prevent the program from succeeding?
- Beyond serious flaws, we’d like to get feedback about the amount and fidelity of information shared by the Atlassian teams:
- On a scale of 1-5 how painful is not having early access to new features for your you teams, with 5 being the most painful
- How many Partner Early Access projects do you think you’d engage in at any point in time?
- What information would you find essential to know if you should join an EAP?
- What do you need during an EAP in order to make participation useful to you?
- Is a new
Early Accesstype helpful or would you prefer to see a different Changelog type used?
- As a community, you’ve asked us to standardize channels. We believe the best way to support EAPs will be with the same channels as GA: DAC, Changelogs, CDAC, Statuspage, and ECOHELP. The benefit to this model would be continuity: EAP docs become GA docs, CDAC questions from EA inform consumers for GA, and bugs found during EAP are still bugs in GA, and even if the SLOs are different for EAP features, you’ll still need incident comms in Statuspage to know if they are broken. However, early access is necessarily more mutable than GA and could swamp these channels with noisy updates. How do you think we can strike a good balance between “standardizing channels” and “keeping them useful”?
- We’re planning on building PEAP in a mode of API-first. We’d be interested to hear high-value use cases our developer community would have for a PEAP API. How would you use a PEAP API?