Re: [DISCUSSION] Growing the Git community

From: Emily Shaffer <emilyshaffer@google.com>
Date: Nov 12, 2019, 18:45 UTC
Message-ID: <20191112184547.GA38770@google.com>
In-Reply-To: <CABPp-BFXs4qes20S+9AZd++p3epW4eJ7Vu7zU_PdDysZ_D-yrg@mail.gmail.com>

On Thu, Sep 19, 2019 at 03:21:08PM -0700, Elijah Newren wrote:

Show 48 quoted lines

> 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

Show 11 quoted lines

> 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