Ideas for Co-maintainership in Extras

[Thorsten Leemhuis]

Hi all!

Welcome everybody to my brain dump of ideas around co-maintainership for
Fedora Extras.

== 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 packages so the traditional enter
path doesn#t scale anymore). Experienced maintainer could watch, help
and teach the new contributor. 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 and the main fedora-maintainers watches their doings
and checks that everything stays compatible to Fedora Core and the
Fedora packaging guidelines

* Someone has to fix security stuff during those time periods if a
problems went public but everybody is offline now and then for some
time, take for example vacations or traveling to conferences. I suspect
 that a lot of contributors probably are far away from a computer at
least once a year for for one, two, three, four or even more weeks --
co-maintainers could fix stuff in those timeframes.

* 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

* all 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 -2, but has
no interest in FC-current or devel

* 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 might be interested -- they 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.

* Reviewers could automatically be made temporary comaintainers of the
packages they review so they see that the packager is doing the right
things to get it to build in the build system for the first time, etc.

* co-maintainership maybe could be used in Core, too -- e.g. the primary
maintainer with access to the buildsys could be someone from Red Hat,
while the co-maintainers are from inside and outside of Red Hat. That
probably would help get load of the shoulders from Red Hat maintainers
and increase package quality.

* Packaging-SIGs (like the Extras Games SIG) or their primary members
could act as co-maintainers for all packages that fall into the SIGs
working area

There are probably even more reasons a that don't come to my mind now.

== What we need to make all that happen ==

* we need limited access in the VCS -- e.g. new contributors that start
as co-maintainers get only access to the packages they co-maintain, but
not to the buildsys or to other packages

* per repo maintainers should be possible -- we probably need a proper
the package database for this

* primary- and other co-maintainers need to get mails directly into
their inbox for everything other maintainers do with a package (commit
changes, updates, upload of new files, build requests, pushes).

* rules need to be written, e.g.
 * responsibilities between co-maitainer and primary maintainer
 * Bug responsiveness
 * do we need a primary maintainer at all?
 * can N (N=4?) co-maintainers outvote the primary maintainer in case of
disputes?
 * can there be takeovers ("I'm doing all the work and my primary
maintainer never does anything; I want to take the package over")
 * probably a lot more...
 * "new contributors have to actively co-maintain one package for at
least X months before they can take over this or other packages
completely (they of course can also take the traditional route with a
new package and sponsoring)


== Action plan ==

=== Short term ===

* Fix bugzilla auto-CC in owners.list -- see
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198109

* evaluate in detail the technical groundwork we need for proper
co-maintainership -- especially package database, VCS, the accounts
system and everywhere else

=== Middle term ===

* Wait for the new package database to finish and make sure it offers
everything we need (maintainers per dist, ...)

* encourage co-maintainership in general -- I'd say that 95% of Extras
packages should have co-maintainers (the other 5% are packages for
special interest areas where only one of the current contributors might
bne interested in)

* especially encourage co-maintainership or even a package hand-over to
those people that maintain a lot of or important packages

* work out detailed rules for co-maintainership (see above)

=== Long term ===

* make sure co-maintainers get mails when one of their packages is
changed in CVS or build (people can set up local filters to get
something like that but it's often forgotten and likely to break; a
feature like this is also interesting for sponsors that want to watch
people they sponsored closely)

* make co-maintainership possible in core, too.

== EOF ==

Comments?

CU
thl