git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Emily Shaffer <emilyshaffer@google.com>
To: Denton Liu <liu.denton@gmail.com>
Cc: Derrick Stolee <stolee@gmail.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>,
	"peff@peff.net" <peff@peff.net>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	"gitster@pobox.com" <gitster@pobox.com>,
	garimasigit@gmail.com
Subject: Re: [DISCUSSION] Growing the Git community
Date: Thu, 19 Sep 2019 13:43:21 -0700
Message-ID: <20190919204321.GA116396@google.com> (raw)
In-Reply-To: <20190919173423.GA70421@dentonliu-ltm.internal.salesforce.com>

On Thu, Sep 19, 2019 at 10:34:23AM -0700, Denton Liu wrote:
> Aside from getting the first email sent, most of my time learning to
> contribute to Git stemmed from the fact that there's a lot of tribal
> knowledge that's not really written down anywhere. Here are some of the
> smaller things that confused me:

+1 to unwritten knowledge. I learned quite a lot from comments on my
early reviews about utilities and patterns which I had no idea existed.
I'd love to see more and better-organized documentation in Git project
(in fact, that's one of my goals for this year - a contributor's manual,
which was one of the topics discussed at the virtual summit).

> Another discouraging thing when I was just starting out was sending a
> out a patch and just getting radio silence (especially the first one, I
> wasn't sure if it even sent out properly!). Perhaps in the main list, we
> could get people to tag with [FIRST PATCH] or something when sending in
> their first patch.
> 
> If the patch is not desired, then we should explain why it wasn't
> desired instead of just leaving them hanging. I know Junio is too busy
> to say "hey, I'm picking this patch up" to every single patchset, but if
> a patch is desired, perhaps the rest of us could pick up the slack and
> say, "hey, your patchset was picked up by Junio in his gitster repo on
> this branch".

I wonder how feasible it really is to expect people to review more/more
quickly than they are today. It might be more realistic to try to temper
folks' expectations in the new contributor documentation.

This might also be a problem which starts to disappear as the number of
contributors rises...

> > 
> > 4. Add an official Code of Conduct
> > 
> > So far, the community has had an unofficial policy of "be nice,
> > as much as possible". We should add a Code of Conduct that is
> > more explicit about the behavior we want to model. This was also
> > discussed in the meeting with wide approval.
> 
> From what I've personally read and experienced, I don't think that an
> official Code of Conduct is really warranted. Everyone I've interacted
> with has been really kind. Perhaps a new contributor might interpret the
> curtness of replies here as someone being rude but I quickly learned
> that it's more out of necessity since everyone is busy.
> 
> From reading the mailing list archives, I know that in the past, there
> have been some flamewars and some abrasive individuals but I think
> that's a problem of the past.

I disagree pretty strongly - I think that the fact that we did have
problems in the past indicates that we're at risk for similar problems
in the future.

In my opinion, a code of conduct shouldn't be introduced to deal with
behavior when it arises - that invites parties to feel that they're
being targeted for behavior that "used to be okay". We introduce a CoC
to protect ourselves in the future, and to maintain the pleasant
community we have today.

> I also see some drawbacks to implementing a CoC as well. First of all,
> it just feels like unnecessary bureaucracy. Second, I think it'll
> probably cause a stir like it did when the Linux kernel introduced it.
> Of course, all that noise will die down eventually but I feel like it'll
> bring the wrong kind of attention to Git.

As a member of >1 groups which are prone to receiving harassment online,
I don't find it unnecessary at all for there to be a path for me to
escalate and resolve harassment I am the victim of.

As for the stir in the Linux kernel, I find it interesting that most of
the attempts to revert the CoC came via Github PRs - which the kernel
does not use. Another way of saying that is that most of those attempts
came from people who did not regularly contribute to the kernel, and did
not care enough about contributing to it in the future to discover the
correct contribution process.

I realize I'm taking a hard line here, but I'm not sure how "Git wants
to protect its contributors from harassment" is the "wrong" kind of
attention. If I weren't contributing to Git actively and I saw that
news, I would feel inspired and optimistic (again, speaking as a member
of groups which are often harassed online and in tech).

> (Then again, maybe it'll attract more contributors in the process, who
> knows.)


I totally understand where you're coming from, Denton, that it's not a
problem now and so it may not be worth the effort+press. But I wonder
how many folks we're missing out on patches from because they don't
think they will have recourse if they find the community to be
toxic/unwelcoming to them? We really don't have a way to know. I'm
worried that we're restricting the community to those who either
feel it's unlikely that they'll be targeted, or feel they can weather
harassment if they receive it - which narrows the diversity of our
contributor base by quite a lot.

 - Emily

  reply	other threads:[~2019-09-19 20:43 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-19 16:30 Derrick Stolee
2019-09-19 17:34 ` Denton Liu
2019-09-19 20:43   ` Emily Shaffer [this message]
2019-09-19 22:26   ` Jeff King
2019-09-20 17:48     ` Junio C Hamano
2019-09-20 15:22   ` Garima Singh
2019-09-20 17:51     ` Junio C Hamano
2019-09-19 18:44 ` Klaus Sembritzki
2019-09-19 19:12   ` Klaus Sembritzki
2019-09-19 20:20     ` Klaus Sembritzki
2019-09-20  5:04       ` Klaus Sembritzki
2019-09-20  5:41         ` Klaus Sembritzki
2019-09-20  6:54           ` Klaus Sembritzki
2019-09-20  7:43             ` Klaus Sembritzki
2019-09-20 10:25               ` Klaus Sembritzki
2019-09-19 21:40 ` Mike Hommey
2019-09-23 21:28   ` Johannes Schindelin
2019-10-01 15:03     ` Jakub Narebski
2019-09-19 22:16 ` Jeff King
2019-09-20  2:17   ` Derrick Stolee
2019-09-20  2:23     ` Jeff King
2019-09-19 22:21 ` Elijah Newren
2019-09-25 13:36   ` Pierre Tardy
2019-09-25 14:02     ` Derrick Stolee
2019-10-04 12:39       ` Jakub Narebski
2019-09-25 14:14     ` Philip Oakley
2019-10-04 10:48   ` Jakub Narebski
2019-11-12 18:45   ` Emily Shaffer
2019-11-12 20:01     ` Johannes Schindelin
2019-11-13  6:45       ` Christian Couder
2019-11-13 15:06         ` Thomas Gummerer
2019-11-14  2:31           ` Emily Shaffer
2019-11-14  6:06             ` Jeff King
2019-11-15  4:48               ` Junio C Hamano
2019-11-14  6:08             ` Pratyush Yadav
2019-11-14 10:01               ` Thomas Gummerer
2019-09-20 10:48 ` Philip Oakley
2019-09-20 14:36 ` brian m. carlson
2019-09-20 15:16   ` Randall S. Becker
2019-10-04 14:27   ` Jakub Narebski
2019-09-20 15:20 ` Garima Singh
2019-09-20 17:43 ` Junio C Hamano
2019-09-20 18:52   ` Junio C Hamano
2019-09-23 12:36 ` Derrick Stolee
2019-09-23 21:46 ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190919204321.GA116396@google.com \
    --to=emilyshaffer@google.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=garimasigit@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=liu.denton@gmail.com \
    --cc=peff@peff.net \
    --cc=stolee@gmail.com \
    --subject='Re: [DISCUSSION] Growing the Git community' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git