Non-responsive maintainer policy

Propósito

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 increase the overall quality of Fedora.

Coverage

This policy covers existing Fedora packages, containers, and modules; for non-responsive package submitters or reviewers, see the Policy for stalled package reviews. If you are a not an existing Fedora contributor, you can follow this procedure too. If you want to take over maintainership, you must find a sponsor following the rules specified in How to get sponsored into the packager group.

Steps

When a Fedora member notices that a maintainer isn’t answering their bugs, not answering rebuild requests, src.fedoraproject.org pull requests, emails, or the like, these steps should be followed:

Week 0

  1. Check if the non-responsive maintainer is on vacation. To see if the maintainer has been recently active on Fedora, fedora-active-user can be employed.

  2. File a new bug against the package in Bugzilla asking for the maintainer to respond using an appropriate template and fill in all the fields (template for nonresponsive package maintainer, nonresponsive container maintainer, or nonresponsive module maintainer). This is a must.

  3. Post to the Fedora devel list with a link to the bug report and ask if anyone knows how to contact the maintainer. CC the maintainer. Links to all other bug reports open on all neglected packages from the same maintainer should be included.

Week 1

  1. After 7 days, submit a FESCo issue with the bug link and mailing list post link. State if you are a packager and want to take over the package. The non-responsive maintainer and all existing maintainers must be @-mentioned in the ticket.

  2. If at least one FESCo member votes +1 and no one votes differently, the ticket is approved after three days. If any -1 or 0 votes are made, FESCo will discuss the issue during a meeting. This voting policy is intentionally simpler than the usual voting policy#ticket-votes.

  3. If approved, and the reporter is a current Fedora packager in good standing, interested in comaintaining the package, FESCo will default to adding the reporter as the package admin. If the existing co-maintainers of the package do not want the package to be reassigned to the reporter, they should state so in the ticket. If assigned ownership, the reporter can now perform any required package maintenance.

Week 2

  1. A week later FESCo posts a reminder in the ticket, @-mentioning the maintainer.

Week 3

  1. With no further reply for the original owner, FESCo closes its ticket and the bugzilla ticket. If maintainership was requested in the FESCo ticket, the reporter will be assigned as the main maintainer of the package, and the package will be orphaned otherwise. All other packages are orphaned too, and may be picked up by co-maintainers or other packagers. The original owner is removed as co-maintainer (admin/commit/ticket access) or "watcher" from all other packages.

Once the final reassignment happens, the new owner must also reassign all open bugs for this package to themselves.

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. In general, it is better for every package to have multiple maintainers. Co-maintainers may be added in the Settings tab of the package in dist-git.

  • Edit the Vacation page to indicate when you will be away.

Invalid email addresses

Bugzilla uses the email address in the Fedora Account System to send messages to the package maintainer. If it becomes known that this email address no longer goes to the package maintainer, and there is already an open non-responsive maintainer procedure open, the issue with the email address should be noted in the mailing list post and FESCo ticket. Otherwise, the non-responsive maintainer procedure should be opened for this maintainer.

Situations where it becomes known that an email address is no longer going to go to the maintainer are:

  1. Email to the address bounces (to differentiate from temporary bounces like a mailbox full, this should go on for a period of 7 days).

  2. Red Hat lets us know that an email address is no longer valid for the package maintainer (usually because the person has left Red Hat).

In the special case where an account does not have a valid email address connected in bugzilla, and does not maintain any packages and is not part of packager group, it can be dropped from package "watchers" immediately.

Exception procedure

There are some cases where it may be needed to reassign a package even if this procedure has not yet finished. Examples include when many dependencies are broken, version updates are needed for security or stability reasons, or maintainer response prevents the non-responsive process from proceeding without actually resuming maintenance. In such cases, this exception procedure can be used.

Steps:

  1. Explain why the exception process is needed and note all communication attempts in an email to the devel@lists.fedoraproject.org list with the non-responsive maintainer CC’ed on the email.

  2. Open the FESCo ticket described in step 4 without waiting a week and also describe the situation there.

Orphaning process

Unless there is a reason not to (the maintainer’s email is bouncing, the maintainer has told someone that they are not interested in continuing to maintain Fedora packages) we will make the maintainer a comaintainer on the package in all branches they were an owner. Then we will orphan the packages.

If the maintainer’s email is bouncing or we’ve been told that the maintainer is not interested in continuing to contribute to Fedora we’ll remove all of the maintainer’s acls.

Want to help? Learn how to contribute to Fedora Docs ›