Action Items

• Type your task here, using "@" to assign to a user and "//" to select a due date

Topics

• 4 Working group Ownership, backlogs for working groups - do they own and work on stuff?  Can they?
  • Where do we track issues? Is there a consistent scheme for libraries/services/frontends? Do we need one?
  • Background:
    • Arch-FED team changes
    • Question on FedX working group
  • Spotify Guild model - akin to our working group model
  • DEPR working group - using meeting time as a working session
  • Are working groups the technical stewards at edX?  Or the owning squads?
• 5 Arch Backend Priorities
  • Arch Lunch voting (out of 14 folks)
  • (5) A Scaling our Microservices architecture (standardization, inter-service communication)
    • standardization/consistency
      • common libraries for authn, authz, 
      • updating authn across services
      • config
      • caching guidelines
    • scaling communication
      • eventing framework
      • async versus not
  • (2) B API practices
    • Up-to-date API Conventions doc
    • API Versioning questions
    • Direction/future of API Gateway
    • Location of business logic
  • (6) C Multi-Environment (Prod, Stage, Sandbox, etc) Testing & Configuration (Data inconsistency)
    • Note: Devops team is working on Kubernetes for multi-environment
      • DevOps is focusing on production, but need to consider other environments (not doing as much right now)
    • Automated tooling to identify discrepancies across environments
  • Should just happen
    • Observability
      • Note: Engagement theme invested time to analyze their SLAs and took action to implement alerts for them
• 3 Permissioning across non-edxapp IDAs (nothing or superuser)
• 6 Ownership
  • Current Pain Points
    • Multiple ownership locations: Google Doc, Wiki (S&E + FED), openedx.yml, Codeowners
  • What do you want to see coming out of it
    • Need a reliable way to keep it up-to-date
    • Person discoverability - who do I ask if I'm curious about this
    • Accountability - required upgrades, flaky tests
      • Holding engineering owners (as technical stewards) accountable
    • Resourcing and prioritization across product work & ownership work
    • Zero "Default" owners (individuals who defacto get pulled in when something isn't owned)