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

[Kaushal Modi]

On the contrary, I had a very pleasant experience making my first contribution to emacs core very recently.

As Emacs is used by people from varied fields of interest, a corner case for one person might be the only a major use case for another.

This first contribution wasn't one-shot. I did not email a patch that got committed right away. I had CC'd the primary committer of the package to which I was contributing to. He automatically became my mentor and guided me through multiple versions of my patch, while making it more robust and meet every corner case we could collectively think of.

For newbie committers, I think that we need to be patient and listen to what more experienced coders have to teach.

The code robustness needs to be checked not from just one person's perspective.

TL;DR: My first contribution to emacs was a pleasant experience and I will contribute more.

--
Kaushal Modi

On Tue, Oct 20, 2015 at 7:45 AM, Óscar Fuentes <address@hidden> wrote:

"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.