Arch Tea Time: 2020-08-27

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 (Deactivated) on Inter-service Eventing