Topics

• Jeff has an a11y wishlist - communicate with you directly via slack or email

  • Examples

    • LMS video player enhancements

    • Audio description service integrations and enablement with our partners

    • Studio items

• Workshop-based review of https://www.thoughtworks.com/radar

  • Anything that stands out as possible things for edX to consider for ourselves?

    • Adopt of Remote pairing - apply to edX?

      • Can we set up an experiment to develop best practice for edX?

  • What do folks think about this form/tool as a means of visualizing decisions?

    • Nit: the term “Hold” doesn’t say, “don’t do” to me, it sounds like “Keep this thing”

    • Promoted a level of discovery

    • They may be cheating - with somethings starting in adopt without an assess state

    • There is a mish-mesh of categories: ML, service-mesh, etc

    •  

• Time permitting, workshop-based review of edX Radar posted in https://github.com/edx/open-edx-proposals/pull/61

Notes from breakout room:

• Interesting Automated Security Tools

  • https://github.com/liamg/tfsec

  • https://github.com/nccgroup/ScoutSuite

• It looks like istio is the choice from thoughtwork re: service mesh

• Development Environments

  • https://www.gitpod.io/

The radar has been looked at before, but nothing significant regarding radar before.

Use case for radar at edx:

• It would be good to give details on things we’ve considered and what our thoughts was on it

Applying product management to internal platforms

• This is done only in a limited way, and we do have a lot of things that haven fallen through the cracks over the years (e.g. devstack).

Pair programming:

• Definitely support it and would push for wider use of it.

• Someone needs to be a point person for it and they would figure out what to use

• Would help in delegating knowledge

• Possible method -> 2 people pairing together… With one person taking lead and the other person comes and goes based on their schedule

• The person pairing would be responsible for writing docs for knowledge transfer

Legacy migration feature parity

• As talk about studio split grows, we should be careful about this

Zero Trust Architecture

• We probably already do some of this, but probably should go into this eventually

• Not sure where this should be for things

Stuff Jeremy noted as interesting and/or useful:

• https://jupyterlab.readthedocs.io/en/stable/getting_started/overview.html (Python notebooks)

• https://pulsar.apache.org/en/ (Kafka alternative)

• https://www.ory.sh/hydra/ (OAuth 2 in separate service)

• https://crowdin.com/ (Transifex competitor)

• https://github.com/liamg/tfsec (Terraform security linting)

• https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare-pack (pair programming in Visual Studo Code)

• https://phrase.com/ (Transifex competitor)

• https://github.com/kudulab/dojo (enhancement of docker-compose)

• https://www.cypress.io/ (Selenium alternative)