User:Wraeth/PM MaintBug Dev

= Process for Granting Maintainership Requests =

This policy attempts to set 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.

Maintainer Bugs
The intention of having maintainer bugs is to track the contribution of individual maintainers, 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 proxied maintainers 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 where  is their proper name and  is their preferred online handle (preferrably the nick they wish to use as their 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. For those intending to later become developers, ideally it will be the nick they wish to use as their developer 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 proxy-maintainer bug can be linked to the developer bug.

Ongoing Maintainers
The maintainer bug can be used as a means of getting in touch with the maintainer when they appear to be inactive, and can be seen as a maintainer 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 functionality, allowing to bulk mail proxy maintainers. 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 in 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. Maintainers 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 maintainer ceases maintainership for whatever reason, any open bugs linked in the "Depends on" field of the maintainer bug (which would be the individual maintenance requests) should have the maintainer changed in and the request closed as, noting that the maintainer 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 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 contributor may contact a project member to ask for maintainership of a package, and that 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 maintainer managing them
 * : requests that have a developer managing them (listed in CC), but for which the maintainer has not been set in
 * : requests that have been granted and maintainership assigned, and are under active maintainership
 * : requests where the package was maintained for a time but have since been dropped by the maintainer, either due to leaving the Proxy Maintainers or progressing through recruitment.
 * : 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 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 finally closure when proxied maintainership ceases.


 * 1) A maintainership request bug should be filed for each package to be maintained with the summary/title
 * 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 maintainers 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 the contributor does not have a maintainer bug, it should be prior to assigning the maintainer in . The request should be linked to the maintainer bug by entering the maintainer bug ID in the  field of the request
 * 18) * If the package is being co-maintained, both developer bugs should be linked in the field
 * 19) When the maintainer is assigned in  the bug should be set to  and the developer remove themselves from CC

Once a maintainership request has been granted and the maintainer assigned in, the request should be in a and have the maintainer bug of each maintainer 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 bug 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 bug should be closed as and a comment entered explaining the closure, if appropriate.