Ben W: How should we review/communicate changes in platform that affect other developers across teams?
How can we make it easy for people to find changes that have happened?
The Organization table is now enabled by default in devstack → that impacted other teams.
ADRs? → they get posted in #adr-notifications
Easy to reference via Repo
Timely via Slack
Good for when we know we were going to break stuff.
What about for oops I broke stuff?
Can we write the ADR when we did break stuff?
An alert when default settings changes.
This might produce more noise as there will be other kinds of change.
We could have added an entry to the changelog even if we didn’t know we were going to cause a breakage.
Arch tea-time? (please no)
Not an arch topic.
Arch tea time is not a high reach meeting.
Monthly Arch Standups have a specific question on “Impacts on other teams”.
Data retention for slack is less than 6 months. Not great for long lifetimes.
Use Reacji to tag announcements as breaking changes.
Deals with timeliness but not keeping history.
Could this have also been in #how-to? (existing channel)
Use semantic-release and semver to record (expected) breaking changes
How can we improve our culture of async communication? +4
What is preventing wider adoption of discourse?
We don’t have a culture of aiming discourse discussions at specific people.
Higher pressure to use this because you’re speaking on behalf of edX
We don’t need to be perfect for the community, don’t feel like we have to.
Don’t use for internal edX Work
Levels of Async Comms
Slack - really more like synchronous comms.
Async doesn’t really work because it rolls off the top.
What are we trying to communicate?
Anything where you wanted to involve the community.
Are there concerns about leaking plans/features as a part of architectural conversations in discourse?
Complex relationship with Open edX because it’s unclear what enterprise capabilities should be public to Open edX.
Is there a difference between tagging a repo vs making it an official part of Open edX?
OEP 10 makes these distinction. We don’t really differentiate between Included/Supported.
Is it installed as a part of our supported installation?
We will fix the build for anything that breaks the build(Supported not just included.)
Will moving to distributed devstack make the distinction less relevant?
Private requirements might break this as well. Some things might not work without integrating with the same 3rd parties as us.
It seems like we want a distinction between public vs will actually work in an opensource context.
Similarly we want to be clear about will work vs we are accepting contributions.
React - Discussions Forum - editor input - draft JS
Branding: How can we keep branded edX Strings separate from the open source code (right now English string values are also edX-branded string values) +1
Future (when folks are not on PTO)
Q&A with Feanil on Inter-service Eventing
Type hinting: Do we want it? Everywhere or just in APIs? etc?
Shopping cart deprecation with Diana
lessons learned, knowledge sharing on dead code, etc.