RFC escalation policy

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