User:Wraeth/PM MaintBug Dev

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.

Note
The information and steps required for Contributors can be found here.

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 gentoo.git repostory
Maintainer: A person or project listed in a packages metadata.xml 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 gentoo.git 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 NAME is their proper name and NICK 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 CONFIRMED state while the maintainer remains active.

Note
As with Gentoo Developers (and perhaps less strictly so), while a proper name is preferred, it is not a requirement - if a Contributor does not wish to provide a proper name, they should not be pressed for the information nor refused maintainership solely on this fact.

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 Depends on field of the Maintainer Bug (which would be the individual Maintainership Requests) should have the Contributor removed in metadata.xml and the request closed as FIXED, 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 RESOLVED-UPSTREAM 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:

UNCONFIRMED: requests that have not been assigned and do not have a Developer managing them
CONFIRMED: requests that have a Developer managing them (listed in CC), but for which the Contributor has not been set in metadata.xml
IN_PROGRESS: requests that have been granted and the Contributor assigned, and are under active maintainership
FIXED: 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
WONTFIX: requests where the package was maintained for a time but maintainership was neglected or otherwise adversely conducted
INVALID: 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.

A Maintainership Request bug should be filed for each package to be maintained with the summary/title Maintainership Request: <cat>/<pkg>
- If a request already exists for a package, Contributors should comment on the existing bug to announce their interest
A Developer can CC themselves to any UNCONFIRMED Maintainership Request they wish to manage
- A CC'd Developer is responsible for progressing the Request and assigning maintainership of the package
Once a Developer is CC, availability of the package for maintainership should be checked and, if available, the bug set to CONFIRMED
- If the package is already maintained, the current maintainer should be CC'd so they may respond to the request
- A CC'd Developer who cannot continue managing the Request should remove themselves from CC and set the bug back to UNCONFIRMED
Any existing bugs open for the package should be linked in Depends on, and the Contributor(s) instructed to begin working on these bugs
- 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
  - This may be longer as deemed appropriate by the Developer, for example for new contributors
  - A WHITEBOARD entry indicating the date the request is to be granted, if known, should be entered in the format due-YYYYMMDD
Anyone with objections to the claim should either enter comment on the bug or discuss them with the Developer managing the Maintainership Request
- Other Contributors wishing to maintain the package may comment to announce their intention. A suggestion of co-maintainership may be offered where reasonable
- 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
- REMEMBER THAT BUGZILLA IS PUBLIC AND PERMANENT
- 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
If a Request is to be denied, the Request should be closed with a status of INVALID and the reason for the rejection explained to the Contributor
If the Package Contributor does not have a Maintainer Bug, it should be created prior to assigning the Contributor in metadata.xml
The Request should be linked to the Maintainer Bug of each Contributor by entering the Maintainer Bug ID in the Blocks field of the Request
- If the package is being co-maintained, both Maintainer Bugs should be linked in the Blocks field
When the Contributor is assigned in metadata.xml the Request should be set to IN_PROGRESS and the Developer remove themselves from CC

Once a Maintainership Request has been granted and the Package Contributor assigned in metadata.xml, the Request should be in a IN_PROGRESS and have the Maintainer Bug of each Contributor linked in the Blocks 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).

Note
In the case of co-maintained bugs where only one Contributor is dropping the package, their Maintainer Bug should be removed from the "Blocks" field. Unfortunately this unlinks a Maintainers Bug, but we can't have one Request in two states for different Contributors.

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