Co-maintainersip policy for Fedora Packages

[Thorsten Leemhuis]

Hi all!

Fedora Extras for a long time wanted to have more than one maintainer
per package as that has several advantages (see below). But until now we
never had a policy how it should look like and how it those maintainers
 should work and interact. I took some time and wrote something up.
Please comment!

CU
thl

P.S.: This stuff (and some more details) can be found in the wiki at
http://www.fedoraproject.org/wiki/Extras/Schedule/EncourageComaintainership

=== Why do we need it ===

There are several reasons why we need it:

 * co-maintainership could be the main new enter path for new Extras
contributors -- people could start their "Extras maintainer life" with
co-maintaining packages when they don't know what to package (a lot
of/most interesting stuff is already packaged so the traditional enter
path Fedora Extras used in the past doesn't scale anymore). Experienced
maintainer could then watch, help and teach the new contributor that
way. If the new contributor showed that he understands everything well
he gets more permissions in Extras -- he for example could take over a
package as primary maintainer

 * upstream maintainers could co-maintain their packages. They could
import the updates while the fedora-maintainers watches their doings and
checks that everything stays compatible to Fedora and the Fedora
packaging guidelines

 * One maintainer does not scale; for example, if a maintainer offline
due to vacations, traveling to conferences or other happenings someone
else has should be easily able to fix security stuff

 * people get when distracted by other projects/work
areas/schedules/real life and can't watch their packages closely to
fix/update stuff

 * people use packages sometimes differently -- one maintainer might be
more interested in feature foo while the other might be more interested
in bar -- let them work together and the package is better maintained
and the quality improved for users that need both foo and bar

 * maintainers of one package could watch and check each others commits

 * we support multiple releases (and will probably support even more in
the future) -- one packager might be interested in devel and FC-current
only while another might be interested in FC-current -1, or EPEL

 * some people maintain more then 50 (one even more then 100) packages
-- we should make sure they don't burn out. And the package quality
probably is better if one maintainer only maintains a smaller number of
packages

 * sponsors could act as primary-maintainer for a new package from a new
contributor in the beginning if they are unsure if the new contributor
is worth sponsoring. The new contributor could do all the work in cvs
while being watched by the sponsor. Only the sponsor would have
permission to request the build of a package in the beginning; the new
contributors gets more permissions if everything worked fine for a while.

=== Policy Proposal ===

----

== Digest ==

All packages in Fedora Extras shall normally be maintained by a group of
maintainers. Each package normally should have at least three
maintainers in total. There is one primary maintainer and a primary
maintainer per distribution release (both often will be identical); he
should have at least one co-maintainer per release.

Maintainers and sponsors are encouraged to use co-maintainership to
educate new contributors an help them getting involved and integrated
into the Project. Maintainers should hand over packages to
co-maintainers when they have lots of packages to improve the quality,
share the load and get people involved.

== Co-maintainership ==

All packages in Fedora Extras shall normally be maintained by a group of
maintainers. That has several benefits; maintainers for example can
watch and help each other. One maintainer further can fix important bugs
(security, data-corruption, whatever!) even when the other maintainer(s)
are offline (traveling, sleeping, whatever).

The goal is to have at least three maintainers per package in total and
at least two per distribution release. Big and important packages should
have more -- there is no upper limit. There is a primary maintainer that
takes care of the package in general; it's his job to make sure the
efforts of the different maintainers get coordinated. Then there is a
primary maintainer per distribution release (often that will be the same
as the primary maintainer); bugs get assigned to him. It does not mean
that he has to do all the work, but he has to make sure the work gets done!

All the maintainers normally should share the load to make sure that all
are familiar with the package -- the Fedora Distribution in a big
community project and keeping something like that running is not be
helped with a "This is my package, I don't want other people touching
it" attitude. Packages primary maintained by Red Hat employees should
have at least one co-maintainer from the community. They should try to
hand over certain regular maintain task to the the community; that
should help getting the community involved everywhere and to get some
load of the Red Hat employees so they can focus on more imporant things
-- that's best for both sides!

Co-maintainership should also make the sponsorship process easier, too.
New contributors can (they don't have to -- that's the decision of the
sponsor) start as co-maintainers for the packages they submitted while
the Sponsor or some experienced packager gets primary maintainer of it.
The new contributor then get limited ACLs first that allow him to only
modify those packages in CVS that they co-maintains. The primary
maintainer can check the things that got changed before he kicks off the
build. The new contributor gets full access after everything worked fine
for a while.

=== Coordination between maintainers ===

The primary maintainer can set individual guidelines what his
co-maintainers are allowed and what not; be has to put them into the
wiki at Packages/<package-name>/MaintainerRules . A hint to that page
should be as comment on the top of the spec file.

Those rules are optional, it normally works like this if no rules were
specified:

 * the per-release primary maintainer takes care of the a package for
that release; he has to make sure the work gets done. He shares the
workload with the co-maintainers. All of them check each others commits
for correctness.

 * all maintainers can directly commit small changes (for example: small
package enhancements/fixups) to cvs. Only the primary maintainers
normally builds them.

 * medium sized changes (for example: update from 1.0.1 to 1.0.2) should
get coordinated. Best and easiest practice it to commit changes if they
are obvious and wait one or two days before building/pushing the package
out to give the co-maintainers a chance to yell if they see problems.
Only the primary maintainers normally builds the update.

 * big changes (for example: update from 1.0.1 to 1.2.0 or heavy changes
in the spec file) should normally get coordinated between the different
maintainers via e-mail or bugzilla before they get committed

 * the usual rules for
[:Extras/Policy/WhoIsAllowedToModifyWhichPackages: modifying other
people packages] remain intact, thus people from QA, Security or
Arch-SIGs might touch the package, too.

 * the primary maintainer handles who is co-maintaining his packages

=== Disputes ===

There are big chances that conflicts will always arise if two or more
people work together on a package (a: "1+1=2"; b: "no, you're stupid;
1+1=10"; c: "you are both stupid, 1+1=11"). There are no hard rules how
maintainers should solve those disagreements. But in practice it should
be something like this:

 * if one maintainer thinks the primary (per release) maintainer is
doing something wrong then the primary (per release) maintainer should
ask a third person (preferred: another maintainer of said package or the
SIG that handles them) as mediator or ask on the mailing list for comments.

 * if two maintainers agree that the primary maintainer is doing
something not as they would like to then the primary maintainer should
really start thinking about changing something to make those two happy.
A fourth person or a SIG can be asked as mediator; the list can be used
to get further comments, too.

If the problems don't get solved that way a FESCo-member should be asked
to mediate.

If co-maintainers get the impression that the primary maintainer is a
lame duck and doesn't do his job properly then they should kindly ask
the primary maintainer to hand over the package. If he's unwilling for
no good reasons or does not respond at all or seems to be AFK then again
a mediator has to be found. FESCo can hand over a package to somebody
else if there is a need to (packager does not respond) if the committee
believes that the co-maintainers will do the job better.

=== Don't maintain to many packages ===

People owning a lot of packages are encouraged to hand over
maintainership to other maintainers with less packages. That should
share the load between different people and result in better overall
package quality, as people that maintain only a small number of packages
often take more care of them than those with a lot of packages. By
handling over packages to other people we let new people learn packaging
and maintaining software in Fedora, too; that should help getting more
people involved into Fedora and let them grow up. That serves the
Project as a whole and is important for us.

Maintainers with lots of packages thus should ask others (existing
co-maintainers and *especially* new contributors that seems to be
willing to get more involved) that seem to be interested in a package to
become a co-maintainer for a package. Educate those co-maintainers a bit
and tell them about the backgrounds of the package and how it was
maintained in the past. Then let the co-maintainer do some work and
watch him. If he does a good job give him more responsibilities over
time and while stepping back from it more and more over time. At some
point hand over the job as primary (release) maintainer to the
co-maintainer when he did the job fine; become a co-maintainer for the
package at the same time. If the new primary maintainer continues to do
a good job consider stepping away completely to yet make more room for a
new packager to get involved.

=== Other aspects of co-maintainership ===

We had some situations where maintainers had to stop maintaining
packages in Fedora. That can happen due to different circumstances --
sicknesses, accidents, changes in the job or at home are only some
examples for reasons to stop. Some of those situations happen suddenly
and are not foreseeable. Due to this maintainers are strongly advised to
build a healthy maintainer community around all of their packages so
those people can take over the packages smoothly even if you stop
maintaining packages tomorrow suddenly because you won in the lottery
and became millionaire.

SIGs can't become co-maintainers per-se. Rather they should observe the
packages or make sure that SIG members are co-maintainers.

=== Intermediate solution ===

We require the PackageDB and some other technical things to really make
above policy possible. Until we have those it works like this:

 * the general and primary-maintainers for each release are always
identical (exception: EPEL); it's the one that listed as first in
owners.list

 * co-maintainers all get listed in the last field in owners.list

 * there are no ACLs yet in the VCS, thus we need to find ways to live
without them

 * all packages should have at least two co-maintainers