mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Taylor Blau <>
Subject: [TOPIC 11/12] Improving new contributor on-boarding
Date: Mon, 2 Oct 2023 11:22:24 -0400	[thread overview]
Message-ID: <ZRrgMDacYpj41DcO@nand.local> (raw)
In-Reply-To: <ZRregi3JJXFs4Msb@nand.local>

(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
* (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
* (Jonathan Tan) We could use a guideline on what's expected in terms of code
* (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
* (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
* (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.

  parent reply	other threads:[~2023-10-02 15:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-02 15:15 Notes from the Git Contributor's Summit, 2023 Taylor Blau
2023-10-02 15:17 ` [TOPIC 0/12] Welcome / Conservancy Update Taylor Blau
2023-10-02 15:17 ` [TOPIC 1/12] Next-gen reference backends Taylor Blau
2023-10-02 15:18 ` [TOPIC 02/12] Libification Goals and Progress Taylor Blau
2023-10-02 15:18 ` [TOPIC 3/12] Designing a Makefile for multiple libraries Taylor Blau
2023-10-02 15:19 ` [TOPIC 4/12] Scaling Git from a forge's perspective Taylor Blau
2023-10-02 15:19 ` [TOPIC 5/12] Replacing Git LFS using multiple promisor remotes Taylor Blau
2023-10-02 15:20 ` [TOPIC 6/12] Clarifying backwards compatibility and when we break it Taylor Blau
2023-10-02 15:21 ` [TOPIC 7/12] Authentication to new hosts without setup Taylor Blau
2023-10-02 15:21 ` [TOPIC 8/12] Update on jj, including at Google Taylor Blau
2023-10-02 15:21 ` [TOPIC 9/12] Code churn and cleanups Taylor Blau
2023-10-02 15:22 ` [TOPIC 10/12] Project management practices Taylor Blau
2023-10-02 15:22 ` Taylor Blau [this message]
2023-10-02 15:22 ` [TOPIC 12/12] Overflow discussion Taylor Blau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZRrgMDacYpj41DcO@nand.local \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).