Re: [DISCUSSION] Growing the Git community

Elijah Newren [off-list ref] writes:

On Thu, Sep 19, 2019 at 11:37 AM Derrick Stolee [off-list ref] wrote:

[...]

quoted

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

[...]

quoted

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