Policy for encouraging comaintainers of packages

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.

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 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 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.

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