/
Arch Hour: 2020-11-19

Arch Hour: 2020-11-19

Topics

Please enter your proposed topics for discussion here.
In Lean Coffee Style (link1, link2), we will vote on which topics the group wants to discuss and time-box the discussion to 10 or 15mns → 5mns (if re-voted) → 5mns (if re-voted).

  • Frontend organisms - an incomplete strawperson proposal for how to manage complex, shared components.

    • We have a bunch of different front end dependencies shared between different MFEs, some of which are only used for edx.org and some only for Open edX. Is it worth trying to roll these up together somehow for easier management?

    • All the different repos are making code sharing harder

    • Packaging concerns change a lot when we can drop IE11 support and switch to HTTP2

  • Semantic git commit messages +3

    • https://github.com/facebook/docusaurus/blob/master/CONTRIBUTING.md#semantic-commit-messages

    • https://github.com/facebook/docusaurus/blob/master/CHANGELOG-2.x.md

    • Makes us think a little more about what kind of change we’re making

      • Refactor broken out into a separate commit

    • Flags to community what kinds of changes were made (aid in creating / supplement to changelog)

    • Note that some edXers may always squash all their commits. But other edXers do keep their commits logically separate.

    • How might we enforce something like this?

      • commit-lint - pre-commit hook

        "husky": {
 "hooks": {
 "pre-commit": "npm run lint",
 "commit-msg": "commitlint -e $GIT_PARAMS"
 } },


    • PR titles today also have Jira ticket numbers

      • Could they be in the description of the PR instead?

    • How Github/Jira Linking Works

  • Ideas on doing upgrades more efficiently in the future? +3

    • Would be good to know the priority order and sequencing of upgrades.

      • Sometimes based on repo ownership priority, sometimes technical reasons like dependency chains

    • Some teams own too many things, hard for them to get upgrades done in a timely manner

    • Some teams aren’t yet familiar enough with the stuff they own to feel confident in safely upgrading a thing quickly

    • We should articulate better why we’re upgrading a thing now and consequences of deferring

    • Repo health dashboard checks for progress and consistency tracking

    • “Ticket all the places we need to upgrade this” tickets

    • Inconsistency of services being in devstack and/or sandboxes makes it a little hard to follow a pattern for upgrading all the things

  • GitHub Actions migration +2

Backlog of Questions/Discussions

This section lists a backlog of previous proposed topics that haven’t yet been discussed.