Non-responsive maintainer policy

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 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, has an invalid email address or deactivated Bugzilla account set in FAS, or the like, these steps should be followed:

Week 0

  1. Check if the non-responsive maintainer is on vacation.

  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 or nonresponsive container maintainer. If the maintainer’s email address or Bugzilla account are inactive, this step can be skipped.

  3. Post to the Fedora devel list with a link to the bug report (if applicable) and ask if anyone knows how to contact the maintainer. CC the maintainer unless the maintainer’s email address is known to be invalid. 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 nonresponsive maintainer’s package or packages. The non-responsive maintainer and all existing maintainers must be @-mentioned in the ticket. This ticket MAY be filed at the same time as the devel post is sent in which case the FESCo voting period will start 7 days after the devel post was sent.

  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, the issue with the email address should be noted in the mailing list post and FESCo ticket. In this case, the requirement to file a nonresponsive maintainer Bugzilla bug is waived but the requirement to send a devel list post remains.

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 with an invalid user error (such as Recipient address rejected: User unknown in local recipient table).

  2. The provider or company associated with the address otherwise communicates that the address is invalid.

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

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.

Alternative: Lightweight stalled request process for other packagers

The non-responsive maintainer process is a serious undertaking, and if successful, results in the packages where the maintainer is the main admin being orphaned; as noted in the Exception procedure a maintainer response also aborts this process.

Prerequisites

  1. You should be an already sponsored Fedora packager.

  2. You should be willing to co-maintain the package in question. This should not be used for drive-by contributions.

Week 0

  1. File a new bug against the package in Bugzilla, with a linked pull request if applicable (this might not be needed if you’re requesting an EPEL branch and an existing branch builds fine, in which case please provide some evidence e.g. scratch build result).

Week 1

  1. After 7 days, ping the bug, NEEDINFO the assignee and ask for a response.

Week 3

  1. After another 14 days with no action, submit a releng ticket requesting commit permissions in order to co-maintain the package. The non-responsive maintainer and all existing maintainers must be @-mentioned in the ticket. If the request is for the purpose of an EPEL branch, also state that you are willing to be made the default EPEL bugzilla assignee.

    This releng ticket must be approved with a +1 vote by at least one FESCo member (other than the request creator, if also a FESCo member). As soon as that happens and as long as there are only +1 votes, the ticket is considered approved. If there are any other votes (0 or -1), FESCo will follow its usual voting policy to approve or reject the ticket.

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