One of the main difficulties in managing an open source project is how to maintain it without burning out.

The issue list is an open invitation for contributions which require your time and attention, which can be both beneficial and harmful.

As a maintainer on a project you are uniquely positioned to make the judgement calls on what is and isn’t important to the project. You hold the key to setting a clear direction and communicating that clearly and constantly to your contributors. Ensuring your project stays maintainable is about taking control of what is worth focusing on, and what isn’t.

 

An irresistible force, and an immovable object.

We’ll start with two simple truths.

Truth one: There are, and will always be, a non-finite number of possible valid issues to address.

Your code can always be better polished, your APIs better defined, and your project more fully featured. Your documentation can always be better. The ecosystem within which your project lives is constantly evolving.

You will never run out of things you could work on.

Ever.

Truth two: You have finite resources.

Damn.

 

Your issue tracker is a priority list, not a checklist.

The logic outcome of this is that you should address the opening and closing of tickets not based on whether the ticket might ever be addressed at some hypothetical point in the future, but based on if the ticket is active or is feasibly on the horizon.

As a maintainer, recognize that every issue you accept means that you have just actively de-prioritized something else.

As a contributor, recognize that every time you open an issue, you’re actively saying “I need you to look at and help resolve this, even if it means delaying work on other issues.”

 

Scope is everything.

The validity of a ticket is a function not just of its own merit, but also of your team’s ability to deal with it.

If your project has an issue that is non-resolvable with your current resources, then congratulations!

You don’t actually have an issue. Those things are called constraints, accept them, document them, close them, and get on with working on the things you can actually improve.

 

Take no prisoners.

If your project issue count starts to rise beyond an amount you’re able to sustainably deal with, then you’re at risk of losing control. Not only will you lack the time to be able to address the problem, but it’s going to continue to get worse over time.

Draw a maintainable scope around your project and defend it aggressively. Consider tactics such as:

• If the issues list is longer than you’re comfortable with then stop accepting feature requests until you’re in a better position. Make that explicit to contributors, and explain the motivation.
• Commit yourself to reducing the total open issues count by one per day. If you’re not able to achieve that, something needs to change.
• Use milestones consistently. If you don’t think an issue will make it into the next couple of releases then close it off as out of scope, unless it is clearly a headline feature that’s prominently on the project roadmap.

 

Be negative.

As a contributor, you should aim to have a net negative impact on the projects you deal with.

Close more issues than you open. Any time you’re considering opening an issue consider if you can first help another issue along the road to resolution.

 

Goodbye isn’t forever.

A closed issue doesn’t necessarily need to mean “we’re never going to consider this, ever”.

As a maintainer you should be open to reassessing and reopening closed issues. When you close tickets, be explicit that you’re open to reconsideration if someone makes a compelling case and helps make the issue easier to resolve.

As a contributor take a proactive approach to tickets you think have been closed incorrectly. Make a clear case, and be proactive about demonstrating a workable implementation. The less work a maintainer needs to do to resolve an issue, the better the effort/reward trade-off and the more likely it is to be accepted.

 

Finding the envelope.

In any large project there will always be a tension between wanting to expand the project, and what can be sustainably maintained.

You’re not typically aiming to have a project with no open issues. What you are looking for is to find the sweet spot of a manageable number of open tickets. Getting that right means your project will have focused forward motion. Getting it wrong means you’ll be overstretched, and risk your project losing productivity by thrashing on low priority issues.

Recognizing that issues are not worth considering unless they are within your team’s resources to deal with is liberating. You will be doing your users a favor by ensuring that you’re in active control of prioritizing where the project focus should be, and you’ll be doing yourself a favor by always being in a state where the project feels manageable.

 

It’s your project. Own it.

Efficiency. Sustainability. Maintainability.

Concentrate on what you can achieve within the foreseeable future and disregard the rest.

Then iterate, iterate, iterate.

DabApps offers technical consultancy, as well as bespoke development services. To find out more, get in touch. You can also follow Tom on Twitter.