Re: [PATCH v2] MyFirstContribution: add avenues for getting help

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Nov 20, 2019, 11:41 UTC
Message-ID: <nycvar.QRO.7.76.6.1911201222490.15956@tvgsbejvaqbjf.bet>
In-Reply-To: <20191119214101.GN23183@szeder.dev>

Hi Gábor,

On Tue, 19 Nov 2019, SZEDER Gábor wrote:

Show 26 quoted lines

> On Tue, Nov 19, 2019 at 10:29:43PM +0100, Johannes Schindelin wrote:
> >
> > On Tue, 19 Nov 2019, SZEDER Gábor wrote:
> >
> > > On Mon, Nov 18, 2019 at 01:45:19PM -0800, Emily Shaffer wrote:
> > >
> > > > I don't mind the idea of pushing folks to ask on the mentoring list
> > > > first. It's pretty well attended already - just now I count 16 list
> > > > members, a pretty significant majority of which are project veterans.
> > > > I have no problem suggesting newbies ask their questions, which others
> > > > probably had and solved before them, in a space separate from the main
> > > > mailing list.
> > > >
> > > > Of course if you want to encourage newbies to ask in any of these
> > > > three venues, weighted equally, I can change the language. But
> > > > suggesting the main list as a last resort was intentional.
> > >
> > > git@vger is the ultimate source of all wisdom :) and it is openly
> > > accessible for anyone for writing,
> >
> > ... except people with an @outlook.com address (all of their emails will
> > bounce) and people who do not know how to suppress HTML in their emails
> > (which I believe constitutes the vast majority)...
>
> And I believe that that "vast majority" will never try to contribute
> to Git, and thus doesn't matter.

Yes, this is a tautology, because by that very expectation you make that happen. It's kind of a perfect example of a self-fulfilling prophecy.

And while I write this, I realize that my answer is not even data-driven. So *clicketyclick*:

$ git shortlog -nse | grep outlook
     6  Force Charlie <charlieio@outlook.com>
     1  Rohit Mani <rohit.mani@outlook.com>

Oh wait, what? That vast majority will never contribute? Not so "never", after all. Well, it is certain that they do not feel invited to the Git mailing list, that much is clear. Force Charlie's contributions probably all came in via Git for Windows (because it does not slam the door in the face of Outlook.com users, is my guess).

But Rohit is an interesting case. Apparently in 2014, vger had no qualms about letting @outlook.com users in:

https://public-inbox.org/git/BLU0-SMTP956BEABA437FB370F76953918A0@phx.gbl/

Well, I guess as long as we can make a nice and cozy place for ourselves and our kind here, and contend ourselves with the knowledge that the rest of them out there don't matter, all is fine and dandy.

Or maybe it is not. Maybe this is not fine and dandy at all.

Maybe I find this very much _not_ in line with the decency that I normally see on this here Git mailing list, in particular with the later arrivals. With the politeness and respect for other people and their different tastes (such as the taste for HTML-formatted mails, which _do_ make conveying certain things a lot easier) that I hoped we could all agree on, and which I actually did feel during our Virtual Contributor Summit earlier this fall.

I don't know about you, but if I were to read on any mailing list that I do not matter at all, I would have a range of totally understandable feelings about that.

In short: This is not what I want to see on this list, it is not in line with my understanding of being respectful to one another.

Let's hold ourselves to a higher standard, okay?

Ciao, Dscho

Show 6 quoted lines

> > > reading, and searching.  Therefore these three venues cannot be weighted
> > > equally, but git@vger should be the explicitly preferred venue.  Only if
> > > the newbie has some other preferences should the other two be
> > > considered; e.g. if more interactive, chatty communication is preferred,
> > > then try #git-devel.
>

P.S.: I _think_ that I understand where exclusive behavior comes from, of course, there is ample research about this, see e.g. https://en.wikipedia.org/wiki/In-group_and_out-group. This explains it, but does not excuse it.