Arch Tea Time: 2020-03-19 (Blended Dev Ideas)
Topics
Propose topics for us to discuss here.
Blended Development (italicized blue = probably self-contained effort; red = will probably need more hand-holding with edX engineers; bold green = on blended board)
We have an opportunity to outsource technical debt or technical investments through the Blended Development model. What are some possible projects to propose?
Frontend replatforming
Miscellaneous MFE-ification +1
NOTE:
For feature parity, the frontend rewrite wasn’t tough (based on experience with Logistration hackathon)
When APIs are missing, they can opt for BFF (Backend for Frontend) APIs for simpler features
There is probably some low hanging fruit here but also some fairly complex ones that would be less approachable.
Studio as an MFE
Backend replatforming
XModule => XBlock Conversion (FWIW, this is a planned project)
Move authn to its own service
Theming
Deprecations
Shopping Cart
Pattern Library Removal
Old LMS profile & account settings pages
Feature Spec Documentation - Document how different parts of the platform work.
Better support for ed tech standards and external content:
LTI Provider work
Bringing xAPI/Caliper integration over the line (already started by Appsembler and RaccoonGang)
Tech Investments
Pub/Sub messaging (maybe this is something we’d want to do ourselves on second thought) -1
Separate celery worker containers for edxapp in devstack
Feature Dev
edX Live (along the lines of what George’s hackathon team demoed)
Shopify Integration
Netsuite Integration
Notification Framework
Upgrades
Automated code cleanup via pyupgrade (six removal, remove deprecated code patterns, etc.) +1
Python 3.8 upgrade (3.5 support ends later this year) +1
Django 3.0 testing (get ahead of the curve this time) +1
ElasticSearch 5 upgrade
OEP Compliance
Better compliance with highest-priority repo health checks +1
Warnings & linting
Better Python warning reporting from test suites, fix existing warnings
Make edx-platform score 10/10 in pylint (might be more INCR-ish)
If we outsource projects to multiple development teams outside, how can we scale development without (1) edX engineers being bottlenecks, (2) further increase in the platform’s complexity, (3) causing production fires?
ORA & Teams as an example
ORA is non-trivial (maybe 2x complex as Teams)
Need a tech owner that coordinates the dev
Treat the external devs as part of your team
Developed in line with internal expectations
Internal “tech owner” / “reviewer”
Can be a burden unless reviewed externally first
Higher expectations on the internal dev
Blended role - not just an engineer anymore
Training the community to develop behind feature toggles
Sharing pager duty of edx.org
Notes
edX Engineers: ~80
Community Contributors: ~150
Project Size: generally larger than INCR project size
Project Type: scope is clear; requirements are clear
Developer expertise: intermediate-level engineers
Review Arch-BOM’s Q4 goals and projects (and where we are with Q3).
3 T’s
Toggles
Testing
Tech Ownership
Who takes ownership of ownership?
Tooling and maintenance: Arch BOM
Accountability: Engineering Leadership ceremony on a quarterly basis
FYIs
Bokchoy Experiment
Planning to turn off most bokchoy tests (not a11y tests)
ADR in progress
Accepting Risk over Development efficiency
Upcoming Survey will be sent to Engineers soon
Input into Platform theme priorities
As a pre-assessment metric for the Arch team
Repository Dashboard being created for Q3
Framework for automated checks
Examples: Makefile, tox.ini, openedx.yaml, etc.
Align on which constraints need to be consistent across repos and which don’t