The Architecture Coordination Working Group would adhere to 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:
Create and maintain the tools and channels needed to connect developers with the stakeholders and subject matter experts needed to make architectural decisions.
Advise on how to publicly discuss, document, and communicate those decisions.
Ensure that the process allows for asynchronous, community involvement.
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.
Next Steps
I’m going to leave this thread open for a week for folks to comment on mission and/or indicate their interest in participating. I’ll put some schedule times in this thread later this week. I’ll try to schedule a kickoff for the week of July 18th if possible, but we might end up in the following week depending on who is interested and what their availability is.
I’m interested in participating as well. I think some of the recent work around Backstage will help us with the future automation of this but I think having an interim switch board is a good idea.
I’m in, and have also asked a few principal engineers at 2U to also join - @ashultz (learning technology) and Alex Dusenbery (enterprise engineering, can’t find his handle to tag 'em).
Hi folks! Sorry for the late update. I just put up a poll for some possible meeting times next week to kick things off. Please take a moment to mark down the times that work for you:
Hello Dave. Thanks for setting this up. I’m late to this topic, but just filled out the poll.
In addition to being interested in general, I am interested in how this all applies to the active event bus work. It was recently requested that we create an Open edX Slack channel for the event bus project, and it prompted a bunch of questions that may or may not fall under the charter of this group:
When and why should a specific Slack channel be created for an area of interest?
Could Slack channel membership, or Slack group membership, be used to learn about interested parties?
Slack is likely to be an entry point (for some users) to learning about different notification channels. Will we want to keep separate notification channels for project status and ADR review?
What will be the best practices for using a project roadmap GitHub issue (or other github issues), or these forums, or Slack for different types of communication? Even if users start in any of these, we may want to redirect to avoid duplication. This should cover both incoming questions and outgoing announcements.
For me, best practices for handling project status announcements has overlap with the more narrowly focused concept of ADRs. Would this group discuss that? If not, who? The Open Source Process WG?
Note: I’m not expecting answers or opinions on this thread, although I wouldn’t stop anyone. These are notes for topics of interest as we move forward.
@robrap: Those are very good questions and I don’t have answers for them yet. I think that they’d make good topics for discussion.
Invites sent for the first meeting to those who signed up for the poll. The kickoff will be on 2022-08-03 (Wed), at 11 AM EDT. (Update: 2022-08-02 (Tue) at 12 PM EDT.) I tried to get as many folks from as many orgs as I could. If you’re interested and the time doesn’t work for you, please keep on the lookout–it’s quite possible the meeting time will shift after this initial kickoff.
I’ll draft a few discussion topics by end of day Monday, but feel free to add things yourself.
Okay, I was just informed that there is an unexpected conflict that will make that time not work for one of the orgs, so I’ll move to one of the other date/times and update this thread shortly. Sorry for any confusion folks.
