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 10 Current »

Each IDA we plan to upgrade to Django 3.2 has an owning squad within edX.

Project Lead Jeremy Bowman and Project Manager Natalia Berdnikov have developed a “menu of options” for owning squads, offering various levels of involvement. Each squad that owns a DJango IDA needs to:

  1. choose from options below how involved they want to be in the upgrade work

  2. document their decision in https://docs.google.com/spreadsheets/d/11DheEtMDGrbA9hsUvZ2SEd4Cc8CaC4mAfoV8SVaLBGI/edit#gid=2033344699.

Green cells indicate work that would be done by the project team, lead by Jeremy Bowman.

Yellow cells indicate work owning squad would do.

Service Levels

Options

Plan and Automate

Create PRs

Review

Merge

Deploy

Test

1. Hands-off

By project team

By project team

By project team

By project team (with notice)

By project team

By project team

2. Trust but verify

By project team

By project team

By project team

By project team (with notice)

Need to do

Need to do

3. Review everything

By project team

By project team

Need to do

Need to do

Need to do

Need to do

4. DIY

By project team

Need to do

Need to do

Need to do

Need to do

Need to do

Service Levels Description

Option 1. Hand-off (Owning Squad is available for advice)

Project team does everything (development through deployment and testing), owning squad is not involved, aside from possible advice if project team gets stuck and needs help. Project team will give owning squad advance notice before merging.

Needed from the owning squad: occasional advice within 1 weeks of request.

This option allows the owning squad to spend little to no time on this project, and concentrate on other work. This option is good for areas of code that don’t require too much domain knowledge and can be easily done by the project team.

Option 2. Trust but verify (Owning Squad deploys and tests)

Project team creates and (after providing advance notice) merges PRs, owning team deploys and tests.

Needed from the owning squad: Deploy and test before October 15. Update project team on progress, highlight any possible blockers to the project team in advance.

This option is a compromise and allows the owning team to save time on development, while ensuring the end result.

Option 3. Review everything (Owning Squad reviews, deploys, and tests)

Project team creates PRs, owning squad reviews, deploys, and tests.

Needed from the owning squad: Review, deploy and test before October 15. Provide updates to the Project team along the road, highlight any possible blockers.

This option is a compromise and provides the owning team with the benefit of outsourcing the bulk of work to the project team, while still closely supervising the end result and having full control over it. This option might be good for teams who have a more complex area of code.

Option 4. DIY (Owning Squad creates PRs, reviews, deploys, and tests)

Owning squad does everything (use project plan and automation provided by project team, deployment, testing, etc.). Project team supervises timeline and status.

Needed from the owning squad: to deliver upgrade to prod and Edge by October 15. Provide updates to the Project team along the road, highlight any possible blockers.

This option requires most time from the owning squad, while at the same time ensuring that upgrade is done exactly as the owning team wants. This option might be good for areas of code that require a lot of domain knowledge or are otherwise complex.

  • No labels