Architecture Coordination Working Group


The Architecture Coordination Working Group aims to implement the vision of OEP-56, which advocates for a strongly decentralized architecture decision making process. As such, this working group's purpose would be to:

  1. Create and maintain the tools and channels needed to connect developers with the stakeholders and subject matter experts needed to make architectural decisions.

  2. Advise on how to publicly discuss, document, and communicate those decisions.

  3. Ensure that the process allows for asynchronous, community involvement.

  4. Ensure that teams feel empowered to commit to decisions in a timely manner.

The working group has "Coordination" in the name to make it explicit that this body does not make architectural decisions for the Open edX Platform–not even "wide reaching" ones, like REST API conventions. ACWG will not review the substance of architectural proposals, and will not debate these issues in its meetings. Depending on who the stakeholders and subject matter experts are, these sorts of discussions may occur in various other working groups (e.g. Frontend, Data, Build-Test-Release), or in ad hoc groups formed around specific initiatives (e.g events, message bus). Wherever possible, we want to empower individual implementing teams to make the final decisions.

In the short term, this body will act as a sort of manual switchboard to find the domain experts and stakeholders needed to have the architectural discussions described by OEP-56. If your team is considering a change that will have cross-team impact, you will be able to bring your idea as an agenda item to this working group. Note that this is a service, not a requirement. If you already know the stakeholders and domain experts relevant for your discussions, by all means just contact them directly and put your discussions in a publicly accessible space. This working group is intended to be a helpful resource, not an extra hurdle.

In the long term, the goal would be to push as much as possible into documentation and tools (e.g. Backstage), so that manual routing is unnecessary most of the time.

Child Pages