RFC escalation policy

[remie]

@ibuchanan @Anthony,

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

RFC-29: App Access Rule - Revised followup to New Data Access APIs

@ibuchanan, can you please outline the process for escalating an RFC? As mentioned on other RFC threads as well, individual Atlassian teams make overarching decisions that might seem logical to them as a team (and often involve a New Shiny Thing ) but erode the trust in the system architecture as a whole. It would be great if we could somehow signal this to a higher level, some sort of architectural committee or something, which would be able to override these decisions on behalf of the p…

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

[ibuchanan]

@remie,

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?

[remie]

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.

See

@remie

Would it be possible for Atlassian to pretty pretty pretty pretty pretty pretty pretty pretty pretty pretty pretty pretty pretty pretty pretty pretty pretty pretty pretty pretty please not introduce Yet Another Shiny New Technology?

Why does Atlassian think that partners are happy with having to support a different type of format for events compared to Connect install hooks or product events specifically for App permissions?

@andreas.schmidt

1000x this.

Also looking at the greater context:
The whole purpose of this feature is to allow apps to have a great user experience when data access is disabled. When it is hard to implement, very few apps will implement. See Dark Mode as a reference

@JulianWolf

Like @remie, while reading, I was surprised that you want to introduce CloudEvents for those new kinds of events. I am not really opposed to that approach but would expect that this is part of a greater plan in which Atlassian changes the whole Connect & Forge event infrastructure to this new format.

@tobias.viehweger

Agree with @remie - this is not great, especially having logic to handle binary formats, for payloads that a re <2kb? Why not just use normal webhooks.

@danielwester

I agree with @remie here (and everyone else) - please don’t add yet another “atlassian standard” approach. It will mean that we’ll be less likely to adapt to this and in a year after launching Atlassian will be introducing programs/incentives of how to get people to make use of this.

@jbevan

What factors did Atlassian include in its determination that “this is an opportune time” for app vendors to adopt CloudEvents?

I’d contest your comment about CloudEvents being a mature standard by quoting their own website:

CloudEvents is a new effort and it’s still under active development. However, its working group has received a surprising amount of industry interest…

Please can you provide more information about Atlassian’s decision to roll out support for CloudEvents across the entirety of the existing webhook mechanism including timeframes?

@tobitheo

I also do not think it necessary to add another (self-proclaimed!) standard to the mix, especially when it requires its own SDK to be used. IMO, the current webhooks implementation is sufficient. Unless you’re telling us that you want to migrate all webhooks to this, I’d like to rather avoid it. It adds unnecessary complexity. If you were to avoid the binary format, my acceptance might be higher, because it looks like it may be usable without an extra dependency then, but I still think it’s unnecessary.

@AndreasEbert

Point 1:
I can give a +1 to pretty much all concerns raised by other app vendors. Using additional APIs/standards increases technical complexity on our (app vendor’s) side. Please only do this for good reasons.

[ibuchanan]

@remie,

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?

[danielwester]

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

[JustinThirkell]

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.

RFC-29: App Access Rule - Revised followup to New Data Access APIs

This reply is in response to ongoing expressions of concern about Cloudevents. In conjunction with the explanatory note about Cloudevents in this RFC I will explain by way of example show how the use of Cloudevents should be completely transparent to Partners, who should be able to work with plain json objects as usual. Schema diff If we were to ignore Cloudevents entirely (while still including event schema properties we feel are desirable), an example AppAccessToObjectsBlocked event would lo…