From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kaushal Modi Newsgroups: gmane.emacs.devel Subject: Re: Becoming an Emacs contributor (was: [PATCH] Add shell-quasiquote.) Date: Tue, 20 Oct 2015 12:47:01 -0400 Message-ID: References: <87si59wj42.fsf@T420.taylan> <878u6znii9.fsf@T420.taylan> <836123gfh2.fsf@gnu.org> <87r3krm0t3.fsf@T420.taylan> <5624F66F.1030600@yandex.ru> <87io63lzkg.fsf@T420.taylan> <562508B7.3020202@yandex.ru> <876122n5v3.fsf@T420.taylan> <22053.50324.60123.654292@turnbull.sk.tsukuba.ac.jp> <87d1waknl1.fsf@T420.taylan> <87oafugeia.fsf@fencepost.gnu.org> <87io61epbv.fsf_-_@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113d57c62392e805228c050f X-Trace: ger.gmane.org 1445359691 1315 80.91.229.3 (20 Oct 2015 16:48:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 Oct 2015 16:48:11 +0000 (UTC) Cc: Emacs developers To: =?UTF-8?Q?=C3=93scar_Fuentes?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 20 18:48:11 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zoa4y-0003O5-Bc for ged-emacs-devel@m.gmane.org; Tue, 20 Oct 2015 18:48:04 +0200 Original-Received: from localhost ([::1]:47076 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zoa4x-0005IL-SJ for ged-emacs-devel@m.gmane.org; Tue, 20 Oct 2015 12:48:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40486) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zoa4d-0005Ei-F9 for emacs-devel@gnu.org; Tue, 20 Oct 2015 12:47:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zoa4b-0000zV-Dx for emacs-devel@gnu.org; Tue, 20 Oct 2015 12:47:43 -0400 Original-Received: from mail-oi0-x22b.google.com ([2607:f8b0:4003:c06::22b]:35791) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zoa4b-0000z2-7K for emacs-devel@gnu.org; Tue, 20 Oct 2015 12:47:41 -0400 Original-Received: by oiev17 with SMTP id v17so13467525oie.2 for ; Tue, 20 Oct 2015 09:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=92SVk4TYQFXMNFDVoMuUJa3vlML1MwdpH6GLcrxuaho=; b=QjSG101RgizMc8Le1D3zxuYvTk424rRUT9RGOc4fmQCC12fLmeueiWrVZOsm9RFOyz kNPUukmY7AwkFAkJ+hOfJRd78TSrXXFek10YjDg8oCAaDegz0nxioF3E5jDtK5vn3bUT IsL4qWFX6kwTGNYqzNbBytrSSDGBBHfTzzt02J4BTY7nY+0L2GpwdAw97rdWYp5s4Gky sqOCOncrZXLrJ2HZdsoDLB2b7iFxHSZoCu7EBtp6hKjpsFljMXodn0EQ7vGiWIaEG3XJ xY/KtphaRUG/h5BP/WEoSlOUAYPXu0A6+dLBmWPknjzpbKaA6VWWcWW3iq4qJYnHFP59 ifXQ== X-Received: by 10.202.221.68 with SMTP id u65mr2665314oig.34.1445359660534; Tue, 20 Oct 2015 09:47:40 -0700 (PDT) Original-Received: by 10.202.44.8 with HTTP; Tue, 20 Oct 2015 09:47:01 -0700 (PDT) In-Reply-To: <87io61epbv.fsf_-_@wanadoo.es> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c06::22b X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:192202 Archived-At: --001a113d57c62392e805228c050f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, =C3=93scar Fuentes wrote: > "John Wiegley" writes: > > >>>>>> David Kastrup 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" an= d > 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 meaningful= ly > > addressed are: > > > > 1. Some patches die in the bug tracker. They get submitted; the author= s > > respond to the criticism; but there is no closure. This gives peopl= e > 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 solv= e > 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 expe= ct > > 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 ju= st > > "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. No= t > > 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. > > > --001a113d57c62392e805228c050f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On the contrary, I had a very pleasant exp= erience making my first contribution to emacs core very recently.

As Emacs is used by people from varie= d fields of interest, a corner case for one person might be the only a majo= r use case for another.

This= first contribution wasn't one-shot. I did not email a patch that got c= ommitted 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 m= eet 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 chec= ked not from just one person's perspective.

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





--
Kaushal Modi

On Tue, Oct 20, 2015 at 7:45 AM, =C3=93scar = Fuentes <ofv@wanadoo.es> wrote:
"John Wiegley" <jo= hnw@newartisans.com> writes:

>>>>>> David Kastrup <d= ak@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, Da= vid.
>
> Lately I've heard and read many things about emacs-devel's &qu= ot;culture" and how
> it stifles newcomers. This is something to take seriously, but I don&#= 39;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 on= e's full-
> time job. We all communicate differently.
>
> Given those truths: as soon as the number of people involved becomes &= gt;large,
> any perception you choose to adopt of such a group will generally be t= rue in
> some ways, and false in several other ways.
>
> Some of the concrete problems I've heard about that could be meani= ngfully
> addressed are:
>
>=C2=A0 1. Some patches die in the bug tracker. They get submitted; the = authors
>=C2=A0 =C2=A0 =C2=A0respond to the criticism; but there is no closure. = This gives people the
>=C2=A0 =C2=A0 =C2=A0impression that their efforts are being wasted on E= macs development, so
>=C2=A0 =C2=A0 =C2=A0they move elsewhere.
>
>=C2=A0 2. Sometimes people can be abrasive. This isn't something yo= u can solve by
>=C2=A0 =C2=A0 =C2=A0mandate, or by posting a code of conduct. It requir= es a willingness on
>=C2=A0 =C2=A0 =C2=A0the part of participants to assume the best of othe= rs, and not expect
>=C2=A0 =C2=A0 =C2=A0them to do all the work revealing it.
>
>=C2=A0 =C2=A0 =C2=A0There could be things we might do here, like making= the list passively
>=C2=A0 =C2=A0 =C2=A0moderated so we can silence egregious posters. But = I haven't seen
>=C2=A0 =C2=A0 =C2=A0anything yet to warrant this type of response.
>
>=C2=A0 3. Newcomers don't understand our culture. If you've gro= wn up in the fast-
>=C2=A0 =C2=A0 =C2=A0paced GitHub world of one button PRs and brief disc= ussions on Twitter,
>=C2=A0 =C2=A0 =C2=A0the culture and pace of emacs-devel may well shock = you. Some of us are
>=C2=A0 =C2=A0 =C2=A0OLD, and we like our lawns kid-free a goodly part o= f the time.
>
>=C2=A0 =C2=A0 =C2=A0Now that is no excuse for bad manners, but it does = mean we don't just
>=C2=A0 =C2=A0 =C2=A0"hop to it" when a shiny toy comes along.= Be patient, give us time. And
>=C2=A0 =C2=A0 =C2=A0maybe, if your patch is withering on the vine, remi= nd someone?
>
> I think we have good people, who pay attention to meaningful issues. N= ot
> everything we do needs to be instantly appealing to those unfamiliar w= ith our
> history of development. But if it's needlessly off-putting, that s= hould 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.



--001a113d57c62392e805228c050f--