git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Klaus Sembritzki <klausem@gmail.com>
To: Derrick Stolee <stolee@gmail.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>,
	"peff@peff.net" <peff@peff.net>,
	Emily Shaffer <emilyshaffer@google.com>,
	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 21:12:09 +0200
Message-ID: <CADMnYXCdEMQ9BEq+DdByDTteZmC3j+c8WuHVx3T9Cb1QNu8zaw@mail.gmail.com> (raw)
In-Reply-To: <CADMnYXCGsTSuxiZuKtz5FZmjthkcwz=k8+m=4_=AU9t0BRERug@mail.gmail.com>

Hello all,

A game-theoretical insight, as the GIT mailing-list has just been
hacked: Such a move necessitates everyone to down-value the hackers'
intellects, if it was not a false-flag-operation.

Cheers,
Klaus Sembritzki


On Thu, Sep 19, 2019 at 8:44 PM Klaus Sembritzki <klausem@gmail.com> wrote:
>
> Hello all,
>
> 1. Long texts stem from false (You can deduce anything from something
> that is wrong).
> 2. TL;DR is therefore sane.
> 3. (Inclusion & Diversity) is a tautology, it includes all of it.
>
> Cheers,
> Klaus Sembritzki
>
>
> On Thu, Sep 19, 2019 at 8:35 PM Derrick Stolee <stolee@gmail.com> 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.
> >
> > II. Approach
> >
> > The action items below match the problems listed above.
> >
> > 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 https://github.com/git/git
> > 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
> > (https://git-scm.com/docs/MyFirstContribution).
> >
> > 2. Add more pointers to GitGitGadget
> >
> > 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?
> >
> > 3. Introduce a new "mentors" mailing list
> >
> > From personal experience, all new contributors at Microsoft (after Jeff
> > Hostetler at least) have first had their patches reviewed privately by
> > the team before sending them upstream. Each time, the new contributor
> > gained confidence about the code and had help interpreting feedback from
> > the list.
> >
> > We want to make this kind of experience part of the open Git community.
> >
> > The idea discussed in the virtual summit was to create a new mailing
> > list (probably a Google group) of Git community members. The point of
> > the list is for a new contributor to safely say "I'm looking for a
> > mentor!" and the list can help pair them with a mentor. This must
> > include (a) who is available now? and (b) what area of the code are they
> > hoping to change?
> >
> > As evidence that this is a good idea, please see the recent research
> > paper ""We Don't Do That Here": How Collaborative Editing With Mentors
> > Improves Engagement in Social Q&A Communities" [1].
> >
> > [1] http://www.chrisparnin.me/pdf/chi18.pdf
> >
> > When asking your first question on Stack Overflow, this group added
> > a pop-up saying "Would you like someone to help you with this?". Then,
> > a mentor would assist crafting the best possible question to ensure
> > the asker got the best response possible.
> >
> > I believe this would work in our community, too. The action items
> > are:
> >
> > a. Create the mailing list and add people to the list.
> >
> > b. Add a pointer to the list in our documentation.
> >
> > Note: the people on the mentoring list do not need to be
> > "senior" community members. In fact, someone who more recently
> > joined the community has a more fresh perspective on the process.
> >
> > 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.
> >
> > 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?
> >
> > III. Measurement
> >
> > How do we know if any of these items make a difference? We
> > need to gather data and measure the effects. With the size
> > of our community, I expect that it will take multiple years
> > to really see a measurable difference. But, no time like
> > the present to ask "What does success look like?"
> >
> > Here are a few measurements that we could use. Each "count"
> > could be measured over any time frame. We could use major
> > releases as time buckets: v2.22.0 to v2.23.0, for example.
> >
> > 1. How many first-time contributors sent a patch?
> >
> > 2. How many contributors had their first commit accepted into
> >    the release?
> >
> > 3. How many contributors started reviewing?
> >
> > 4. How many total patches/reviews did the list receive?
> >
> > What other measurements would be reasonable? We could try
> > building tools to collect these measurements for the past
> > to see historical trends. Based on that data, we may be
> > able to set goals for the future.
> >
> > With such a small community, and an expected small number
> > of new contributors, it may also be good to do interviews
> > with the new contributors to ask about their experience.
> > In particular, we would be looking for moments where they
> > had trouble or experience friction. Each of those
> > moments is a barrier that others may not be clearing.
> >
> >
> > I look forward to the discussion.
> >
> > Thanks,
> > -Stolee

  reply	other threads:[~2019-09-19 19:12 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 [this message]
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=CADMnYXCdEMQ9BEq+DdByDTteZmC3j+c8WuHVx3T9Cb1QNu8zaw@mail.gmail.com \
    --to=klausem@gmail.com \
    --cc=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=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