Re: Another others for maintainer?

[Eli Zaretskii]

> From: "John Wiegley" <address@hidden>
> Date: Tue, 20 Oct 2015 16:44:00 -0700
> Cc: address@hidden, address@hidden
> 
> My ideal scenario is this:
> 
>  - I'm willing to act as "project manager" in the non-technical sense. That
>    is, charting the course, working with contributors, planning releases,
>    keeping an eye on matters of concern, liaising with the FSF. This is a
>    pleasant role for me, and doesn't require daily output.
> 
>  - Eli -- without whom even *imagining* this would be impossible

Thanks, but you make this sound like if tomorrow I'm overrun by a bus,
Emacs will die, or at least stagnate.  Which of course is not true.
There are quite a few people here without whom Emacs development would
not have been what it is, let alone what it (hopefully) will be.

>                                                                   -- would
>    become our primary technical lead, the person I rely on most to keep the
>    ship aright and stay on top of bug submissions and patches.

If you don't have enough time to actively engage in technical issues,
like discussing development and design/implementation decisions,
reviewing patches, fixing bugs, etc. -- then the above scenario is not
viable.  There's no chance in the world I alone will be able to deal
with that workload: I have neither the time nor knowledge (nor talent,
to be honest) to do that.  So we will need at least some of the team
you describe here:

> Eli and I, in turn, would start assigning responsibilities and delegating to
> others, until we have a distributed team of hopefully 10-20 people, each with
> their own time, energy, experiences and expertise.

We need this as a _prerequisite_ for announcing that the new
maintenance team is in place and has assumed its responsibilities.
Without them, this simply won't work; we shouldn't even try.

10-20 people is probably an ambitious goal, but at least around 5 is
IMO the necessary minimum.  Those individuals will have to agree to be
part of the team, ideally also tell which areas they would like (or
consider themselves able) to be responsible for, so that many (most?)
issues will have a clear addressee in the team.

Lack of hands is crucial here.  If we don't collect enough hands to
routinely and efficiently perform the day-to-day duties -- reviewing
and approving patches, analyzing bugs, writing documentation -- we
will never be able to sustain the intensity and pace of development
we'd like to have.

P.S. I think many people don't realize how many simple, mundane tasks
are part of what we call "Emacs maintenance".  Stuff like fixing
spelling errors, committing auto-generated files, fixing unsafe or
sub-optimal code revealed by compiler warnings, closing bugs that were
resolved but left open, merging bug reports for the same bug, fixing
typos in generated log messages, managing our mailing lists and the
Web site -- all this is part of the job.  That we currently have a few
kind people like Glenn, Paul, Juanma, and others silently doing this
behind the scenes (look at "git log" to see what I mean) is sheer
luck.  People who want to help could start with these small but
important tasks.  With time and experience, they will gain confidence
in their talents and abilities, and -- no less important -- upgrade
their status within the community, and that will help them decide
which larger tasks they could take upon themselves.