Project:Proxy Maintainers/Managing Requests

This policy sets out a standard process to follow for handling Maintainership Requests from Contributors and tracking their involvement with the Proxy Maintainers project for the duration of their maintainership. While this policy attempts to cover most conditions that are likely to be encountered, some may fall outside the coverage of this policy, in which case a common-sense approach should be taken to follow the intent of this process.

This policy has two components that go hand-in-hand in the management of requests for individual packages and the tracking of Contributors involvement.

Terminology
For the purpose of clarity, this policy uses the following definitions:


 * Gentoo Developer or Developer
 * A Gentoo Linux Developer with push access to the repostory


 * Maintainer
 * A person or project listed in a packages as a maintainer. This may or may not be through the Proxy Maintainers project and may be either a Contributor or Developer


 * Package Contributor or Contributor
 * The individual acting as maintainer for one or more packages and whom does not have push access to the repository


 * Project Member
 * A Gentoo Linux Developer who is a member of the Proxy Maintainers project

Maintainer Bugs
The intention of having maintainer bugs is to track the contribution of Package Contributors, acting as a record of their involvement with the project, and to provide a guaranteed point of contact in order to verify continued involvement and record any notes relevant to their maintainership. This is similar to a Developer bug and, given that many Package Contributors continue to become full Developers, can act as supporting material in their recruitment.

New Maintainers
When a Contributor is about to be assigned as maintainer of their first package, a bug should be filed to follow their contributions. The summary/title of the bug should be set to Maintainer: ${NAME} (${NICK}) where is their proper name and  is their chosen online handle (preferably the nick they wish to use as their Gentoo Developer nick, if they intend to follow that route). The bug should be assigned to the Contributor and have proxy-maint@gentoo.org added to CC, and should remain in a state while the maintainer remains active.

The nick does not necessarily need to be an IRC nickname either - not all people use IRC. The nick should be their "preferred" nick. The Contributors nick may be set as an alias to the bug, but this will need to be removed if and when they wish to proceed with recruitment, and their Maintainer Bug can be linked to their Developer bug.

Ongoing Maintainers
The Maintainer Bug can be used as a means of getting in touch with the Package Contributor when they appear to be inactive, and can be seen as a Contributor status - if they have an open Maintainer Bug with no comments to the contrary, they are presumed to be active. Also note that Bugzilla has the edit multiple bugs and Send Mail to Assignees functionality, allowing to bulk mail Package Contributors. This can be used as a means to request a response from a number of Contributors at once.

If a Contributor appears to have become inactive, attempts should be made to contact them through the Maintainer Bug before the bug is closed and maintainership is removed from them.

The Maintainer Bug should be used as a record of their overall maintainership and not used as a day-to-day communication medium. Also keep in mind that Bugzilla is a permanent and public record, so due consideration should be made before entering a comment. Contributors may also leave notes on their bug, for example if they plan on being away for a significant period of time, similar to the devaway system.

Finishing Maintainership
When a Package Contributor wishes to leave maintainership for whatever reason, any open bugs linked in the field of the Maintainer Bug (which would be the individual Maintainership Requests) should have the Contributor removed in  and the request closed as, noting that the Contributor is ceasing maintainership. Once all those bugs are closed, the Maintainer Bug can be closed.

If the Contributor is moving on to become a full Gentoo Developer, maintainership requests should be closed and the maintainer bug finalised as to indicate that they have become a Developer.

When closing a Maintainer Bug, a final comment should be entered indicating the reason for the closure.

Maintainership Requests
Due to the number of different ways a Package Contributor may contact a Project Member to ask for maintainership of a package, and that Gentoo Developers may be unaware of others wishing to take maintainership of the same package, a Maintainership Request bug should be used to track the progression of the request and maintenance of the package by the Contributor(s). Each request should be managed by a single Developer only, so that the one Developer can be aware of any and all issues with a given request when considering it. The Bugzilla status of these bugs is used to indicate the state of each request:


 * : requests that have not been assigned and do not have a Developer managing them
 * : requests that have a Developer managing them (listed in CC), but for which the Contributor has not been set in
 * : requests that have been granted and the Contributor assigned, and are under active maintainership
 * : requests where the package was maintained for a time but has since been dropped by the Contributor - the reason for it being dropped should be listed on the bug
 * : requests where the package was maintained for a time but maintainership was neglected or otherwise adversely conducted
 * : requests that were not granted either due to the initial request being withdrawn, the request being considered unsuitable, or the package being maintained by another maintainer (either a Gentoo Developer or Package Contributor) who wishes to retain maintainership

Process
Once a Maintainership Request has been filed, the process for managing them is a straightforward progression from initial request, resolution of existing bugs (or timeout in a lack thereof), assignment and maintenance, and eventual closure when the maintainership of the Package Contributor through the Proxy Maintainers project ceases.


 * 1) A Maintainership Request bug should be filed for each package to be maintained with the summary/title Maintainership Request: /
 * 2) * If a request already exists for a package, Contributors should comment on the existing bug to announce their interest
 * 3) A Developer can CC themselves to any  Maintainership Request they wish to manage
 * 4) * A CC'd Developer is responsible for progressing the Request and assigning maintainership of the package
 * 5) Once a Developer is CC, availability of the package for maintainership should be checked and, if available, the bug set to
 * 6) * If the package is already maintained, the current maintainer should be CC'd so they may respond to the request
 * 7) * A CC'd Developer who cannot continue managing the Request should remove themselves from CC and set the bug back to
 * 8) Any existing bugs open for the package should be linked in, and the Contributor(s) instructed to begin working on these bugs
 * 9) * If there are no other current bugs for the package, a minimum of three (3) days from the time a Developer takes management of the package should apply to allow for any additional comments or claims
 * 10) ** This may be longer as deemed appropriate by the Developer, for example for new contributors
 * 11) ** A entry indicating the date the request is to be granted, if known, should be entered in the format due-YYYYMMDD
 * 12) Anyone with objections to the claim should either enter comment on the bug or discuss them with the Developer managing the Maintainership Request
 * 13) * Other Contributors wishing to maintain the package may comment to announce their intention. A suggestion of co-maintainership may be offered where reasonable
 * 14) * In the case of two or more Contributors wanting exclusive maintainership of a package, a general preference of FIFO may be reasonable, however it should be a case-by-case assessment of the suitability of each candidate, and new contributors should be encourage when possible
 * 15) * REMEMBER THAT BUGZILLA IS PUBLIC AND PERMANENT
 * 16) * A normal conflict-resolution policy is expected here - if an objection is made and dismissed, and the objection is considered strong enough, the matter may be escalated to either a third-party Developer or the project lead
 * 17) If a Request is to be denied, the Request should be closed with a status of  and the reason for the rejection explained to the Contributor
 * 18) If the Package Contributor does not have a Maintainer Bug, it should be created prior to assigning the Contributor in
 * 19) The Request should be linked to the Maintainer Bug of each Contributor by entering the Maintainer Bug ID in the  field of the Request
 * 20) * If the package is being co-maintained, both Maintainer Bugs should be linked in the field
 * 21) When the Contributor is assigned in  the Request should be set to  and the Developer remove themselves from CC

Once a Maintainership Request has been granted and the Package Contributor assigned in, the Request should be in a and have the Maintainer Bug of each Contributor linked in the  field.

Ending Maintainership
When maintainership of the package is ceasing, or maintainership is being handed to another maintainer, the Developer making the change should close the Request as FIXED, adding a comment noting the reason for the removal ("maintainer dropping", "handing over maintainership", etc).

If maintainership is being removed due to inactivity or unsatisfactory maintenance, the Request should be closed as and a comment entered explaining the closure, if appropriate.