Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

This documents the general operation of the team.

Roles and Responsibilities

Bugs Triage/Escalation

  • 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
  • Major internal stakeholders:

Sustaining engineering

  • 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

Code Review Best Practice:

    • 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

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 at https://openedx.atlassian.net/secure/RapidBoard.jspa?rapidView=362
  • We also have a filter for continuous prioritization at  Getting issues...
  • No labels