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

[Kaushal Modi <kaushal.modi@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5711 bytes --]

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 <ofv@wanadoo.es> wrote:

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

[-- Attachment #2: Type: text/html, Size: 7970 bytes --]