Activity Team/Policy for nonresponsive maintainers

Non-responsive Maintainer Policy

(This policy is inspired from Fedora Policy for Nonresponsive package maintainers)

Purpose

The purpose for this policy is to provide a mechanism within Sugar Labs to handle situations when a package maintainer becomes unavailable to continue maintainership, often referred to as non-responsive. The end goal is to help prevent packages becoming stale through non-maintenance, reduce open bugs on non-maintained activities and assist in the overall quality.

Coverage

The policy is targeted at maintainers that can still be reached through the mail they have registered in Gitorious. If the mail of the maintainer has changed in a way that seems permanent, and cannot be contacted (with reasonable effort), this policy also applies. If there is no known way of contacting the former maintainer, or they are not willing to make the required change in Gitorious, one can short-circuit the normal 3 week interval required in the Outline steps 1 to 3, and make the formal request to orphan mentioned in step 4.

Outline

When a Sugar Labs member notices that a maintainer isn't answering their bugs, not answering rebuild requests, emails or the like, these steps should be followed:

1. [File a bug] against the activity asking for the maintainer to respond. This bug should list the outstanding issues they need to address. This is a must.
2. After 7 days, the reporter adds a second comment to the bug report asking again for a response. Others can add to the bug that they also were not successful in contacting the maintainer, or providing additional contact information for the maintainer (i.e., alternative email, IRC, etc).
3. The reporter also posts to the [lists.sugarlabs.org/listinfo/sugar-devel sugar-devel] list with a link to the bug report and asks if anyone knows how to contact the maintainer.
4. After 7 more days (now 2 weeks total), the reporter posts a formal request to the sugar-devel list with the bug link, indicating all reasonable efforts to contact the maintainer have failed and that they wish to take over the package.
5. If at least one Activity Team Coordinator or SLOBs member approves the takeover, and no one objects within 2 days, the reporter may take over the package.
6. Once approval has been given, the reporter can request the Infrastructure Team to change ownership of the Activity in git, trac and ASLO. In addition to this, the new owner must also reassign all open bugs for this package to themselves.

If you are a not an existing Sugar Labs contributor, you can still take over an Activity. All of the above must be followed. When you seek approval for the takeover, you should create accounts for yourself in Gitorious, Trac and ASLO.

Notes for Mass Orphaning

• It is common for a Sugar Labs contributor to maintain multiple activities, and the situation may arise where multiple activities with a single maintainer need to be orphaned. Given that, it would be quite impractical to create a ticket for each activity. In the case where a mass orphaning is likely, the above should still be followed choosing a single package owned by the potential non-responsive developer. However, the formal request to the Sugar development mailing list should include all other bug reports open on all neglected activities from the same maintainer, indicating that the maintainer is indeed non-responsive. The Activity Team Coordinators can then step in and orphan the other activities if necessary.

Notes for maintainers

It is understood that maintainers will go on vacation or will otherwise be unavailable for possibly significant lengths of time. There are a couple of things that maintainers should consider doing if they know in advance that they will be unavailable;

• Designate a co-maintainer. Currently there is no policy on the exact details of this, but, in general, another Sugar Labs contributor can be asked to maintain the package in the maintainer's absence. To add a co-maintainer, have the co-maintainer request commit rights in Gitorious and approve the request.

• Send a vacation notice to sugar-devel to indicate when you will be away.

Fast Track procedure

In some cases it may be needed to reassign an activity from a non-responsive maintainer quickly, for example: when the core user experience is broken by their activity, there is a lot of integration work needed, a version update is required for security or stability issues or the maintainer has been non-responsive for a long time, but the above procedure has never been completed. In such cases this "fast track" process can be used.

Steps:

• Write email to the sugar-devel list with the non-responsive maintainer CC'ed on the post. Explain why you think the fast track process is needed. (Make sure and note any communication attempt done already)

• Open a ticket with the maintainers' account CC'ed.

• The next Activity Team meeting will discuss the case and reach a decision.