English Italian
Non-responsive maintainer policy
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.
This policy covers existing Fedora packages, containers, and modules; for non-responsive package submitters or reviewers, see the xref:Package_review_policy.adoc#stalled[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 link:https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/[How to get sponsored into the packager group].
When a Fedora member notices that a maintainer isn't answering their bugs, not answering rebuild requests, link:https://src.fedoraproject.org[src.fedoraproject.org] pull requests, emails, or the like, these steps should be followed:
**Week 0**
Check if the non-responsive maintainer is on link:https://calendar.fedoraproject.org/list/vacation/[vacation]. To see if the maintainer has been recently active on Fedora, link:https://github.com/pypingou/fedora-active-user[fedora-active-user] can be employed.
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 link:https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&format=fedora-nonresponsive-maintainer[nonresponsive package maintainer], link:https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora+Container+Images&format=fedora-nonresponsive-maintainer[nonresponsive container maintainer], or link:https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora+Modules&format=fedora-nonresponsive-maintainer[nonresponsive module maintainer]). This is a *must*.
Post to the Fedora link:https://admin.fedoraproject.org/mailman/listinfo/devel[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**
After 7 days, submit a link:https://pagure.io/fesco/new_issue/?template=nonresponsive-maintainer&title=Nonresponsive%20maintainer:%20%3Cname%3E%20%3Cfas-id%3E[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.
If at least one FESCo member votes +1 and no one votes differently, the ticket is approved after three days. Otherwise, FESCo will discuss the issue during a meeting.
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**
A week later FESCo posts a reminder in the ticket, @-mentioning the maintainer.
**Week 3**
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;