git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.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>,
	garimasigit@gmail.com
Subject: Re: [DISCUSSION] Growing the Git community
Date: Fri, 20 Sep 2019 10:43:23 -0700
Message-ID: <xmqqsgoqvp6s.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <71fba9e7-6314-6ef9-9959-6ae06843d17a@gmail.com> (Derrick Stolee's message of "Thu, 19 Sep 2019 12:30:13 -0400")

Derrick Stolee <stolee@gmail.com> writes:

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

I have quite a lot of problem with this attitude to place the world
domination as the ultimate goal, even though it may call for the
need for sub-goals, one of which is this one,

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

that I can 100% agree with.  Also I agree that the tactical moves
listed like improved onboading and documentation (omitted from this
response) are all good.

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

I am also somewhat negative on this.

I want to see our system to support the use cases of its users well,
which would lead to its users being happy to use the system.

I think that (and in the remainder, I won't write "I think that" for
brevity) it should be the primary goal.  By being a system that is
useful and pleasant to use, we may gain more users, and we may gain
users from many more different fields and industries and make these
new users happy.  But it should merely be a result, consequence of
being a good system for its users, and not a goal of its own, to
acquire new users from new industries.

And by being a project that works on such a good system for its
users, with welcoming atmosphere to those who are prepared to
reciprocate the same respect while interacting with us, the
community may attract more new members, developers, advocates, tech
writers, etc.  It should merely be a result, consequence of being a
good community for its members, and not a goal on its own, to
acquire new community members.

We first should make sure that we serve existing users and existing
community members well.  So well that other people who are not yet
our "existing" users and members would want to become part of us, in
order to join the fun and share the benefit.  If we cannot serve
even the existing members well, we shouldn't be talking about
acquiring new members.

Growth and the world domination may come as a consequence, and I
would not reject it when it happens, but we should not be actively
seeking it.

It follows that "in this quarter, we acquired these high profile
projects as users", "we have this many new contributors this month",
"the acceptance rate of the patches from contributors with less than
3 months experience dipped by 20% this month" etc. are not best
measures of success.  What's preferable would be yardsticks to gauge
the community-member happiness (e.g. "This many percent of total
community member population have been active this month").

Thanks.

  parent reply	other threads:[~2019-09-20 17: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
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 [this message]
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=xmqqsgoqvp6s.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=emilyshaffer@google.com \
    --cc=garimasigit@gmail.com \
    --cc=git@vger.kernel.org \
    --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