...

• Ben W: How should we review/communicate changes in platform that affect other developers across teams?

...

• • Variant

    • How can we make it easy for people to find changes that have happened?

  • Problem example

    • The Organization table is now enabled by default in devstack → that impacted other teams.

  • Ideas

    • 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?

          • +1

    • An alert when default settings changes.

    • DEPRs

    • Changelogs?

      • 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)

      • No because

        • 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”.

    • Slack

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

      • +1

      • 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

  • Idea: Discourse

    • 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

    • Immediate

      • Slack - really more like synchronous comms.

        • Async doesn’t really work because it rolls off the top.

    • Eventual

      • E-mail

      • Github

      • Wiki

  • What are we trying to communicate?

    • Architectural topics?

    • Anything where you wanted to involve the community.

    • Are there concerns about leaking plans/features as a part of architectural conversations in discourse?

    • Enterprise

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

    • Private

    • Public

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

Backlog of Questions/Discussions

• 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 EventingObservability with Robert

  • What are your biggest pain-points?

  Any we should dive into (e.g JS Error alert fatigue)

  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.

• Are detailed commit messages controversial? +2