Re: New maintainer

[Xue Fuqiao <xfq.free@gmail.com>]

On Sat, Oct 3, 2015 at 4:04 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> Emacs is so large that its maintenance is IMO qualitatively different
> from almost any other package out there.  There are maybe a dozen
> distinct large areas of expertise in the C core, dozens of such areas
> in core Lisp infrastructures, and hundreds of them on the application
> level.  Each one of these comes with its own non-trivial
> domain-specific knowledge, its own algorithms, its own do's and
> dont's.  No single person nor a small (2-3) number of people could
> ever cover all that turf in any reasonable way.
>
> By contrast, a head maintainer seems to be expected to be the final
> authority for making decisions on changes in any particular area, and
> also on design and implementation of both significant and
> insignificant new features.
>
> So, given this seemingly unsolvable contradiction, what do you, the
> crowd, expect of the new maintainer?  What "job description", in
> addition to what Richard wrote, would you propose if you were tasked
> with the job of finding the candidates?  E.g., how many hours a week
> should that person be available for working on Emacs?  Which talents
> and personal traits should he or she possess?  Etc. etc.

The head maintainer should make policy about the general direction of
Emacs, and should make final decisions.

Since one single maintainer or a small team can't "cover all that turf",
the decision-making can be distributed to a range of participants.  I
think a (documented) decision-making policy would be nice.  When a new
idea, feature, patch, etc. turns up in the mailing lists (most likely on
emacs-devel), voting, for example, can be helpful for gauging the
community's general sentiment, or help the head maintainer make a
decision if he or she is not familiar with the domain-specific knowledge
of a package/area.  It doesn't have to have a binding force.  Voting can
be done with numbers (+1, -1, 0), and a -1 vote should include an
alternative proposal or a detailed explanation of the reasons for the
vote.  Of course, to provide an opportunity for participants from all
over the world, there should be a minimum voting duration (e.g., 72
hours).  But IMHO using a vote tracking system like Debian's devotee[1]
is overkill.

Or, the head maintainer only makes a decision when:
* it needs urgent action
* nobody else has responsibility (perhaps judged by `admin/MAINTAINERS'
  and/or the `Maintainer' header in a file)
* we can't reach an agreement

As for "job description", in addition to what Richard wrote, I think the
head maintainer should also:
* know the overall situation of Emacs well
* be familiar enough with Emacs Lisp, C, and Git
* be comfortable with Debbugs (or be willing to find a good alternative
  that can still be controlled with email and write import scripts from
  Debbugs and assist its deployment inside the FSF infrastructure)
* be comfortable with Texinfo
* (at least) have some basic understanding of the GNU build system
* keep an eye on GNU ELPA commits, not only Emacs core

Moreover, IMO if an Emacs developer nominate herself as a candidate head
maintainer, she should summarize her plans for her term.  For example,
if I self-nominate for that role, I'll write something about how to make
Emacs easier to contribute, the release schedule, when to
obsolete/deprecate features, how to improve the bug-fixing workflow and
the testing infrastructure, how to cooperate/communicate better with
popular third-party packages (like Magit/CIDER/Projectile), and write a
draft feature roadmap (dynload/modules, concurrency, new extension
languages, FFI, i18n, GUI builder, etc.).

[1] https://www.debian.org/vote/