Non-responsive Maintainer Policy
Digest
- File a bug against the package in bugzilla asking for the maintainer to respond (after checking if the maintainer is on Vacation ).
- After every 7 days, the reporter adds a comment to the bug report for each unsuccessful attempt to contact.
- After 2 attempts of no contact, the reporter asks if anyone knows how to contact the maintainer.
- After another 7 days, the reporter posts a formal request to the fedora-devel list with the bug link.
- If at least one FESco member approves the takeover and no one objects within 3 days, the requester may take over the package. If the requester is a not an existing Fedora contributor, he may still take over a package. Once approval has been given, follow PackageMaintainers/CVSAdminProcedure to have ownership of the package changed. In addition to this, the new owner must also reassign any open bugs on that package to themselves.
Purpose
The purpose for this policy is to provide a mechanism within Fedora 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 packages and assist in the overall quality of Fedora.
Coverage
This policy covers existing Fedora packages; for non-responsive package submitters or reviewers, see Policy_for_stalled_package_reviews. This mechanism is not limited to existing Fedora contributors. For non-contributors, see below for instructions.
The policy is targeted at maintainers that can still be reached through the mail they have registered in fedora. 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 he is not willing to make the required change in the packagedb, 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 Fedora member notices that a maintainer isn't answering their bugs, not answering rebuild requests, emails or the like, they need to file a bug against the package in bugzilla asking for the maintainer to respond. This bug should list the outstanding issues they need to address. This is a must. Note: Be sure to check the Vacation page before opening the bug, to verify that the maintainer is not away on vacation.
- After every 7 days, the reporter adds a comment to the bug 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 (ie, alternative email, irc, etc).
- After 2 attempts (2 weeks) of no response from the maintainer, the reporter posts to the fedora-devel list with a url to the bug report and asks if anyone knows how to contact the maintainer.
- After another 7 days (now 3 weeks total), the reporter posts a formal request to the fedora-devel list with the bug link, indicating all reasonable efforts have been made to contact the maintainer have failed and that they wish to take over the package.
- If at least one FESco member approves the takeover, and no one objects within 3 days, you may take over the package.
- If you are a not an existing Fedora contributor, you can still take over a package. All of the above must be followed. When you seek approval for the takeover, you, again, must provide a bugzilla report as if it were a new Fedora package review. This will allow the normal review process to happen -- that includes finding a sponsor that believes you understand the packaging rules. Information on sponsorship is at PackageMaintainers/HowToGetSponsored and the full process for becoming a contributor to Fedora is at PackageMaintainers/Join. You'll probably want to start from step 7. You can peruse the packaging guidelines at Packaging/Guidelines.
- Once approval has been given, follow PackageMaintainers/CVSAdminProcedure to have ownership of the package changed. In addition to this, the new owner must also reassign any open bugs on that package to themselves.
Notes for Mass Orphaning
- It is common for a Fedora contributor to maintain multiple packages within Fedora, and the situation may arise where multiple packages with a single maintainer need to be orphaned. Given that, it would be quite impractical to create a bugzilla ticket for each package. 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 Fedora development mailing list should include all other bug reports open on all neglected packages from the same maintainer, indicating that the maintainer is indeed non-responsive. The Steering Committee can then step in and orphan the other packages 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 Fedora contributor can be asked to maintain the package in the maintainer's absense. To add a co-maintainer, follow the procedure at PackageMaintainers/CVSAdminProcedure (this may change soon to use the PackageDB ).
- Edit the Vacation page to indicate when you will be away.