Volunteer-initiated team maintenance as a solution for packages with low activity

[Michael Gilbert <mgilbert@debian.org>]

Hi,

I would like to throw out an idea for constructively combating low
activity in strongly maintained packages.

Across the Debian package ecosystem team maintainership has been seen
as the strongest antidote for package stagnation.  This process "just
works" because as one team member becomes less active, others tend to
pick up the slack, and the package continues on with a healthy life
cycle.

However, certain areas of the archive remain strongly maintained, and
when those packages enter this kind of low activity state, there is no
clear or established remedy; thus problems ensue.  After time, those
packages stagnate, and absent a healthy team spirit, no one can fix
it.  In fact, often enough potentially helpful volunteers get caught
in a type of thermal discouragement beam when trying to contribute.

Needless to say, this situation is unfortunate for many.  The
potentially helpful volunteer gets a dose of negativity and
potentially loses interest in the package and after enough of these
cases probably Debian altogether, the package stagnates, the existing
maintainer takes on a certain level of guilt and frustration, and
potential Debian users are lost because of resulting package
out-of-dateness qualms.

So anyway, enough explanation, on to my proposed solution.  Seeing as
team spirit has been a quite effective antidote to stagnation, lets go
ahead and use that again.  Here is my suggested process:

1. An interested volunteer notices that an upstream version of a
package has been out for a time frame (perhaps 3 months), but hasn't
been packaged by the existing team or maintainer.  This defines the
low activity state.
2. The interested volunteer files a bug report against the package
stating their intent to contribute
3. If an alioth team already exists, the interested volunteer sends an
email to admin@alioth.debian.org with the following information
  a. Link to upstream release and date
  b. Link to info on latest maintainer activity on package
4. If an alioth team does not exist, the maintainer creates a
collab-maint project
5. The volunteer adds a link to the vcs in their intent to contribute bug report
6. The volunteer adds him or herself as an uploader, makes their other
changes (bug fixes, new upstreams, etc.) and pushes to alioth
7. The volunteer either uploads their package (and future updates)
directly to the archive (if they're a DD) or seeks a sponsor (if
they're not a DD)
8. Continue step 6 and 7 as needed
9. After 6 months of steps 6 and 7, the interested volunteer can send
a message to admin@alioth.debian.org including links and information
about their work over those 6 months requesting to become a project
admin

Note that in step 3, if the existing maintainer disagrees with the
alioth admin approval of the volunteer, he should not be allowed to
directly override that.  He or she would need to make a case to the
alioth admins that the new volunteer has been doing problematic things
and deserves to be removed; otherwise he or she could continue to
block work on the package.

Of course all of this is necessary only if the maintainer is not
supportive (or reactive) in terms of adding team members him or
herself.

Importantly this process avoids the negativity of the MIA process
(that doesn't apply in these cases anyway since low activity is not
zero activity).  In the long-term, the MIA process may just go away as
instead packages gradually/organically become team-maintained, and the
new contributors become established and eventually take over full
responsibility as project admins for the packages that they're working
on.

I know processes within Debian are often seen as bad, but I believe
this one is good (or at least better) because it replaces an existing
negatively perceived top-down process with a self-directed organic one
(i.e. may the best work win).

Best wishes,
Mike