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

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.

Policy

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.

Who can be a co-maintainer?

Anybody who has been sponsored to the packager group can be a co-maintainer. Packager 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.

Approving and rejecting 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.

Assigning bugs

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.

What are co-maintainers allowed to do?

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

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.

Guidelines

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.

Coordination between maintainers

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.

Do not (co-)maintain too many packages

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.

Sometimes there is only one maintainer

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.

Upstream developers as co-maintainers

Ask upstream developers to become a co-maintainer or an observer of the package. That could benefit both sides.

Procedure

The procedure is described here.