Becoming an Emacs contributor (was: [PATCH] Add shell-quasiquote.)

["Óscar Fuentes" <ofv@wanadoo.es>]

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

>>>>>> David Kastrup <dak@gnu.org> writes:
>
>> You don't need to speak in riddles. I am quite used to seeing my name
>> explicitly written in such contexts.
>
> I've found your contributions to be quite helpful on the whole, David.
>
> Lately I've heard and read many things about emacs-devel's "culture" and how
> it stifles newcomers. This is something to take seriously, but I don't think
> the issue should be over-simplified just to find a place to put blame.
>
> We're a lot of people. We have a lot of experiences. This is no one's full-
> time job. We all communicate differently.
>
> Given those truths: as soon as the number of people involved becomes >large,
> any perception you choose to adopt of such a group will generally be true in
> some ways, and false in several other ways.
>
> Some of the concrete problems I've heard about that could be meaningfully
> addressed are:
>
>  1. Some patches die in the bug tracker. They get submitted; the authors
>     respond to the criticism; but there is no closure. This gives people the
>     impression that their efforts are being wasted on Emacs development, so
>     they move elsewhere.
>
>  2. Sometimes people can be abrasive. This isn't something you can solve by
>     mandate, or by posting a code of conduct. It requires a willingness on
>     the part of participants to assume the best of others, and not expect
>     them to do all the work revealing it.
>
>     There could be things we might do here, like making the list passively
>     moderated so we can silence egregious posters. But I haven't seen
>     anything yet to warrant this type of response.
>
>  3. Newcomers don't understand our culture. If you've grown up in the fast-
>     paced GitHub world of one button PRs and brief discussions on Twitter,
>     the culture and pace of emacs-devel may well shock you. Some of us are
>     OLD, and we like our lawns kid-free a goodly part of the time.
>
>     Now that is no excuse for bad manners, but it does mean we don't just
>     "hop to it" when a shiny toy comes along. Be patient, give us time. And
>     maybe, if your patch is withering on the vine, remind someone?
>
> I think we have good people, who pay attention to meaningful issues. Not
> everything we do needs to be instantly appealing to those unfamiliar with our
> history of development. But if it's needlessly off-putting, that should be
> brought up and remedied too.

You forgot *the* problem newcomers face with emacs-devel: bikeshedding.
Even the most trivial contribution can bring huge amounts of discussion,
mostly improductive. And what is productive, often has little real
value. The contributor is overwhelmed by minutia, hypothetical
(unspecified) corner cases, requests for extended features "because we
should completely cover what the user might need", complains about the
code doing too much (at the same time of the previous item.) And
misunderstandings, lots of misunderstandings, which is a huge problem
because some well-meaned top hackers here are overly argumentative. (See
how often emacs-devel or emacs-bugs hosts threads with hundreds of
messages.)

I've made just a few contributions to Emacs and my experience says that
it can be an exasperating process, draining lots of energy. Once you got
commit access and you are trusted to not ask for permission for
operating on certain areas, things turn to be much better, but even then
you confront discussions with other hackers about matters where no clear
criteria exists for setting the matter.

Emacs would benefit from a process that avoids those repetitive,
unproductive discussions that only end when one part resigns by
exhaustion, bringing in frustration.

I think that Stefan tried to do something about this, by encouraging
early inclussion of code, as soon as there was clear that the code is an
improvement for Emacs. In lots of cases, it was obvious that the code
was far from the optimum solution, but it was a positive trade-off.

We could create the figure of mentor, who takes care of a contribution
(singular) and advices the contributor until the code is good enough,
and then he makes sure it is committed. Other people could chime in on
the technical discussion, but the contributor only listens to the
mentor.

BTW, this has nothing to do with the parent thread, which I haven't
followed.