Retiring Inactive Committers

Project leads have the ability to retire committers: this is a power that must be used responsibly.

The most common reason to retire a committer is extended inactivity. Inactive committers can be a liability, for example:

• A long list of committers can give a false sense of viability (if a project looks like it has ten maintainers but only two are active, the project is much more fragile than it appears);
• Inactive committers, especially when the number of committers is small, can make it difficult to run successful votes in committer elections; and
• The EMO and Security Team have started to be concerned that long-term inactive committers represent a potential security risk.

From a security perspective, our main concern is abandoned accounts that have committer status: these accounts run the highest risk of being compromised.

How long is too long for a committer to be inactive is determined by project leads and the PMC; the EMO recommends that project teams consider one year of inactivity as an upper bound.

A project lead needs to be able to support their decision to retire a committer. As a best practice, the project lead should give committers reasonable opportunity to retain their status, and – should the decision be made to retire – committer retirements should be announced on the project’s primary communication channels including the dev-list.

The practice that many project leads follow is to use the PMI to determine which committers are inactive and then post the names of inactive committers on the project’s main communication channel (usually the dev-list or an issue) with instructions for those individuals to respond if they feel that they should retain committer status (a committer’s response on the dev-list can be considered an indication that the committer is still active). Set a reasonable deadline and retire everybody who does not respond when that date passes. The sweet spot is four weeks, and never during the summer.

This technique has the benefit of being entirely transparent.

If the list of committers is so large that flipping through the PMI pages to determine who is active and who is not is especially cumbersome, open a help desk issue and ask the EMO to generate a list for you. Be specific: for example “please generate a list of Eclipse Woolsey committers who have been been inactive in Git for six months or longer”. Note that we can only provide names and committer IDs; the privacy policy restricts us from giving out email addresses.

Bear in mind that committer status is an important part of the IP workflows in the specification process and that it is normal to have inactive committers who represent member companies on specification projects

If you make a horrible, horrible mistake and retire somebody by accident, contact the EMO and we’ll help you sort it out.

If you have questions about Eclipse Project Governance, open help desk issue or contact emo@eclipse-foundation.org.