Operation and Process

Owned by Simon Chen
Last updated: Apr 03, 2023 by Feanil PatelVersion comment

This documents the general operation of the team.

Roles and Responsibilities

Category: CustomerTriage / Escalation: InternalSustaining: InternalSuccess: Learner
Goal / Impact


Overview
  • The work is, looking at all the incoming bugs for Learner team, and collect the following:
    1. What is the impact of the bug? (Priority)
    2. Is there a timeline associated with the resolution of the bug? (Urgency)
    3. Are the bugs contain enough information to start investigations? (Actionable)
    4. Communicate with bug creator on expectations (Communication)
    5. Are the bugs reproducible? (Reproducible)
  • Based on the answers to the above, prioritize, schedule, plan or transfer each bug ticket into the right places.
  • 2 engineers at a time to perform the triage and escalation work above
  • One will be pinged on OpsGenie and Splunk alerts. One will be monitor the incoming bug area
    • See how to get yourself set-up on OpsGenie at 
  • Getting the support from the whole learner team by the form of secondary on-call rotation on Cambridge side
  • Work on maintenance tickets for the existing learner team technology
  • Quickly react to high priority issues we can swarm on
  • Delivering the biggest value to our existing learner base in shorter time

Existing set of service we provide to our learners:

    • Web Marketing (edx-mktg)
    • Email Marketing (Sailthru)
    • Search (Discovery)
    • Courseware (LMS)
    • Ecommerce (Payments and fulfillments) (Otto and Ecom-worker)
    • Course metadata (course-discovery)
    • Program Certificates (credentials)
    • Course certificates (LMS)
    • Dashboard (LMS)
    • Logistration (LMS)
    • ID Verification (LMS)
    • Credit (LMS)
    • Mobile
(TBD, similar to the sustaining: internal, but this calls out the project work / teams / prioritization that this team does. 
Stakeholders


What We are Not

  • Taking on a project without explicit consent from all members of the team
  • Dive into a new technology area without:
    • Clear motivation
    • Support
    • Conversation
    • Plan
    • Expectation
  • Isolated. We should communicate with Educator escalation regularity to discuss
    • Issues impact both
    • Best practices
    • Technical knowledge

Development Process

  • We shall employ Kanban as our development process.

    • We chose this agile methodology because it's flexible for interrupt and quick priority change. We anticipate interrupt and quick priority change will be the norm for this team

  • Our Kanban board is [Spartans] Product Development Board
  • We also have a filter for continuous prioritization at  Getting issues...

Code Review Best Practices

    • Communicate about the design and architecture of the solution in PR with code reviewers before you put up a PR.
    • Use Request to Review feature on Github
    • Fill out on the PR what you did to validate the fix (Your local environment or other environments)
    • It's better to squash commits after code review is done