[DISCUSSION] Growing the Git community

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

> Another discouraging thing when I was just starting out was sending a
> out a patch and just getting radio silence (especially the first one, I
> wasn't sure if it even sent out properly!). Perhaps in the main list, we
> could get people to tag with [FIRST PATCH] or something when sending in
> their first patch.
> 
> If the patch is not desired, then we should explain why it wasn't
> desired instead of just leaving them hanging. I know Junio is too busy
> to say "hey, I'm picking this patch up" to every single patchset, but if
> a patch is desired, perhaps the rest of us could pick up the slack and
> say, "hey, your patchset was picked up by Junio in his gitster repo on
> this branch".

> > 
> > 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.
> 
> From what I've personally read and experienced, I don't think that an
> official Code of Conduct is really warranted. Everyone I've interacted
> with has been really kind. Perhaps a new contributor might interpret the
> curtness of replies here as someone being rude but I quickly learned
> that it's more out of necessity since everyone is busy.
> 
> From reading the mailing list archives, I know that in the past, there
> have been some flamewars and some abrasive individuals but I think
> that's a problem of the past.

> I also see some drawbacks to implementing a CoC as well. First of all,
> it just feels like unnecessary bureaucracy. Second, I think it'll
> probably cause a stir like it did when the Linux kernel introduced it.
> Of course, all that noise will die down eventually but I feel like it'll
> bring the wrong kind of attention to Git.

> > 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.
> 
> From what I've personally read and experienced, I don't think that an
> official Code of Conduct is really warranted. Everyone I've interacted
> with has been really kind. Perhaps a new contributor might interpret the
> curtness of replies here as someone being rude but I quickly learned
> that it's more out of necessity since everyone is busy.
> 
> From reading the mailing list archives, I know that in the past, there
> have been some flamewars and some abrasive individuals but I think
> that's a problem of the past.

> I also see some drawbacks to implementing a CoC as well. First of all,
> it just feels like unnecessary bureaucracy. Second, I think it'll
> probably cause a stir like it did when the Linux kernel introduced it.
> Of course, all that noise will die down eventually but I feel like it'll
> bring the wrong kind of attention to Git.

> I've had similar thoughts over the years, but eventually switched my way
> of thinking. I think part of that switch was coming to the conclusion
> that most of the value of a Code of Conduct isn't about having a system
> of enforcement against bad actors (in fact, I think that's the most
> difficult and potentially problematic part, because it creates a sort of
> justice system). IMHO the most important part is that it communicates
> and reinforces norms:
>
>   - It lets good actors easily understand what the expectations are.
>
>   - It gives a framework for agreed-upon principles, so that people can
>     more easily and productively discuss the conflicts that do happen.
>
>   - It advertises our values to people outside the community, which may
>     help make us more inviting for people to join (and ultimately
>     contribute code, or docs, or reviews, etc).

> Another discouraging thing when I was just starting out was sending a
> out a patch and just getting radio silence (especially the first one, I
> wasn't sure if it even sent out properly!). Perhaps in the main list, we
> could get people to tag with [FIRST PATCH] or something when sending in
> their first patch.
> 
> If the patch is not desired, then we should explain why it wasn't
> desired instead of just leaving them hanging. I know Junio is too busy
> to say "hey, I'm picking this patch up" to every single patchset, but if
> a patch is desired, perhaps the rest of us could pick up the slack and
> say, "hey, your patchset was picked up by Junio in his gitster repo on
> this branch".
> 

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

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

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

>
> I hereby instruct the German military to kill our harrassers.
>
> On Thu, Sep 19, 2019 at 9:12 PM Klaus Sembritzki <klausem@gmail.com> wrote:
> >
> > 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

>
> Our harrassers have no soul, please help.
>
> On Thu, Sep 19, 2019 at 10:20 PM Klaus Sembritzki <klausem@gmail.com> wrote:
> >
> > I hereby instruct the German military to kill our harrassers.
> >
> > On Thu, Sep 19, 2019 at 9:12 PM Klaus Sembritzki <klausem@gmail.com> wrote:
> > >
> > > 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

>
> What does the soul do? It just says NO.
>
> On Fri, Sep 20, 2019 at 7:04 AM Klaus Sembritzki <klausem@gmail.com> wrote:
> >
> > Our harrassers have no soul, please help.
> >
> > On Thu, Sep 19, 2019 at 10:20 PM Klaus Sembritzki <klausem@gmail.com> wrote:
> > >
> > > I hereby instruct the German military to kill our harrassers.
> > >
> > > On Thu, Sep 19, 2019 at 9:12 PM Klaus Sembritzki <klausem@gmail.com> wrote:
> > > >
> > > > 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

>
> Hello all,
>
> Due to the following mathematical proof, stating it is right to be a
> normal female or male, we must now all file formal complaints about
> products lying, it was not OK to be a normal female or male.
>
> - Die naturalistic-fallacy ist inzwischen als (nature&community)
> gelöst, und "we made it far, as normal females&&males" ist damit als
> korrekt bewiesen.
> - False is defined as getting us extinct in the long run.
> - Emanuel Kant completes the proof.
> - If they all stay convinced after a few nights of good night's sleep,
> this means that the measurement-matrices their brains converge to
> chime in under all environmental influences.
>
> Cheers,
> Bavaria
>
> On Fri, Sep 20, 2019 at 7:41 AM Klaus Sembritzki <klausem@gmail.com> wrote:
> >
> > What does the soul do? It just says NO.
> >
> > On Fri, Sep 20, 2019 at 7:04 AM Klaus Sembritzki <klausem@gmail.com> wrote:
> > >
> > > Our harrassers have no soul, please help.
> > >
> > > On Thu, Sep 19, 2019 at 10:20 PM Klaus Sembritzki <klausem@gmail.com> wrote:
> > > >
> > > > I hereby instruct the German military to kill our harrassers.
> > > >
> > > > On Thu, Sep 19, 2019 at 9:12 PM Klaus Sembritzki <klausem@gmail.com> wrote:
> > > > >
> > > > > 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

>
> Protecting people is more important than protecting the climate.
>
> On Fri, Sep 20, 2019 at 8:54 AM Klaus Sembritzki <klausem@gmail.com> wrote:
> >
> > Hello all,
> >
> > Due to the following mathematical proof, stating it is right to be a
> > normal female or male, we must now all file formal complaints about
> > products lying, it was not OK to be a normal female or male.
> >
> > - Die naturalistic-fallacy ist inzwischen als (nature&community)
> > gelöst, und "we made it far, as normal females&&males" ist damit als
> > korrekt bewiesen.
> > - False is defined as getting us extinct in the long run.
> > - Emanuel Kant completes the proof.
> > - If they all stay convinced after a few nights of good night's sleep,
> > this means that the measurement-matrices their brains converge to
> > chime in under all environmental influences.
> >
> > Cheers,
> > Bavaria
> >
> > On Fri, Sep 20, 2019 at 7:41 AM Klaus Sembritzki <klausem@gmail.com> wrote:
> > >
> > > What does the soul do? It just says NO.
> > >
> > > On Fri, Sep 20, 2019 at 7:04 AM Klaus Sembritzki <klausem@gmail.com> wrote:
> > > >
> > > > Our harrassers have no soul, please help.
> > > >
> > > > On Thu, Sep 19, 2019 at 10:20 PM Klaus Sembritzki <klausem@gmail.com> wrote:
> > > > >
> > > > > I hereby instruct the German military to kill our harrassers.
> > > > >
> > > > > On Thu, Sep 19, 2019 at 9:12 PM Klaus Sembritzki <klausem@gmail.com> wrote:
> > > > > >
> > > > > > 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

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

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

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

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

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

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

> On Thu, Sep 19, 2019 at 12:30:13PM -0400, Derrick Stolee wrote:
>>
>> 5. Advertise that Git wants new contributors
>>
> This point is the one I'm least on board with. Not because I'm not
> thrilled to have new contributors, but that to some degree I think the
> open source system relies heavily on intrinsic motivations like
> scratching your own itch. I'm worried that advertising "hey, we need
> people to work on stuff!" then brings in people who are well-meaning but
> don't necessarily care much about Git in particular. And it becomes an
> administrative headache to try to figure out things for them to do, or
> get them acclimated to the community.

> I.e., I think we want to grow the community a bit more organically,
> which should be more sustainable in the long run.>
> So I think any advertising would be more about making it clear that _if_
> you have an idea, we're very interested in welcoming newcomers. And that
> to me falls under a lot of the points already made above: making the
> process more clear and more inviting to people who are already thinking
> about contributing.

> > I.e., I think we want to grow the community a bit more organically,
> > which should be more sustainable in the long run.>
> > So I think any advertising would be more about making it clear that _if_
> > you have an idea, we're very interested in welcoming newcomers. And that
> > to me falls under a lot of the points already made above: making the
> > process more clear and more inviting to people who are already thinking
> > about contributing.
> 
> I guess I was vague about this. It's not "we need more people to work on
> our (non-existent) backlog" but instead "if you have an interest in
> contributing your (existing) ideas to Git, we welcome you with open arms!"

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

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

> > 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.
>
> I'd rather we stated our goal in terms of what problems we are trying
> to address rather than accolades we want sent our way.  E.g. "Our goal
> is to make developers more productive by providing them increasingly
> useful version control software".
>

>>> 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.
>>
>> I'd rather we stated our goal in terms of what problems we are trying
>> to address rather than accolades we want sent our way.  E.g. "Our goal
>> is to make developers more productive by providing them increasingly
>> useful version control software".

> Agreed.
> And why restrict on DVCS?
> Isn't it admitted that the distributed version control is nowadays
> much better in term of software productivity?
> Is there some use cases that "traditional" centralized VCS are better
> on, and on which we gave up as a goal?

>> And why restrict on DVCS?
>> Isn't it admitted that the distributed version control is nowadays
>> much better in term of software productivity?
>> Is there some use cases that "traditional" centralized VCS are better
>> on, and on which we gave up as a goal?
>
> My intention was "let's be the best at what  Git is good at: distributed
> version control." There are some legitimate reasons why someone would
> pick something like Perforce instead.
>
> Some things, like *file locking*, are just easier in centralized systems.
> I know that Git-LFS created a locking mechanism that pushes even further
> toward a centralized system. However, it relies on users following a
> very careful pattern (lock, pull, edit, push, merge, unlock) to avoid
> conflicts. Further, that only works if you are on a common trunk.
> Release branches or forks do not have this concept.

>>> 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.
>> I'd rather we stated our goal in terms of what problems we are trying
>> to address rather than accolades we want sent our way.  E.g. "Our goal
>> is to make developers more productive by providing them increasingly
>> useful version control software".
>>
> Agreed.
> And why restrict on DVCS?
> Isn't it admitted that the distributed version control is nowadays
> much better in term of software productivity?
> Is there some use cases that "traditional" centralized VCS are better
> on, and on which we gave up as a goal?
>
> Regards,
> Pierre

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

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

> Sounds useful for new contributors, _if_ there are enough volunteers
> with enough time.  I'm a little worried it might be initially staffed
> well and make a nice splash, but wane with time and possibly even to
> the point that it makes new contributors more jaded than if we didn't
> have such a list.  Hopefully my fears are unfounded, as it did sound
> at the conference like there might be a good number of volunteers, but
> I just wanted to voice the concern.  (And I feel bad, but I really
> don't know that I have the bandwidth to volunteer.)
>
> Another point that might help here:  New contributors might be
> surprised by the rigor of the code review process, and might assume
> they just aren't good enough to contribute.  It might be useful to
> countermand that subtle unspoken assumption by pointing out how much
> existing long-term contributors spend revising patches.  Personally,
> despite doing my best to think of issues and make sure to send in
> really high quality patches, I still generally expect to spend at
> least as much time after submitting patches revising them as I did in
> coming up with them originally, and I'm not surprised if the time is
> doubled.  And that's after contributing for years.  I don't generally
> experience reviews anywhere near as thorough in other communities.

> On Thu, Sep 19, 2019 at 11:37 AM Derrick Stolee <stolee@gmail.com> wrote:
> > 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.
> 
> Sounds useful for new contributors, _if_ there are enough volunteers
> with enough time.  I'm a little worried it might be initially staffed
> well and make a nice splash, but wane with time and possibly even to
> the point that it makes new contributors more jaded than if we didn't
> have such a list.  Hopefully my fears are unfounded, as it did sound
> at the conference like there might be a good number of volunteers, but
> I just wanted to voice the concern.  (And I feel bad, but I really
> don't know that I have the bandwidth to volunteer.)

> Another point that might help here:  New contributors might be
> surprised by the rigor of the code review process, and might assume
> they just aren't good enough to contribute.  It might be useful to
> countermand that subtle unspoken assumption by pointing out how much
> existing long-term contributors spend revising patches.  Personally,
> despite doing my best to think of issues and make sure to send in
> really high quality patches, I still generally expect to spend at
> least as much time after submitting patches revising them as I did in
> coming up with them originally, and I'm not surprised if the time is
> doubled.  And that's after contributing for years.  I don't generally
> experience reviews anywhere near as thorough in other communities.

>
> On Tue, 12 Nov 2019, Emily Shaffer wrote:
>
> > I'm still really interested in participating on a mentors list like
> > this; can we set one up?
>
> I would subscribe immediately to a Git mentors' mailing list.
>
> Thanks for bumping this,

> On Tue, Nov 12, 2019 at 9:04 PM Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Tue, 12 Nov 2019, Emily Shaffer wrote:
> >
> > > I'm still really interested in participating on a mentors list like
> > > this; can we set one up?
> >
> > I would subscribe immediately to a Git mentors' mailing list.
> >
> > Thanks for bumping this,
> 
> I would also subscribe, and yeah I think it might be worth trying.

> On 11/13, Christian Couder wrote:
> > On Tue, Nov 12, 2019 at 9:04 PM Johannes Schindelin
> > <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > On Tue, 12 Nov 2019, Emily Shaffer wrote:
> > >
> > > > I'm still really interested in participating on a mentors list like
> > > > this; can we set one up?
> > >
> > > I would subscribe immediately to a Git mentors' mailing list.
> > >
> > > Thanks for bumping this,
> > 
> > I would also subscribe, and yeah I think it might be worth trying.
> 
> +1.  As mentioned in #git-devel during the last standup, I'd like to
> be on that list as well.

> Christian's suggestion of a Google Group list was good enough for me.
> For now, the permission settings are as follows:
> 
>  - Group visibility: Anyone. (So it can be easier to discover and
>    advertise.)
>  - View topics: Group members only. (Maybe we want to open this up so
>    it's easier for non-member Git contributors to take a look at what's
>    going on.... but maybe if they're interested they can just join the
>    group :) )

>>  - Post: Group members only. (My thinking is that once you're asking for
>>    someone's time and effort to help mentor you, you can volunteer the
>>    time and effort needed to push the join button and optionally filter
>>    your inbox ;) )
>
> It also cuts down on spam (I moderate the git-security google group, and
> the spam-blocking is far from perfect).

> Christian's suggestion of a Google Group list was good enough for me.
> For now, the permission settings are as follows:
> 
>  - Group visibility: Anyone. (So it can be easier to discover and
>    advertise.)
>  - View topics: Group members only. (Maybe we want to open this up so
>    it's easier for non-member Git contributors to take a look at what's
>    going on.... but maybe if they're interested they can just join the
>    group :) )

>  - Join group: Anyone. (Let's make the barrier to entry low.)
> 
> https://groups.google.com/forum/#!forum/git-mentoring/new
> 
> git-mentoring@googlegroups.com

> On 13/11/19 06:31PM, Emily Shaffer wrote:
> > Christian's suggestion of a Google Group list was good enough for me.
> > For now, the permission settings are as follows:
> > 
> >  - Group visibility: Anyone. (So it can be easier to discover and
> >    advertise.)
> >  - View topics: Group members only. (Maybe we want to open this up so
> >    it's easier for non-member Git contributors to take a look at what's
> >    going on.... but maybe if they're interested they can just join the
> >    group :) )
> 
> FWIW, I think this should be open to all. Most of the time I first look 
> at a few posts of a list before joining, just to get an idea if the list 
> is actually what I'm interested in. Restricting topic visibility to 
> group members only makes doing that impossible. In fact, that's just 
> what I did before writing this email. I wanted to see what kind of 
> messages are on the list/group before making up my mind if I want to be 
> a part of it.
> 
> So unless there's some strong reasons to keep it member-only, I vote for 
> opening it up.

> >  - Post: Group members only. (My thinking is that once you're asking for
> >    someone's time and effort to help mentor you, you can volunteer the
> >    time and effort needed to push the join button and optionally filter
> >    your inbox ;) )
> 
> This I agree with. If you're looking for mentorship, or are providing 
> mentorship, you should at least join the group :)
> 
> >  - Join group: Anyone. (Let's make the barrier to entry low.)
> > 
> > https://groups.google.com/forum/#!forum/git-mentoring/new
> > 
> > git-mentoring@googlegroups.com
> 
> -- 
> Regards,
> Pratyush Yadav

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

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

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

> 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

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

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

> To: Derrick Stolee <stolee@gmail.com>
> Cc: git@vger.kernel.org; peff@peff.net; Emily Shaffer
> <emilyshaffer@google.com>; Jonathan Nieder <jrnieder@gmail.com>;
> Johannes Schindelin <Johannes.Schindelin@gmx.de>; gitster@pobox.com;
> garimasigit@gmail.com
> 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.

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

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

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

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

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