RFC escalation policy

@ibuchanan @Anthony,

As part of RFC-29 I’ve asked what the process is for escalating an RFC:

That comment got flagged as off topic, which I can understand, so I started this new thread. Looking forward on your input.



Per RFC-1 which defines RFCs, there isn’t an RFC-specific escalation path. Indeed, your argument from suboptimization applies here: I don’t want to establish an escalation policy for 1 practice, when the problem described (suboptimization) applies equally to early access programs, change logs, deprecations, or any other changes to the ecosystem. Generally speaking, there never has been something I can point to as a formal escalation process but it has been and remains an option to open a developer support ticket and ask for management conversation. There are also many other paths to reach management, including DMs here in CDAC.

That said, I don’t know that your appeal to suboptimization is appropriate for the case of ARIs. Custom URIs are nothing new to the internet. AWS, Azure, and Google all expose some form of URIs, many of them custom. If we had the “architectural committee or something” to which you might appeal, I suspect we would have switched to ARIs much earlier, rather than the other way around.

I think you anticipated my assertion given your 2nd point, “unless there would also be a plan to migrate other parts of the Atlassian event system.” And, I think the problem is really with IDs in general because an event is likely to trigger the need for additional queries, and you’re saying the overhead of ID switching is intolerable (at least in the long-run). On this point, let me confer with @JustinThirkell (who is an architect) and we’ll respond within a week.

In the meantime, I think there is an implied “conservative plan” wherein we would only introduce ARIs when we have no other choice, so as to minimize the disruption to current API clients. Thus, the burden is on new APIs (like those described in RFC-29) to provide bridging. It’s clear from your line of reasoning that you either think that we have another option or that you don’t believe in this “conservative plan”. Perhaps you could elaborate on why you are pressing for a more explicit plan?

1 Like

Hi @ibuchanan ,

Please not that the issue that I’m trying to escalate is the introduction of Cloudevents, not ARI.

I’m not against ARI per se, the problem is that it is not documented anywhere and is not accepted by any other REST endpoint. But I’m sure @JustinThirkell will give us the required context of how to use ARI and how to map it back to an identifier that we can use in other REST API’s, as part of his answer to: RFC-29: App Access Rule - Revised followup to New Data Access APIs - #7 by remie

However, the issue with Cloudevents is a lot bigger, and as noted in the comments of RFC-25, a lot of partners have voiced their concerns against the introduction of yet another format for events.




Ah, thanks for clarifying that you’re more concerned about CloudEvents. I’ll focus on this in discussion with @JustinThirkell. That said, I know that Justin had considered that in the change from RFC-25 to RFC-29. He wrote:

We’ve noted Partners’ concerns about the use of another standard and potential complexities involved. We are nevertheless comfortable that aligning event schema to the Cloudevents specification should be largely transparent, with negligible impact on Partners. We know that Atlassian lacks consistent standards for error statuses and messages (including event metadata) across our public APIs, and we recognise this is a longstanding pain-point for developers, particularly developers attempting to build resilient apps against APIs they have not worked with previously. We believe use of a standard to consistently represent event metadata can only be a good thing. We’re choosing to use a mature public standard here because we believe it is fit for purpose and prefer to adopt a public standard where possible.

As I check-in with Justin, let me confirm the following concerns:

  • The solution should not be a new format. Other webhooks are JSON.
  • The solution should not be a new protocol. Other webhooks are sent as HTTP (more or less: Forge events look close enough).
  • The solution should not require a new library or framework. ACE, ACSB, and Forge Runtime are plenty.

If CloudEvents were only a layer of schema over HTTP + JSON, that should satisfy the requirements (expressed in prior comments), right?

@ibuchanan I think the RFC’s intention are good. However there have been cases where it feels like it’s a rubber stamping approach. This is obviously not your (and Atlassians) intention with it.

Part of it is that communication is happening in stages. It’s all in the forum. It would be awesome if each RFC had surveys attached to them (“Did you feel listened to?”) and somebody at Atlassian followed up on those surveys. Also, I would encourage RFC authors to talk to folks that have issues so that they can follow up on them. The new-shiny disease is flaring up at Atlassian so those types of things would help to make the partners concerns understood properly.


Hi @ibuchanan, @remie,

I have added a reply to this thread - but I have done so in the RFC itself, rather than in this thread which is about how/where to escalate RFC concerns. To continue the conversation about Cloudevents specifically, let’s keep it over there. :slight_smile: