list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <>
To: Derrick Stolee <>
Cc: "" <>,
	Emily Shaffer <>,
	Jonathan Nieder <>,
	Johannes Schindelin <>,
	"" <>,
Subject: Re: [DISCUSSION] Growing the Git community
Date: Thu, 19 Sep 2019 18:16:15 -0400
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Sep 19, 2019 at 12:30:13PM -0400, Derrick Stolee wrote:

> Feel free to pick apart all of the claims I make below. This is based
> on my own experience and opinions. It should be a good baseline
> for us to all arrive with valuable action items.

First off, thanks for starting this conversation on the list.  I agree
with 99% of what you said, so I'll quote sparingly below, and just cover
the parts where I have something interesting to add.

> 1. Improve the documentation for contributing to Git.
> In preparation for this email, I talked to someone familiar with issues
> around new contributors, and they sat down to try and figure out how to
> contribute to Git. The first place they went was
> and looked at the README. It takes deep reading of a paragraph to see a
> link to the SubmittingPatches docs.
> To improve this experience, we could rewrite the README to have clearer
> section markers, including one "Contributing to Git" section relatively
> high in the doc. We may want to update the README for multiple reasons.
> It should link to the new "My First Contribution" document
> (

I suspect some people may end up at:

when figuring out how to get involved. That discusses the mailing list
itself, but is mostly from the perspective of "how do I ask a question".
I think it could definitely cover some more things:

  - how to get involved by submitting a patch

  - how to get involved in some _other_ way (say, by reviewing or
    participating in discussions)

  - what kind of behavior we expect (and participants can expect) on the

Most of those things would probably be links to other places (e.g., the
first one pointing to MyFirstContribution), but to me it makes sense as
a general landing page for "what is this community and how do I interact
with it".

We take PRs at:

but I'm happy to apply patches if somebody doesn't want to use GitHub.
The file you'd want to touch is app/views/community/index.html.erb
(there are instructions for spinning up a local version of the site in
its README, but if you open a PR it will also get auto-deployed to a
staging site where you can check formatting, etc).

> We have a reference to GitGitGadget in the GitHub PR template to try and
> get people who try to submit a pull request to git/git to instead create
> one on GitGitGadget. However, that captures contributors who didn't read
> the docs about how to submit! (This is somewhat covered by the "My First
> Contribution" doc as well, so making that more visible will also help.)
> Could we reference GitGitGadget as part of the Submitting Patches doc
> as well?

Hmm, I thought we did, but it looks like it's just in CONTRIBUTING. From
my perspective as a reviewer of such patches, I don't mind seeing more
GGG submissions. I.e., I think the tool is mature enough that I don't
mind us letting more people know that it's an option.

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

I agree, and will send a separate message going into more detail.

> 5. Advertise that Git wants new contributors
> After we put items 1-4 in place, we should reach out to the
> general tech community that we are interested in new
> contributors. It's not enough to open the door, we should
> point people to it.
> This item is much less explicit about the _how_. This could
> be done at the individual level: posting to social media or
> blog posts. But perhaps there is something more official we
> could do?

This point is the one I'm least on board with. Not because I'm not
thrilled to have new contributors, but that to some degree I think the
open source system relies heavily on intrinsic motivations like
scratching your own itch. I'm worried that advertising "hey, we need
people to work on stuff!" then brings in people who are well-meaning but
don't necessarily care much about Git in particular. And it becomes an
administrative headache to try to figure out things for them to do, or
get them acclimated to the community.

I.e., I think we want to grow the community a bit more organically,
which should be more sustainable in the long run.

So I think any advertising would be more about making it clear that _if_
you have an idea, we're very interested in welcoming newcomers. And that
to me falls under a lot of the points already made above: making the
process more clear and more inviting to people who are already thinking
about contributing.


  parent reply	other threads:[~2019-09-19 22:16 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
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 [this message]
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:

  List information:

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

  git send-email \ \ \ \ \ \ \ \ \ \
    --subject='Re: [DISCUSSION] Growing the Git community' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror
	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/ \
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
 note: .onion URLs require Tor:

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

AGPL code for this site: git clone