Maintenance Cost Estimates

Assumptions:

• Code that’s not being actively developed but that we need to keep working.

• This is just a minimum, there are other benefits of removing code.

• The cost of maintenance goes down the closer it is to being DEPRed.

• There is a cost of confusion as a thing becomes less and less standard that is not captured here.

Next Steps:

• Validate by calculating minimum maintenance across all edX github repos.

Types of deprecations:

• Small service( ~10 weeks/year)

  • ASSUMPTIONS

    • Size of service: 200 KB python code.

  • Django Upgrades ( 3 days/year)

  • Python Upgrades (2 days/year)

  • Monitoring for breakage. (2 days/year)

  • Renovate PRs ( 2 weeks/year)

  • “make upgrade” PRs ( 2 weeks/year)

  • Flaky test diagnosis ( 1 day/year)

  • Deployment pipeline maintenance and troubleshooting (1 week/year)

  • OSPR review ( 2 weeks/year )

  • Security issue responses ( 2 days/year)

  • Writing and updating documentation ( 1 day/year)

  • Accessibility fixes (1 day/year)

  • CI/Release Tooling Maintenance( 1 week/year)

    • Updating test matrices.

    • Release to Production

    • Moving to new test runners(travis -> gh actions)

    • Updating usage of public actions.

• Python Library/package( ~7 weeks/year)

  • ASSUMPTIONS

    • Size of Library/Package: 200 KB (including config and repo overhead)

  • Django Upgrades (3 days/year)

  • Python Upgrades (2 days/year)

  • Monitoring for breakage. (1-3 days/year based on app cohesion)

  • “make upgrade” PRs (2 weeks/year)

  • Flaky test diagnosis (1 day/year)

  • OSPR review (2 weeks/year )

  • Security issue responses (2 days/year)

  • Writing and updating documentation (1 day/year)

  • CI/Release Tooling Maintenance( 1 week/year)

    • Updating test matrices.

    • Release to PyPI

    • Moving to new test runners(travis -> gh actions)

    • Updating usage of public actions.

• JS Library/Package( ~4 weeks/year)

  • ASSUMPTIONS

    • Size of Library/Package: 50 kb

    • Not Paragon because it’s our design system and needs more regular maintenance.

  • Paragon/React/Node upgrades (1 week/year)

  • Renovate PRs (2 days/year)

  • OSPR review ( 1 days/year)

    • This will change as MFEs become default.

    • As we add a pattern for front-end extension points.

  • Security issue responses (1 week/year)

  • Writing and updating documentation (3 days/year)

  • Accessibility fixes (0 days/year - these mostly happen in Paragon and MFEs)

  • Bug fixes & regression tests (1 week/year)

• MFE (~ 5 weeks/year)

  • ASSUMPTIONS

    • Size of MFE: 200 KB 

  • Paragon/webpack/React/Node upgrades (1 week/year)

  • Renovate PRs (2 days/year)

  • OSPR review ( 2 days/year)

    • This will change as MFEs become default.

    • As we add a pattern for front-end extension points.

  • Security issue responses (3 days/year)

  • Writing and updating documentation (1 day/year)

  • Accessibility fixes (3 days/year)

  • Bug fixes & regression tests (1 week/year)

  • Monitoring for breakage. (2 days/year)

  • Deployment pipeline maintenance and troubleshooting (3 days/year)

  • CI/Release Tooling Maintenance( 2 days/year)

    • Updating test matrices.

    • Release to Production

    • Moving to new test runners (travis -> gh actions)

    • Updating usage of public actions.

• Block of code in a larger service/package (~5-6 weeks/year)

  • ASSUMPTIONS

    • Size of code/package: 150 KB

  • Django Upgrades (3 days/year)

  • Python Upgrades (2 days/year)

  • Monitoring for breakage. (1-3 days/year based on app cohesion)

  • “make upgrade” PRs (2 weeks/year)

  • Flaky test diagnosis (1 day/year)

  • OSPR review (2 weeks/year)

  • Security issue responses ( 2 days/year)

  • Writing and updating documentation ( 1 day/year)

  • Accessibility fixes (1 day/year)