Elijah Newren <newren@xxxxxxxxx> writes: > On Thu, Sep 19, 2019 at 11:37 AM Derrick Stolee <stolee@xxxxxxxxx> 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@xxxxxxxxxxxxxxx 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
