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

[remie]

@JustinThirkell

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.

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

In this case, the majority of partners that responded to the previous RFC said that they were against using Yet Another Standard unless there would also be a plan to migrate other parts of the Atlassian event system. Atlassian has decided to move forward regardless of our concerns, which means that I would like to know if there is any arbitration process available for partners.

EDIT: this post was flagged by the community as Off Topic, which I can somewhat understand. I have created a new topic for this but I hope it can stay here as I would like to maintain context. Also, once the policy is clear, I do want to apply it to this RFC, making it somewhat on-topic again.