[DISCUSSION] Growing the Git community

[DISCUSSION] Growing the Git community

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

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

Re: [DISCUSSION] Growing the Git community

[Denton Liu]

Hello,

As a relatively new contributor (just less than a year), I guess I'll
share some thoughts:

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.

From my anecdotal experience in trying to get my developer friends to
contribute, they've told me that it isn't really that much fun for them
to contribute to free software. After doing one day job, they said they
didn't really want to come home to do another one.

I guess one thing we should consider is "how do we make it more fun to
contribute to Git?" Not sure if that's a naïve goal but I feel like it
would help to keep people coming back.

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

Aside from getting the first email sent, most of my time learning to
contribute to Git stemmed from the fact that there's a lot of tribal
knowledge that's not really written down anywhere. Here are some of the
smaller things that confused me:

I remember some other docs I read included howto/maintain-git.txt about
a month in. I remember feeling confused about what Junio was doing with
all of the integration branches so reading this really cleared things up
for me.

On that topic, I didn't realise the gitster/git repo existed for a while
so, from my pespective, my patches went into a black hole and then
somehow magically got incorporated into Git.

Actually, one thing that I'm still confused about is what people do with
their topic branches. I learned a long time ago not to rebase onto
master (hence why I introduced rebase --keep-base) but aside from that,
are we supposed to pull down the topic branches and edit from there or
keep working on top of a local branch? I think it might be help if
someone experienced in the community wrote a howto/contribute-to-git.txt
and just spent a while talking about their workflow in detail.

> 
> 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 agree, this would've been really helped me get started if it were
around a year ago.

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

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.

(Then again, maybe it'll attract more contributors in the process, who
knows.)

> 
> 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've dropped some of my experiences here but I'd be open to do an
interview if needed.

> 
> 
> I look forward to the discussion.

Thanks for starting the discussion,

Denton
> 
> Thanks,
> -Stolee

Re: [DISCUSSION] Growing the Git community

[Klaus Sembritzki]

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

Re: [DISCUSSION] Growing the Git community

[Klaus Sembritzki]

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

Re: [DISCUSSION] Growing the Git community

[Klaus Sembritzki]

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

Re: [DISCUSSION] Growing the Git community

[Emily Shaffer]

On Thu, Sep 19, 2019 at 10:34:23AM -0700, Denton Liu wrote:
> Aside from getting the first email sent, most of my time learning to
> contribute to Git stemmed from the fact that there's a lot of tribal
> knowledge that's not really written down anywhere. Here are some of the
> smaller things that confused me:

+1 to unwritten knowledge. I learned quite a lot from comments on my
early reviews about utilities and patterns which I had no idea existed.
I'd love to see more and better-organized documentation in Git project
(in fact, that's one of my goals for this year - a contributor's manual,
which was one of the topics discussed at the virtual summit).

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

I wonder how feasible it really is to expect people to review more/more
quickly than they are today. It might be more realistic to try to temper
folks' expectations in the new contributor documentation.

This might also be a problem which starts to disappear as the number of
contributors rises...

> > 
> > 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 disagree pretty strongly - I think that the fact that we did have
problems in the past indicates that we're at risk for similar problems
in the future.

In my opinion, a code of conduct shouldn't be introduced to deal with
behavior when it arises - that invites parties to feel that they're
being targeted for behavior that "used to be okay". We introduce a CoC
to protect ourselves in the future, and to maintain the pleasant
community we have today.

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

As a member of >1 groups which are prone to receiving harassment online,
I don't find it unnecessary at all for there to be a path for me to
escalate and resolve harassment I am the victim of.

As for the stir in the Linux kernel, I find it interesting that most of
the attempts to revert the CoC came via Github PRs - which the kernel
does not use. Another way of saying that is that most of those attempts
came from people who did not regularly contribute to the kernel, and did
not care enough about contributing to it in the future to discover the
correct contribution process.

I realize I'm taking a hard line here, but I'm not sure how "Git wants
to protect its contributors from harassment" is the "wrong" kind of
attention. If I weren't contributing to Git actively and I saw that
news, I would feel inspired and optimistic (again, speaking as a member
of groups which are often harassed online and in tech).

> (Then again, maybe it'll attract more contributors in the process, who
> knows.)


I totally understand where you're coming from, Denton, that it's not a
problem now and so it may not be worth the effort+press. But I wonder
how many folks we're missing out on patches from because they don't
think they will have recourse if they find the community to be
toxic/unwelcoming to them? We really don't have a way to know. I'm
worried that we're restricting the community to those who either
feel it's unlikely that they'll be targeted, or feel they can weather
harassment if they receive it - which narrows the diversity of our
contributor base by quite a lot.

 - Emily

Re: [DISCUSSION] Growing the Git community

[Mike Hommey]

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.

Mike

Re: [DISCUSSION] Growing the Git community

[Jeff King]

On Thu, Sep 19, 2019 at 12:30:13PM -0400, Derrick Stolee wrote:

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

First off, thanks for starting this conversation on the list.  I agree
with 99% of what you said, so I'll quote sparingly below, and just cover
the parts where I have something interesting to add.

> 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 suspect some people may end up at:

  https://git-scm.com/community

when figuring out how to get involved. That discusses the mailing list
itself, but is mostly from the perspective of "how do I ask a question".
I think it could definitely cover some more things:

  - how to get involved by submitting a patch

  - how to get involved in some _other_ way (say, by reviewing or
    participating in discussions)

  - what kind of behavior we expect (and participants can expect) on the
    list

Most of those things would probably be links to other places (e.g., the
first one pointing to MyFirstContribution), but to me it makes sense as
a general landing page for "what is this community and how do I interact
with it".

We take PRs at:

  https://github.com/git/git-scm.com

but I'm happy to apply patches if somebody doesn't want to use GitHub.
The file you'd want to touch is app/views/community/index.html.erb
(there are instructions for spinning up a local version of the site in
its README, but if you open a PR it will also get auto-deployed to a
staging site where you can check formatting, etc).

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

Hmm, I thought we did, but it looks like it's just in CONTRIBUTING. From
my perspective as a reviewer of such patches, I don't mind seeing more
GGG submissions. I.e., I think the tool is mature enough that I don't
mind us letting more people know that it's an option.

> 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 agree, and will send a separate message going into more detail.

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

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.

-Peff

Re: [DISCUSSION] Growing the Git community

[Elijah Newren]

On Thu, Sep 19, 2019 at 11:37 AM 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.

Thanks for working on this.  I like the overall thrust, and many of
the concrete proposals.  I've got lots of comments and feedback, and
if I focus too much on things that could be improved, just remember I
like the overall thrust.

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

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

> 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

This sounds much too strongly worded to me.  I don't like the idea of
everything for everyone; it suggests that if someone comes up with a
one-off usecase that affect 3 people in the world, we have to devote
resources to it (even at the risk of making ongoing maintenance
harder).  I would prefer a statement like we want to solve more
usecases than we do today, and we want to bring in developers from a
diverse background to help us do so.

> means having a diverse community, for all senses of the word: Diverse in
> physical location, gender, professional status, age, and others.

The combination of wording above ("need to...cannot do this...all
kinds...all senses of the word") suggests that more extreme measures
are in scope.  For example, what about programming language?  C is
going to restrict us to a small and possibly shrinking set of
developers.  I think that changing language is far-fetched and not
worth it, but the wording above would suggest it.

A different way to avoid such interpretations might be if you can find
a way to imbue the document with a "evolutionary not revolutionary"
feeling or wording.

> In addition, the community must continue to grow, but members leave the

"must"?  I agree that we want to grow, but "must" suggests a
priortization level of effort that makes me uneasy.  If you said that
we find it really important and will invest resources in it, then I'm
all for it.

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

Sounds good.

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

+1; that'll also give some automated build feedback for the new
contributors, and provide some useful links in the cover letter (I
like how GitGitGadget provides links for fetching the changes without
using git-am).  I should probably use it more myself.

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

> 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 agree with the part of Denton's view that there isn't much of a
problem currently in Git; which I am happy about.  I think such a time
is a wonderful time to introduce a Code of Conduct.

From experience watching another community years ago, I think trying
to introduce one when there are existing problems is much harder and
leads to compromises like saying it's merely an aspirational statement
and explicitly state that there is absolutely no enforcement
whatsoever (unless a maintainer of a sub-project has stated they'll
enforce it for their sub-community).  A code of conduct in more
extreme cases like that is still useful, much as adding "all men are
created equal" to the United States' declaration of independence was
useful -- it guided people over hundreds of years closer to that
ideal.

I think adding a Code of Conduct provides four distinct benefits for us:
  * it prevents future problems
  * it gets everyone to subtly improve behavior on their own
  * it improves the selection filter of who joins the project over time
  * it makes it easier for folks to have a discussion about problems,
should they arise.

On the second point, a rather memorable exchange I remember from that
other community (which I think helped people towards accepting the
code of conduct) was:

"I can understand Ethics code, but I wouldn't sign this, knowing full
well that I'll have bad days, and I call people things worse than
nitwit even on a good day."

"As do I. And people should know that's not how we are in general."

As humans, we sometimes make mistakes.  And short of mistakes, we
sometimes miss social cues.  Further, the inherent lack of tone of
voice and other body language due to using email as a communication
mechanism sometimes leads to misunderstandings.  Behavior is sometimes
black and white, and while we definitely want to keep some behaviors
out of the community, there are a large number of gray areas (e.g.
when reviewing code -- do we remember to praise the good, or only
point out the bad?  I tend not to do as well on that front.)  I think
a code of conduct helps us (subconsciously) move towards lighter
shades of gray.

> 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 think these look like useful things to do, including measuring.  It
may turn out into a great success.  But...I'm a little worried that
the measuring might result in folks getting discouraged and giving up
in a few years.  Even if the numbers aren't as rosy as we hope, I
think there are other advantages that you might not be naturally
measuring here.  For example, the adoption of a code of conduct in
another project slowly made that community more enjoyable to work in
over a period of years, in my opinion (coming from someone who isn't a
minority and was already a core contributor).  I have no way to
measure that, but it was my opinion.  Also, within our community, the
efforts to make contributions for others easier might yield more tools
like Dscho's GitGitGadget that makes the life of existing contributors
better.  Anyway, just some food for thought.


Elijah

Re: [DISCUSSION] Growing the Git community

[Jeff King]

On Thu, Sep 19, 2019 at 10:34:23AM -0700, Denton Liu wrote:

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

> 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 also been worried about that. And it's easy to think "nobody is
behaving too badly right now, so it's all a net negative since we risk a
trollish flamewar". But I think it's easy to discount "invisible"
negatives of the status quo, like people who are hesitant to join the
community because of the lack of a CoC. We in the community don't see
that. And even for people who remember what it was like to join, many
people have different expectations and experiences. If we can easily
make ourselves more inviting to a wider range of people, that seems like
a win.

-Peff

Re: [DISCUSSION] Growing the Git community

[Derrick Stolee]

On 9/19/2019 6:16 PM, Jeff King wrote:
> 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.

Your concerns are valid.
 
> 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!"

Thanks,
-Stolee

Re: [DISCUSSION] Growing the Git community

[Jeff King]

On Thu, Sep 19, 2019 at 10:17:57PM -0400, Derrick Stolee wrote:

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

Yeah, _that_ I'm totally on board with. Thanks again for kicking off
this discussion.

-Peff

Re: [DISCUSSION] Growing the Git community

[Klaus Sembritzki]

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

Re: [DISCUSSION] Growing the Git community

[Klaus Sembritzki]

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

Re: [DISCUSSION] Growing the Git community

[Klaus Sembritzki]

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

Re: [DISCUSSION] Growing the Git community

[Klaus Sembritzki]

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

Re: [DISCUSSION] Growing the Git community

[Klaus Sembritzki]

I have a paper-sheet hanging in my private living-room now, stating:
- "This is my private living-room, and you are guilty invading my
privacy using EMF-telepathy."
- You must all have the same.

On Fri, Sep 20, 2019 at 9:43 AM Klaus Sembritzki <klausem@gmail.com> wrote:
>
> 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

Re: [DISCUSSION] Growing the Git community

[Philip Oakley]

Hi All,

Some rhetorical top level systemy thinking...

On 19/09/2019 17:30, 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.
I'm always cautious about "best" (as in "best-practice" etc). Git is 
only good in it's particular environment (version control in physical 
engineering has different problems with different solutions, which did 
pollute the older computer VCS systems). It certainly should be 'good'.
>   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 is wider than developers, and can include lawyers, 
historians, screenwriters, all with their own particular needs (e.g. the 
new timestamp range capability)
> 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.
We should also ask why engineering companies don't have the same cycle, 
so as to compare and contrast the issues.
>
> 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.

I want to "disagree" here about the accidental tone of perfection at all 
times and in all places.

There is a core integrity to the Git data model that validates and 
verifies the stored content of the versions, which should be inviolate, 
but beyond that, as the distance from the core increases, the "quality" 
can soften for both new and existing parts of the code (corner cases, 
quadratic and worse behaviours, design for small textural repos).

We are poor at clarifying which parts (of the code) require that top 
level of integrity, leading down to those parts that are simply 
convenience capabilities for the broad-based user. And then there is 
documentation, and the difficulty of understanding of Git for the 
general user. The shift to narrowing the core-git may further reduce the 
community.
>
> 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.
Given that Git does support fixups and further patches in a distributed 
environment, we can be our own worst enemy here. Maybe we need to look 
carefully in the mirror.
>
> 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.
A tricky one. It will depend on how they are used and whether they 
promote community and tolerance.
>
> 5. Since Git development happens in a different place than where users
>      acquire the end product, some are not aware that they can contribute.

Should we also address the Windows community and ecosystem? A good 
neighbour to the Friendly fork? Misunderstandings about the difference 
between the users and the provider?... etc.

These systemy comments are about ensuring we are solving the right 
problems and ensuring we don't miss some issue that will negate any good 
work here.
--
Philip
> 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

Re: [DISCUSSION] Growing the Git community

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 3983 bytes --]

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.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]

RE: [DISCUSSION] Growing the Git community

[Randall S. Becker]

On September 20, 2019 10:36 AM, brian m. carlson wrote:
> 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.

Speak as one of those from two very specific underrepresented groups, I have found the committers and reviewers welcoming (and sometimes rightly and deservedly harsh when it was warranted). Although I only have a small number of contributions, I have not found there to be any glaring gaps in the implied policies that have grown organically in the team to this point and hope that we do not become overly formalized as that will, in my experience, push people away. The organic policies of this group are very closely aligned with the Contributor Covenant used by FLOSS - close enough that perhaps only a semanticist will find a difference, so I do find Brian's suggestion to be supportable.

Kind Regards,
Randall

-- Brief whoami:
NonStop developer since approximately 211288444200000000
UNIX developer since approximately 421664400
Not admitting my MVS experience at this point
-- In my real life, I talk too much.

Re: [DISCUSSION] Growing the Git community

[Garima Singh]

Thanks for starting this thread. I am glad it is receiving such great 
energy on here. Apart from the some of the statements that sound too 
ideal, I agree in gist with the overall effort this will hopefully set 
rolling.

On 9/19/2019 12:30 PM, Derrick Stolee wrote> 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?
> 

One more action item that I should be considered and people agreed to 
during the summit was to "Improve the welcome to the mailing list email"
I believe it needs to be warmer and more welcoming. It needs to break 
through the ice and intimidation that many new contributors feel. A lot 
of the ideas being suggested here can be linked into that email. I have 
a few ideas about what it should like and will hopefully send out a 
draft soon. Feel free to send me any suggestions you might have.

Thanks,
Garima Singh

Re: [DISCUSSION] Growing the Git community

[Garima Singh]

On 9/19/2019 1:34 PM, Denton Liu wrote:
> 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".
> 

I absolutely *love* this idea!

Cheers!
Garima Singh

Re: [DISCUSSION] Growing the Git community

[Junio C Hamano]

Derrick Stolee <stolee@gmail.com> writes:

> I. Goals and Perceived Problems
>
> As a community, our number one goal is for Git to continue to be the best
> distributed version control system. At minimum, it should continue to be
> the most widely-used DVCS. Towards that goal, we need to make sure Git is
> the best solution for every kind of developer in every industry.

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

> The
> community cannot do this without including developers of all kinds. This
> means having a diverse community, for all senses of the word: Diverse in
> physical location, gender, professional status, age, and others.

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

> After we put items 1-4 in place, we should reach out to the
> general tech community that we are interested in new
> contributors. It's not enough to open the door, we should
> point people to it.

I am also somewhat negative on this.

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

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

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

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

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

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

Thanks.

Re: [DISCUSSION] Growing the Git community

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

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

And it saves us time when we need to deal with problematic folks.
It would have saved a lot of mental energey from me, you, muggerhagger and
jrnieder (perhaps I am forgetting others) during the last incident,
if we already had one back then.

Re: [DISCUSSION] Growing the Git community

[Junio C Hamano]

Garima Singh <garimasigit@gmail.com> writes:

>> could get people to tag with [FIRST PATCH] or something when sending in
>> their first patch.

I personally think that the [FIRST PATCH] thing will add distraction
without helping much, so I am mildly negative on that idea.

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

It's not busy-ness but more of forgetfullness, or being human.  I'll
try harder ;-)

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

OK.

Re: [DISCUSSION] Growing the Git community

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

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

I realize that it was my mistake that I did not explicitly say this,
but I do appreciate many of the things the document proposed.  They
are measures to make the community a better place for its members.
I want to see it labeled as such.

After all, this project is not an evil corporation with aspiration
for world domination, even though some of us may work for such
companies ;-)

Thanks for starting the discussion.

Re: [DISCUSSION] Growing the Git community

[Derrick Stolee]

On 9/19/2019 12:30 PM, 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.

Thanks, everyone, for the valuable discussion! I particularly appreciate
that everyone who disagreed with my misguided opinions pointed out the
flaws respectfully and moved forward in a positive direction.

That's a great thing to see in an open community.

Thanks,
-Stolee

Re: [DISCUSSION] Growing the Git community

[Johannes Schindelin]

Hi Mike,


On Fri, 20 Sep 2019, Mike Hommey wrote:

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

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?

Ciao,
Dscho

Re: [DISCUSSION] Growing the Git community

[Johannes Schindelin]

Hi Stolee,

On Thu, 19 Sep 2019, 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.
>
> [...]

Thank you for writing this detailed mail about it!

Ciao,
Dscho

Re: [DISCUSSION] Growing the Git community

[Pierre Tardy]

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

Re: [DISCUSSION] Growing the Git community

[Derrick Stolee]

On 9/25/2019 9:36 AM, Pierre Tardy wrote:
>>> 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".

I'll repeat my appreciation for this redirection of focus.
 
> 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?

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.

Other extensions (like VFS for Git) remove a lot of the truly
distributed parts and focus instead on a central source of truth.
This works well for some organizations.

Getting on my personal soapbox: I think that we are improving Git
so much that people will have few strong reasons to choose other
DVCSs. Maybe "hg evolve" is why someone really loves Mercurial, and
we can work to build similar features. Maybe there is some repo
shapes where another tool is faster, but we could probably make Git
faster, too.

Thanks,
-Stolee

Re: [DISCUSSION] Growing the Git community

[Philip Oakley]

Hi Pierre,

On 25/09/2019 14:36, Pierre Tardy wrote:
>>> 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
As an old engineer, I do remember and still see the vast range of areas 
where the Git DVCS is probably never going to help because it doesn't 
solve the engineering issues that regular VCS (e.g. Mil-Std-498) have 
solved for generations...

What modern computing, Linux style, has is:
- Perfect replication, at near zero cost or time.
- Line oriented, Source code based basis.
- Computational efficiency, at near zero cost or time.
- Crypto-algorithms at strength.

If we go outside those areas we are less and less likely to manage. 
(digital video? Every binary to be serialised? bit rot resilience? 
traceability?).

We do have some Elephants in the room regarding What the community is 
about (limits and goals), as distinct from How we conduct ourselves 
(CoC), but that probably should be separated out.

Re: [DISCUSSION] Growing the Git community

[Jakub Narebski]

Hello,

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 20 Sep 2019, Mike Hommey wrote:

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

It would be nice to have those issue trackers announced more widely (on
the homepage, on the Git Rev News homepage, maybe also in docs e.g.
CONTRIBUTING).

For me, beside being the place where to find out some ideas on how to
contribute, would be having a place to put my ideas that I have not had
time to even start to do, like adding `git gui diff` (e.g. borrowing
from tkdiff) and `git instaweb --serve`.

Best,
-- 
Jakub Narębski

Re: [DISCUSSION] Growing the Git community

[Jakub Narebski]

Elijah Newren <newren@gmail.com> writes:

> On Thu, Sep 19, 2019 at 11:37 AM Derrick Stolee <stolee@gmail.com> wrote:
[...]
>> 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.

Doing code reviews is another area that new people might not know that
it is something they can do, and that it is something that helps the
project.  You don't need to be subsystem "owner" to perform code review,
you just need to know the topic; though knowing CodingConventions before
commenting about style is a must.  IMHO this can help a lot, especially
for patch series where Junio waits for any review.

You don't even need to be subscribed to git@vger.kernel.org mailing
list; thanks to public-inbox.org (and GMane before that) you can use
Usenet news reader like for example Gnus (in GNU Emacs) to read and
respond via nntp://news.public-inbox.org/inbox.comp.version-control.git

I don't think that this way of contributing (by doing code review) is
specified anywhere in Git documentation or anywhere on Git-related web
pages.

Best,
-- 
Jakub Narębski

Re: [DISCUSSION] Growing the Git community

[Jakub Narebski]

Derrick Stolee <stolee@gmail.com> writes:
> On 9/25/2019 9:36 AM, Pierre Tardy wrote:
[...]
>> 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.

Well, there is (or perhaps was, as the latest release is from 2013) DVCS
named Veracity that tried to be better than other DVCS in corporate
environment.  It did include file-locking:
  http://veracity-scm.com/
  https://ericsink.com/vcbe/html/veracity_locks.html


But perhaps there would be a better solution to handling file types that
do not support conflict resolution at all than file-level locks: see the
“Git for games: current problems and solutions” presentation by John
Austin at Git Merge 2019:
  https://www.youtube.com/watch?v=K3zOhU3NdWA&list=PL0lo9MOBetEFqBue4vNcTEnkBjgIQU1Q3&index=8&t=0s

Though the tool mentioned here had not seen any significant development
since Feb 1, 2019 (well, at least in the public repo at GitHub).

From Git Rev News: Edition 48 (February 27th, 2019)
  https://git.github.io/rev_news/2019/02/27/edition-48/

GR> John Austin, game studio technical lead from A Stranger Gravity and
GR> Funomena in “Git for games: current problems and solutions” talked
GR> about major problem with using Git in game development workflows,
GR> namely many and large binary files, for which file conflicts are
GR> lost work (minor change, like adding voiceover or changing equalizer
GR> settings results in large changes to files). File locking is one
GR> possibility, but it doesn’t play nicely with Git – it is inherently
GR> centralized. He introduces a new tool, [Git Global Graph][1] (a work in
GR> progress), which can be used to check at commit time if it wouldn’t
GR> create a divergent version of a file. The idea is that there should
GR> be only a single path through commit graph with changes to binary
GR> files.

[1]: https://github.com/Kleptine/gitglobalgraph


Best,
-- 
Jakub Narębski

Re: [DISCUSSION] Growing the Git community

[Jakub Narebski]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

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

Actually you can get feedback without having to subscribe to git mailing
list; and I am not talking here about GitGitGadget gathering response
like GitHub Issues <-> mail bridge.  You can get your feedback via
public-inbox.org, and respond to feedback via public-inboc.org mail to
[Usenet] news interface, reading and replying via NNTP (or replying via
email from thread read via NNTP):
  nntp://news.public-inbox.org/inbox.comp.version-control.git

Unfortunately it looks like newsreaders are dying category of
applications.  KDE's KNode got discontinued in 2015, XPN (X Python
Newsreader) last release had in 2009, MicroPlanet Gravity in 2010; there
is still Pan, Gnus for GNU Emacs; some e-mail clients also have support
for Usenet, like Mozilla Thunderbird (and SeaMonkey), Sylpheed and Claws
Mail.

This technique might not be described in our documentation...

Best,
-- 
Jakub Narębski

Re: [DISCUSSION] Growing the Git community

[Emily Shaffer]

On Thu, Sep 19, 2019 at 03:21:08PM -0700, Elijah Newren wrote:
> 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.)

I wanted to bump this thread. With the end of the Outreachy application
period we're left with at least a couple folks who are still interested
in learning how to contribute, even outside of the scope of the
Outreachy program. I'm still really interested in participating on a
mentors list like this; can we set one up?

To try and summarize what I remember from the summit:

 - It's lower pressure for the mentees if git@vger.kernel.org isn't CC'd
   on all git-mentoring@ emails
 - (But, if we did want to CC the main list, it'd be easy enough for
   people to filter out the mentoring emails if they don't care?)
 - We should advertise that list in the new contributor places:
    - CodingGuidelines or SubmittingPatches
    - mailing list welcome email
    - MyFirstContribution tutorial
    + (My own guess is that regularly CCing the main git list when
      appropriate - that is, when a question would be better posed to
      the whole community - would help advertise, too.)
 - The idea is less to match a single newbie with a single mentor (as
   folks are busy), and more to ask the same kind of questions one would
   usually ask a mentor and be responded to by whoever is available

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

I agree with this point. There's a lot to be said about the review
process in open source as compared to the review process "at home"
(internally at your job by people who sit next to you), and I'm not sure
where to say it in the context of the Git project. Maybe the
MyFirstContribution doc could use a blurb? Hmm.

 - Emily

Re: [DISCUSSION] Growing the Git community

[Johannes Schindelin]

Hi Emily,

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

Re: [DISCUSSION] Growing the Git community

[Christian Couder]

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.

There is already a private git-security mailing list
(https://groups.google.com/forum/#!forum/git-security) on Google
Groups so perhaps it makes sense to have git-mentors there too.

Thanks!

Re: [DISCUSSION] Growing the Git community

[Thomas Gummerer]

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.

Re: [DISCUSSION] Growing the Git community

[Emily Shaffer]

On Wed, Nov 13, 2019 at 03:06:24PM +0000, Thomas Gummerer wrote:
> 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 ;) )
 - Join group: Anyone. (Let's make the barrier to entry low.)

https://groups.google.com/forum/#!forum/git-mentoring/new

git-mentoring@googlegroups.com

 - Emily

Re: [DISCUSSION] Growing the Git community

[Jeff King]

On Wed, Nov 13, 2019 at 06:31:00PM -0800, 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 :) )

I think it makes sense to stay closed for now. One of the reasons to
have a separate group is to make it less daunting to post to. Having a
public archive may work against that.

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

It is annoying if things get cross-posted to git@vger (whoever replies
with the cc intact will get an annoying "you can't post here" bounce).
But I'd try it this way for a while and see.

>  - Join group: Anyone. (Let's make the barrier to entry low.)

Makes sense. I just joined.

-Peff

Re: [DISCUSSION] Growing the Git community

[Pratyush Yadav]

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

Re: [DISCUSSION] Growing the Git community

[Thomas Gummerer]

On 11/14, Pratyush Yadav wrote:
> 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.

I do agree with the original decision and think we should keep it
member-only.  As Peff mentioned somewhere else in the thread, this
makes the group less daunting to post to.  One of the distinct
advantages of having a separate mentoring list is to make the process
of starting to contribute less scary.

I believe that not having all messages public on the internet as
someone is learning to contribute creates an environment where people
are more likely and comfortable with trying to seek out help.

Of course anyone can join the group, so if someone really wants to see
the messages they can, but at least not everyone on the internet can
stumble upon them, e.g. through web searches.

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

Re: [DISCUSSION] Growing the Git community

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> I think it makes sense to stay closed for now. One of the reasons to
> have a separate group is to make it less daunting to post to. Having a
> public archive may work against that.

Yup.  For the same reason, I presume that the list members are not
disclosed to the public.  Or perhaps even to the list members?  It
might be nice to see who are participating as mentors, though.

As long as it is easy to point an already-asked-and-answered topic
to a new mentee, I think that is a sensible thing to do.  We would
find it to be inconvenient that we cannot use such an old exchange
to non-list members, though.

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

I noticed that, too.  Interestingly, GMail catches these spam that
come via the group just fine, so the filter over there may probably
be set to be more generous.