(Presenter: Jonathan Nieder, Notetaker: Xing Huang, Ronald Bhuleskar)
* (Jonathan Nieder) Not as structured of a conversation, but I see a lot of
interest, let's see how the conversation goes. Any open sourced project can be
scary for newcomers; the git project in particular has its unique aspects of
its workflow, such as the mailing list that rejects http formatted mails, etc.
I think overall we are welcoming. Ideally, we would like to attract all types
of contributors, in part because they help different kinds of users have more
of a voice.
* I am interested in how to make the onboarding process easier for the new
contributors; what do we see to make things easier? MyFirstContribution works
well as a tutorial doc, what is the next step for someone after they send
their first patch and get their first review in reply? How do you find a
mentor? Things like how to interpret the reviewer's tone can be hard to
navigate.
* (Emily) We can mark a patcher as a beginner's patch - the golang (?) project,
for example, assigns a mentor to newcomers. We have a mentorship list that's
inactive; could we use the same volunteers from there to give more hands-on
mentoring?
* (Jonathan Tan) We could use a guideline on what's expected in terms of code
quality.
* (Taylor) Folks who are newer contributors or haven't contributed much, do you
have perspectives to share?
* (Vincenzo) Finding a starting point, a problem to tackle, was difficult.
* #leftoverbits search term is listed in our
Documentation/ReviewingGuidelines.txt, but Taylor suspects no new comers
are looking into it.
* People in the project will start looking at the next event and get to meet
the person face to face to have a less daunting relationship.
* (Phillip) There is a lot of information for new contributors to digest in
CodingGuidelines, SubmittingPatches and MyFirstContribution. How do we find
a balance between providing useful guidelines and overwhelming them?
* (Jacob Stopak) As a newcomer, sent an idea that was too big to solve
completely myself, but I would have liked to know where it was going, what
is my part, what others will help with, and to be able to participate more
in its implementation instead of it being done by others.
* (Jonathan Nieder) The mailing list is noisy and someone interested in a
specific topic but the mailing list is flooded with lot of other things,
unless they are specifically cc-ed on the right things. There's no easy middle
ground between "my life is in the list" and "I only see what is sent to me".
* (Jakub) There's a bit of a middle ground - you can use a newsreader
* (Jonathan) In a project with a bug tracker, it's easier to know who is
j assigned to and who the collaborators are on something and what to expect
moving forward. The information is in one place. In the Git project, if
someone sends a patch on something I'm interested in, I have to interpret why
they're doing that - do they want to take this over? Are they giving me a
suggestion?
* (Han Young) Han finds contributor guide to be lacking in details, he finds
READMEs and discord to be complementary to his newcomer experience.
* (Emily) Which of these ideas should be implemented that makes the most sense?
* Auto assign 1:1 mentors to new contributors
* Split up the doc a bit more
* Wiki: Where to start
* Have more conferences
* Have a bug tracker
* Process documentation: What to do when a review comes in, next steps beyond
what MyFirstContribution describes.
* (Taylor) The mentor assignment bit is what excites me the most
* Most new contributors use GitGitGadget, it could notice new contributors
and find a mentor for them
* The key there would be documenting what that relationship should look like.
Helps with clear guidelines on avoiding the kind of hijacking case Jacob
mentioned (sorry about that!)
* (Jonathan Nieder) Great thing to do if we have a pool of mentors available.
This cultiire is appreciated.
* (Emily) Such culture is ingrained in Google in the form of community
contribution. (Junio) Hmm, where are the reviewers? :)
* (Glen) Discord or other informal channels are easier for mini-mentoring.
* (Jeff Hosteler) GitGitGadget is also doing mini-mentoring recently at a small
scale that polishes before the author submits.
* (Emily) Mostly GitHubbers? Should others pitch in?
* (Jeff Hostetler) I think I'm auto-subscribed because I have write access to
the repo.
* (Junio) I've done some reviews there (it shouldn't be limited to GitHub
folks).
* (Jacob) Thanks much for the documentation, step-by-step instructions are great
* I used instructions on how to send patches with "git send-email". I didn't
use GitGitGadget because it wasn't clear to me what it is.
