git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Mike Hommey <mh@glandium.org>
Cc: Derrick Stolee <stolee@gmail.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>,
	"peff@peff.net" <peff@peff.net>,
	Emily Shaffer <emilyshaffer@google.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	"gitster@pobox.com" <gitster@pobox.com>,
	garimasigit@gmail.com
Subject: Re: [DISCUSSION] Growing the Git community
Date: Mon, 23 Sep 2019 23:28:05 +0200 (CEST)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.1909232316300.15067@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <20190919214023.hu3oznjcrzrsmpso@glandium.org>

Hi Mike,


On Fri, 20 Sep 2019, Mike Hommey wrote:

> On Thu, Sep 19, 2019 at 12:30:13PM -0400, Derrick Stolee wrote:
> > During the Virtual Git Contributors' Summit, Dscho brought up the topic of
> > "Inclusion & Diversity". We discussed ideas for how to make the community
> > more welcoming to new contributors of all kinds. Let's discuss some of
> > the ideas we talked about, and some that have been growing since.
> >
> > 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.
> >
> > I have CC'd some of the people who were part of that discussion. Sorry
> > if I accidentally left someone out.
> >
> > I. Goals and Perceived Problems
> >
> > As a community, our number one goal is for Git to continue to be the best
> > distributed version control system. At minimum, it should continue to be
> > the most widely-used DVCS. Towards that goal, we need to make sure Git is
> > the best solution for every kind of developer in every industry. The
> > community cannot do this without including developers of all kinds. This
> > means having a diverse community, for all senses of the word: Diverse in
> > physical location, gender, professional status, age, and others.
> >
> > In addition, the community must continue to grow, but members leave the
> > community on a regular basis for multiple reasons. New contributors must
> > join and mature within the community or the community will dwindle. Without
> > dedicating effort and attention to this, natural forces may result in the
> > community being represented only by contributors working at large tech
> > companies focused on the engineering systems of very large groups.
> >
> > It is worth noting that this community growth must never be at the cost
> > of code quality. We must continue to hold all contributors to a high
> > standard so Git stays a stable product.
> >
> > Here are some problems that may exist within the Git community and may
> > form a barrier to new contributors entering:
> >
> > 1. Discovering how to contribute to Git is non-obvious.
> >
> > 2. Submitting to a mailing list is a new experience for most developers.
> >    This includes the full review and discussion process.
> >
> > 3. The high standards for patch quality are intimidating to new contributors.
> >
> > 4. Some people do not feel comfortable engaging in a community without
> >    a clear Code of Conduct. This discomfort is significant and based on real
> >    experiences throughout society.
> >
> > 5. Since Git development happens in a different place than where users
> >     acquire the end product, some are not aware that they can contribute.
>
> 6. Newcomers don't really have any idea /what/ they could contribute.
> They either have to come with their own itch to scratch, or read the
> code to figure out if there's something to fix.

I think this is very related to the "not only open the door, but invite
contributors in" idea mentioned upthread.

Speaking from my experience as mentor in particular in Outreachy, it is
often not obvious to old-timers in this here project (including myself!)
how intimidating even the idea of "scratching your own itch" is, and
it can be tremendously helpful to even so much as seeing the problem
stated by somebody else first ("Others agree with me! I need not have
doubted myself when I ran into this problem, it really is a bug that
needs to be fixed!").

Additionally, it is no longer all that easy to come up with an "own
itch" to scratch, as the most common workflows work reasonably well in
Git. Yet, it seems that some users _still_ want to "give back" by
contributing patches. Or they just want to see their name in the next
version's announcement mail.

To address both concerns, I started this little experiment a while ago
(but announced it only during a Git IRC standup):
https://github.com/gitgitgadget/git/issues is open, intended to
accumulate possible project ideas. It seems to work reasonably well,
there already have been volunteers who picked up on some of those ideas
I (and Denton) listed.

Hopefully this issue tracker (together with https://crbug.com/git which
targets users more comfortable with that flavor of issue trackers) will
help address your bullet point?

Ciao,
Dscho

  reply	other threads:[~2019-09-23 21:28 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-19 16:30 [DISCUSSION] Growing the Git community 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 [this message]
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=nycvar.QRO.7.76.6.1909232316300.15067@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=emilyshaffer@google.com \
    --cc=garimasigit@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=mh@glandium.org \
    --cc=peff@peff.net \
    --cc=stolee@gmail.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).