RFC-20: Atlassian Partner Early Access Program

General Request for Comments (RFC)
1

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!

Summary of Project:

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

Problem

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.

Proposed Solution

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.

Partner Experience

Discovering the PEAP

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.

Announcing New PEAPs

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.

Managing PEAPs

Once signed up, developers will be able to view a list of the planned, current, and closed Early Access features in their Assistant apps.

Key Features:

  • 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.

Additional Considerations:

  • 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.

image-20230707-155742
image-20230707-1557421920×1200 76.4 KB

(example UI)

Collaborating on a PEAP

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.

Asks

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 Access type 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?
18 Likes
2

Love the proposals! Some feedback on your questions:

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

Depends on the EAP, if it’s an EAP relevant for our apps it would be 4-5 not having the EAP access, since we’d be keen to integrate it ASAP and would miss out on giving feedback and potentially changing the way the feature is built. If it’s not relevant for our apps: 1.

    How many Partner Early Access projects do you think you’d engage in at any point in time?

We’re currently engaging in about 1 EAP at any point in time. This might increase if there are more EAPs in parallel in the future with the proposed changes. Probably also depends on the size of the partner and the number of apps where the EAPs are relevant.

    What information would you find essential to know if you should join an EAP?

As much detail as possible, since it’s sometimes a tiny detail that decides if an EAP feature is relevant for us or not. Since those are public EAPs, it would be great to be able to access e.g. tech specs before having joined the EAP and relevant CDAC categories. Otherwise, we would probably join a lot more EAPs just to make sure we’re not missing out on any unexpected benefits, with the downside of being very inactive in most of them.

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”?

The only feedback here would be that ECOHELP can feel very “detached” if we have a direct line of communication to the team responsible for the EAP via CDAC. If ECOHELP should be used for EAP bugs, we should be able to assign those directly to the relevant team. Also, communicating bugs in CDAC would add visibility for other EAP participants, so it would be good if those bugs can be made publicly visible just like with incidents in ECOHELPPUB. Or just use CDAC to communicate bugs and feature requests? Or at least discuss them there first, and only open an ECOHELP ticket after the team asks us to, so they can track it, potentially even after GA?

2 Likes
3

Thanks for kicking off comments @BenRomberg,

Yes, since we’re making it easier for both Atlassians to run EAPs and developer to participate, there might be more of them. What we really want to optimize for is the “information”: the feedback Atlassian teams can get from developers.

We’re thinking along the lines of what Forge does with EAPs; for example, marking the docs for the new Forge runtime as EAP. While we want open docs & CDAC categories, access to the feature itself may be “gated” (by a feature flag) and require an explicit opt-in.

Excellent point! Let me explain that we’re hoping EAPs can help Atlassian teams develop their developer support capabilities while being in a fast feedback loop with developers. The way I see that working is for the Atlassian teams to use the same channels used for GA support: CDAC, ECOHELP, JAC/EAN ticket, changelogs, etc. That way EAP is a practice run for support practices as much as for the code itself.

While I see the same GA channels as your EAP interface, I also see the “mode” of support as different. For the fast feedback loops to work, it should be the Atlassian teams answering your ECOHELP tickets, raising bugs, and putting out fast fixes. As you point out, we do want bug reports to be public, just like for GA. Indeed, a bug reported during EAP may still be relevant into GA, so all the more reason not to use “special case” channels for EAPs. As happens now with GA features, CDAC discussions do sometimes lead to bug reports & feature requests. I don’t see that changing for EAPs.

5 Likes
4

I love the proposal as well. Since the Assistant Apps started my hope was that Atlassian builds visibility of all currently running EAPs into the app!
That makes my life as a developer so much more easy - and if I’m able to opt-in and out of an EAP, I’d also be able to more easily test different cases on my Cloud environment.

To answer some of your questions:

  • 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

I can relate a lot to Ben’s answer. If it affects our apps, it’s a 4-5, if not, it’s more a 1.

  • How many Partner Early Access projects do you think you’d engage in at any point in time?

That’s hard to say so theoretically since they differ a lot in size and required effort. We’d try to at least check out every EAP where we see that it influences our apps.

  • What information would you find essential to know if you should join an EAP?

Which Atlassian products are affected, which REST APIs are changed/introduced, how did Atlassian think about extensibility of the feature

  • What do you need during an EAP in order to make participation useful to you?

Replys to our feedback to understand if our feedback is being considered - or maybe not at the moment which can be also ok. It’s important for us to know which direction the EAP will take.

One improvement I see:

Private EAPs are something Atlassian needs to, at times, rely on to protect confidential information and maximize marketing moments.

I understand that sometimes it’s needed to not open an EAP to everyone. However, I’d encourage you to also run the private EAPs via the Assistant Apps, but have some hidden control on your end e.g. which Cloud instances will see which private EAP.
This helps us partners keeping the overview of EAPs and also keeps the Atlassian teams trained on how to run EAPs. Otherwise, I can see that more EAPs will take the private route than it’s needed.

2 Likes
5

I think this RFC is great and my answers to the questions would be like matthias.
In addition I think it would be good to have at least a simple list (without interaction) of the running EAP in the initial state would be a good help to make EAPs more visible

2 Likes
6

Thanks for taking the time to answer some of these questions, @matthias! It’s helpful to get this feedback. Regarding private EAPs, the solution you’re encouraging is the way we’ve been thinking about it too :smile:

2 Likes
7

Thanks for this feedback @m.herrmann, it’s appreciated!

9

Thank you all for your feedback on this proposal. Whether you replied directly or just decided to hit that like button ( I :eyes: you! ), we appreciate it.

Since no serious flaws were raised in this RFC, if this project continues, it will do so without major adjustments. Stay tuned for an attempt to Early Access our Early Access (very meta, I know)!

A couple pieces of general feedback to highlight:

  • We want RFC participants to be engaged so we’ll keep in mind internal process that manages volume as well as provide clear details about an RFC so developers can triage what’s most relevant to them.
  • There were also questions about the collaboration model. We’ll explore ways we can improve the collaborative loops (feedback channels, clarity on decisions, etc.)
  • Private EAPs will need to exist and we’re exploring how we might make that experience mirror Public EAPs for participants. The suggestion that be done through the Assistant App was our preferred solution too.

Thanks so much!

2 Likes