Topics

• How to get Open edX community involved in decentralized devstack discussions and development?

  • @Jinder Singh (Deactivated) will post in the Open edX Slack #architecture and on discuss.openedx.org to gauge interest and inquire about discussion venue preferences

• What should be the interface for Decentralized devstack +6

  • slack discussion about this

  • options:

    • mimic current devstack (create a make interface for dd)

      • pros

        • open-edx developers already know this

        • something to standardize around (external example: make upgrade)

        • reduce verbosity or minimize typing and memorization

      • cons

        • by wrapping, you mystify what is actually happening

        • to debug, you will need to know underlying commands already

        • doesn’t decrease memorization and verbosity all that much

        • this allows you to hide bad complexity and makes it easier to procrastinate on proper maintenance

    • Rely on docker’s interface and create a how_to explaining necessary commands

      • pros

        • industry standard (a loose analogy to git can be made)

        • would lead to better debugging experience

        • most common docker commands are not that verbose

      • cons

        • slight increase in verbosity and you will need to know docker well to develop

    • mixture of the two

      • create only make targets for commands that are too long

      • create a how to doc with commonly used docker commands

        • make it easier for new developers to get started with coding

  • Comments in meeting

    • makefile makes discovery for useful commands easy

      • can create make targets that echo useful information about how to use the underlying docker/docker-compose commands

    • wrapping thing in make

      • bad: developers don’t learn docker, so often they self develop tools in make which can be done through docker

    • having developers use docker commands directly allow developers to come up to speed on docker

      • longer term benefit

    • new edx developer experience: having make wrapper disincentivized digging under make command to see what was happening

    • it might be a good idea to change names of make targets to make them more understandable

    • we can add better defaults in the docker files themselves

    • Makefile consistency across services would be a non-issue if we use docker-compose directly

    • Lesss maintenance if we don’t use Makefiles.

  • Experiment with Aperture team - @Matt Tuchfarber (Deactivated)

Backlog of Questions/Discussions

• Open edX community participating in our architectural work +4

  • Loci: Slack, tea-time, https://discuss.openedx.org, pull requests, OEPs, ADRs

  • What would success look like?

  • What has to change to make it happen?

• Observability

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

• MFE with Luca follow-ups ?

• React - Discussions Forum - editor input - draft JS

• Open edX

  • joining us at 1x a month Arch Tea

  • Shared slack channels

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

• Shopping cart deprecation - lessons learned, knowledge sharing on dead code, etc.

• Q&A with @Feanil Patel on Inter-service Eventing