Re: [DISCUSSION] Growing the Git community

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