From: "Randall S. Becker" <firstname.lastname@example.org> To: "'brian m. carlson'" <email@example.com>, "'Derrick Stolee'" <firstname.lastname@example.org> Cc: <email@example.com>, <firstname.lastname@example.org>, "'Emily Shaffer'" <email@example.com>, "'Jonathan Nieder'" <firstname.lastname@example.org>, "'Johannes Schindelin'" <Johannes.Schindelin@gmx.de>, <email@example.com>, <firstname.lastname@example.org> Subject: RE: [DISCUSSION] Growing the Git community Date: Fri, 20 Sep 2019 11:16:28 -0400 Message-ID: <email@example.com> (raw) In-Reply-To: <20190920143614.GB20698@genre.crustytoothpaste.net> On September 20, 2019 10:36 AM, brian m. carlson wrote: > To: Derrick Stolee <firstname.lastname@example.org> > Cc: email@example.com; firstname.lastname@example.org; Emily Shaffer > <email@example.com>; Jonathan Nieder <firstname.lastname@example.org>; > Johannes Schindelin <Johannes.Schindelin@gmx.de>; email@example.com; > firstname.lastname@example.org > Subject: Re: [DISCUSSION] Growing the Git community > > On 2019-09-19 at 16:30:13, Derrick Stolee wrote: > > 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). > > I think there's a lot of improvements we could make here, and I know that > many folks are already working on contributor documentation. > That's enormously valuable work, and I'm pleased to see it going on. > > > 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.) > > I think GitGitGadget is a useful tool which I haven't really had the time to > learn how to use. I appreciate that many people prefer a patch-based > workflow, and that using a patch-based workflow and a mailing list provides > the project independence and avoids favoring any hosting platform or tool, > which I agree with. > > I think also that many folks find a pull request-based workflow to be easier > and more familiar and supporting this a bit better may lower the barrier to > entry, so I'm in favor of bridges that make contributing easier, even if one > still needs to subscribe to the list to get feedback. > > > 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 think this is a good idea. We already document how to contribute to the > community by sending a bug report or a patch: how to format your emails, > how to sign off your patches, and how to write a good commit message. I > see a code of conduct as another way to do this by documenting our social > norms much as we document the way our contributions should look > technically. > > I also know in the past we have had problems with a contributor who was > being argumentative and disagreeable. I think documenting the kind of > behavior we want to see both helps individuals ask themselves if their own > behavior is helping us provide a positive community and helps other > contributors provide feedback about unhelpful or unacceptable behavior on > the rare occasion that we see it. > > Lest I give the impression otherwise, I think that overall the Git community is > quite welcoming and positive, and I anticipate that it will continue to remain > that way. I expect that the difference in behavior on the list if we adopt a > code of conduct will be small, since so far pretty much everyone seems to be > engaging in productive, helpful ways. > > However, I know that many folks from underrepresented groups in tech feel > more comfortable when there's a code of conduct because it signals to them > that the project cares about fostering a respectful, healthy community and > that their contributions are likely to be welcomed. I recommend the > Contributor Covenant for this purpose, since it is well known, well accepted, > and is used by numerous other FLOSS projects. Speak as one of those from two very specific underrepresented groups, I have found the committers and reviewers welcoming (and sometimes rightly and deservedly harsh when it was warranted). Although I only have a small number of contributions, I have not found there to be any glaring gaps in the implied policies that have grown organically in the team to this point and hope that we do not become overly formalized as that will, in my experience, push people away. The organic policies of this group are very closely aligned with the Contributor Covenant used by FLOSS - close enough that perhaps only a semanticist will find a difference, so I do find Brian's suggestion to be supportable. Kind Regards, Randall -- Brief whoami: NonStop developer since approximately 211288444200000000 UNIX developer since approximately 421664400 Not admitting my MVS experience at this point -- In my real life, I talk too much.
next prev parent reply other threads:[~2019-09-20 15: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 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 [this message] 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 \ --email@example.com' \ --firstname.lastname@example.org \ --cc=Johannes.Schindelin@gmx.de \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --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
email@example.com 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 \ firstname.lastname@example.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