Maintainers and contributors (was: Contributors and maintainers)

[John Wiegley <johnw@newartisans.com>]

>>>>> John Wiegley <johnw@newartisans.com> writes:

> Part of the debate seems to be a lack of appreciation of the difference
> between contributors and maintainers. You see, it is not sufficient to have
> a good idea, no matter how clear it is to its submitter. *We* maintain
> Emacs, and so the change must satisfy *us*, no matter how thick our skulls
> may be. If we ask for clarification that Wednesday follows Tuesday, either
> you provide us with that clarification, or the change doesn't go in. Period.

After I sent this message, it occurred to me that while I had strongly
represented one side of this equation -- the needs of maintainers -- I had
omitted to stress the importance of contributors. Thanks to RMS for reminding
me of this discrepancy. Now let me expound on that side of things.

While it's true that maintainers must agree to what they will maintain, and
that contributors must -- to play in our sandbox -- reach some accord with the
maintainers, this may have made it sound like maintainers are all important,
and contributors are only incidental to Emacs' success. But that is only half
of the story.

What moderates the maintainers use of authority is the fact that contributors
are our *number one* most valued resource. As good, energetic and diligent as
a maintainer may be, he or she cannot perform the work of a hundred, of a
thousand people. Contributors can do this. The role of a good maintainer is to
enable and coordinate this massive sea of energy toward the best end results
for our project.

This typically leads to an easy and natural balance: Contributors respect
maintainers, so their code is accepted; and maintainers respect contributors,
so they generate more code. As long as this synergy is maintained, we all
become more potent than we could ever be alone.

So I'd like to emphasize, to our maintainers, that we must strive to make
patience, kindness, and consideration, our primary attributes when dealing
with contributors -- especially those new to the process, who are developing
their first impressions, and based upon which will either continue to help us,
or walk away frustrated.

[This is not a reflection of malfeasance on anyone's part this week; simply it
is a reminder that our contributors are the lifeblood of our project, and will
someday soon be taking our place.]

John