From: Derrick Stolee <stolee@gmail.com> To: "git@vger.kernel.org" <git@vger.kernel.org> Cc: "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: [DISCUSSION] Growing the Git community Date: Thu, 19 Sep 2019 12:30:13 -0400 Message-ID: <71fba9e7-6314-6ef9-9959-6ae06843d17a@gmail.com> (raw) 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
next reply other threads:[~2019-09-19 16:30 UTC|newest] Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-09-19 16:30 Derrick Stolee [this message] 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 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=71fba9e7-6314-6ef9-9959-6ae06843d17a@gmail.com \ --to=stolee@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 \ /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 the 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