Re: Becoming an Emacs contributor

[Taylan Ulrich Bayırlı/Kammer]

Óscar Fuentes <address@hidden> writes:

> "John Wiegley" <address@hidden> writes:
>
>>>>>>> David Kastrup <address@hidden> 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.

This actually sounds pretty similar to what happened in this thread in
some ways, although it differs in other ways, so thanks for the input!

Taylan