• Policy Name: Maintenance

• Policy Owner: Francis Lacoste

• Parent Process/Activity: None

• Supported Policy: None

This is a draft

Feedback to RobertCollins or on the developers list please.

Policy Overview

Quite separate to adding new features and facilities we have to maintain Launchpad indefinitely. This policy is about containing the costs of maintenance while still allowing Launchpad to be changed and extended.

In short: all changes to Launchpad must decrease, or at worst not increase the overall cost of maintenance.

Maintenance means:

• User support
• Bug triage
• Code review and contribution landings
• operate the site(s)
• fix things that break due to our users using Launchpad
• fix things that break due to external environmental changes (new Ubuntu releases, new browsers releases etc)
• make modest changes based on our bug database as time permits

Responsibilities

Anyone that does code/design/project review for Launchpad needs to include maintenance costs in their review. You are expected to think about the cost of maintaining a project and allow for it in some fashion.

This may mean saying 'no' to a volunteer contributed patch because it would increase our maintenance costs. (But you could then offset the cost yourself somewhere else, or ask them to fix e.g. a tech-debt bug to counteract the increased costs).

We don't have a simple rule for this, and given the size of LP it may be hard to come up with one.

Prior art

The drizzle project took a very similar approach - they took one metric for maintenance costs/complexity - lines of code - and then made a simple rule: no patch could land which increased the LoC in the project. This was very successful for them.

Why this policy?

Launchpad is resourced with a (mostly) fixed size maintenance team: if the costs of maintenance increase, we will fall behind (with a corresponding decrease in how well we do our maintenance).

Launchpad is currently very expensive to maintain, and we can do much more interesting things if we make it cheap to maintain.

What things increase costs

• Increasing the number or difficulty of support tickets
• Increasing the number or difficulty of bugs filed against launchpad-project
• Making code review or contribution landings harder to do or more time consuming
• Making operations harder, more complex or more resource hungry
• Using components that do not scale as usage or time increase
• Using features that are likely to be broken as Ubuntu (our platform) or web browsers (our other platform) evolve
• Adding code (which then brings its own bugs)
• Adding complexity to the system (in any of a number of different ways - more languages, more approaches to doing things, more choice)

What things decrease costs

• Fixing things so users don't have to open support tickets
• Fixing things so users don't need to open new (or duplicate) bugs
• Making landings easier and code review more streamlined
• Automation of operational tasks
• Increasing the efficiency of the system
• Replacing poor components with simple or scalable components
• Removing unnecessary code
• Removing unnecessary complexity

XYZ is necessary, but is in the increases-costs list, what choices do I have?

• Don't do XYZ
• Pay for XYZ by tackling something that will decrease costs by about the same amount
• Get special dispensation from the Launchpad project leader and/or CDO Technical Architect to increase the maintenance costs

I want to do a bunch of things that will increase costs, but eventually decrease them

Great. Do it - the policy is intended to apply to arc's of work, or stories, not to individual commits. (But sometimes individual commits are the right place to examine such things).

When

We are starting this policy as soon as it has been approved.