Policy for encouraging comaintainers of packages
All packages in Fedora should normally be maintained by a group of maintainers. Having at least two active maintainers for each package in Fedora is encouraged. Big and important packages should have more maintainers — there is no upper limit.
Reasons for having more than one maintainer are:
One maintainer can commit fixes even when the other maintainers are away.
Maintainers can guide each other, leading to better overall package quality.
If a maintainer stops maintaining their package for whatever reason, co-maintainers can smoothly take over.
Co-maintainership gets new people involved in Fedora.
The burden of experienced maintainers is reduced, so they get a chance to get involved with more complicated and important parts of the project.
There is a primary maintainer who takes care of the package in general. It is their job to approve and find new maintainers and to make sure their efforts get coordinated, especially between Fedora and EPEL.
The maintainers should actively work towards getting at least one co-maintainer.
Anybody who has been sponsored to the packager group can be a co-maintainer. Package sponsor policy has special instructions for the case where somebody who has not been sponsored yet wants to become a co-maintainer.
SIGs cannot be primary maintainers, but they can be co-maintainers.
The primary maintainer approves or rejects new co-maintainers. They can also remove co-maintainers if there is a reason to do so.
The primary maintainer cannot block co-maintainers for EPEL only because they do not want to support EPEL. If they do not want to care about their package in EPEL, they have to accept somebody who does.
Bugs get assigned to the primary maintainer, who is in charge of the package. It does not mean that they have to do all the work, but they have to make sure the work gets done.
In case the primary maintainer is not interested in maintaining the package also for EPEL, the assignee for EPEL bugs can be changed to another maintainer.
Co-maintainers have the same access to the package as the primary maintainer. Changes should have the consensus of all maintainers behind them, either implicitly or, as needed, explictly.
All maintainers should check each other’s commits for correctness and sanity.
Regardless of how many co-maintainers a package has, the usual rules for Who is Allowed to Modify Which Packages remain. Thus provenpackagers might touch the package, too.
Disputes may happen when two or more people work together on a package. Most of them will probably be solved without much noise, but in case not, here are some suggestions:
if two maintainers are in disagreement over a detail, ask the third maintainer
if no consensus can be found, ask on the appropriate mailing list
if still no consensus can be found, ask FESCo to mediate
If co-maintainers get the impression that the primary maintainer does not do their job properly, they should kindly ask them to hand over the package. If they are unwilling for no good reason or seem to be non-responsive, the Policy for nonresponsive package maintainers can be invoked as needed.
The following sections describe some guidelines how co-maintainership should be used in practice. Note that the section title is "guidelines", and not "rules". In other words: you do not have to follow the guidelines if you have a good reason. But please keep in mind that they were carefully written to take the interest of the project as a whole into account, to make sure Fedora stays healthy and grows up — that might not be obvious on the first sight.
The primary maintainer can set individual guidelines on what their co-maintainers are allowed and not allowed to do. When they do so, they should keep Fedora’s goals as a whole in mind. Fedora is a big community project, keeping it running is not much helped by "This is my package, I don’t want other people touching it" attitude.
There is a lot of work to do in Fedora and we should try to get many contributors into the project to get the work done, the load shared and Fedora improved.
If you have already showed ability and gained respect by properly maintaining a lot of packages, it might be time to slowly move on to more serious stuff. To get the time needed for that, it might be a good idea to hand over some packages to other interested contributors that are still on their way up. That can often be easily achieved by educating co-maintainers over time and handing packages over to them when they have shown to be doing a good job. That should help new contributors finding their way into the project and growing up. It should also share the load between the different contributors which could even lead to a better overall package quality.
Nobody can be forced to maintain packages, so sometimes it might happen that a package has only one maintainer. That is fine, but the maintainer should now and then ask other contributors or interested users to become co-maintainers. Especially packages with large numbers of open bugs will need more co-maintainers to try and help solve them.
The procedure is described here.