git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[TOPIC 07/11] New Contributors and Discord

From
Taylor Blau <me@ttaylorr.com>
Date
Sep 20, 2024, 14:20 UTC
Message-ID
<Zu2Eup+vjI3dALYu@nand.local>
In-Reply-To
<Zu2DmS30E0kKug2a@nand.local>

How to attract new contributors? + Community Discord =====================================================

(moderator: Jonathan N + Calvin Wan, notetaker: Emily)
* jonathan: we talk about this a lot 🙂 let's avoid the common pitfall
  of catering to the tiktokkers and the youths (hypothesizing about
  "current generation"):
* but, our contributor base isn't representative of our user base
* and our current contributor base doesn't reflect exactly the skills
  needed to improve git - like interface design is not our strong suit.
  how to attract people who are better at our weak spots?
   * taylor: this weakness is an existential problem for Git. jj,
     gitbutler, gitkraken, etc
   * mark: +1
   * peff: one size doesn't fit all, us deciding not to include a GUI is
     understandable, but workflow improvements like jj's are pretty
     interesting
   * jonathan: ex. in hg there's someone very involved in UX review. we
     don't have someone like that
* missing other disciplines - tech writing, product management, UX
  research, etc.
   * common problem in open source but would be cool if we could get
     good at attracting/retaining these people - and cool for the
     not-eng-discipline people
   * patrick: we could adopt a style guide or guideline but we still
     wouldn't be good at enforcement
   * john: people need to know what they can contribute to - cf. project
     tracking discussion later on
* jonathan: instead of trying to guess - can we think generally, how do
  we make work easier to approach? how can we lower the barrier to
  entry?
* patrick: someone is writing third-party rewrite of gitglossary. huge
  improvement over what we have, well made, but the person didn't want
  to come back to contribute. was afraid of the community giving
  pushback
   * patrick was willing to handhold this potential contributor, but it
     didn't seem like enough to make this person comfortable
* jonathan: related to community discord server - what does it mean to
  function better as a community?
* calvin: the entry point doesn't need to be discord, but we should pick
  some entry point that lets users contribute other than mailing list
  participation
   * and need to be able to navigate new contributions comfortably
* brian: how to write text that's accessible to non-native english
  speakers, for example? the mailing list isn't great for these kinds of
  changes.
* discord is proprietary, that is sometimes an issue
* moderation on discord is an issue - having an unmoderated discord will
  actually drive away contributors. that means actual dedicated
  moderation
   * balancing between sufficient moderation (list) and ease of use
     (discord)
* patrick: new contributors sending changes but the changes being
  ignored
* brian: git-send-email is a barrier, but so are PRs/MRs in some cases
* jonathan: the localization example is a good one - the translation
  layer is in github, uses a very typical dev workflow, and that's
  working well. there's a strong community there. are there other places
  we can do something similar?
* peff: can we do that with documentation?
   * jonathan: can we have a documentation maintainer? hypothetically:
     we hire a tech writer, and that tech writer acts as the
     documentation maintainer only. curating existing docs, making sure
     docs changes get good reviews, how to attract new tech writer
     contributors, etc
   * peff: can we manage documentation as a subproject that doesn't use
     the mailing list, and make tech writers' lives easier?
      * how to negotiate that with code changes that require doc changes
        is trickier, we'd have to figure out how to do it, but doable
      * jonathan: readthedocs
* jonathan: we don't advertise well that we can accept contributions in
  a different way if people are committed to the improvement
   * peff: sometimes a mentor can "translate" a contribution. Individual
     contributors are already interested in mentoring, do we need
     more/different mentoring?
   * mentoring list isn't working well yet - maybe it's too faceless?
     should we get a list of individuals who want to mentor?
   * taylor: should we literally put photos of the people on the
     mentoring list up somewhere? "here are real humans, they will reply
     to you on git-mentoring@"?
   * jonathan: in-person meetups help with this. emailing is
     transactional, but e.g. python meetups are interactive
* patrick: we had the git berlin meetup a few months ago, lot of people
  came, we did lightning talks and user conversations. it worked well -
  let's use that model more
   * taylor: hey, we can help spend money on that
   * brian: those are cool but for example, houston linux users group is
     quite small. meetups like this can be helpful, but it's not the
     only source.
   * peff: it doesn't really scale up. python users group are
     user-to-user, doesn't necessarily draw python project contributors.
   * nasamuffin: Gerrit has a community meeting once/month, should we
     use discord for f2f video meetups?
   * peff: if people want to do big group meetups great. we could also
     use it for 1:1 meetups that way, and advertise that it's an option
Previous: Taylor BlauNext: Junio C Hamano
Message 17 of 38 in “Notes from the Git Contributor's Summit, 2024”
  1. Taylor BlauSep 20, 2024
  2. 01/11 RustTaylor Blau, Sep 20, 2024
  3. rsbecker@nexbridge.comSep 20, 2024
  4. Sean AllredSep 23, 2024
  5. rsbecker@nexbridge.comSep 23, 2024
  6. Phillip WoodSep 24, 2024
  7. rsbecker@nexbridge.comSep 24, 2024
  8. Sean AllredSep 27, 2024
  9. rsbecker@nexbridge.comSep 27, 2024
  10. rsbecker@nexbridge.comSep 27, 2024
  11. 02/11 Top-level lib/ directoryTaylor Blau, Sep 20, 2024
  12. 03/11 Structured Error HandlingTaylor Blau, Sep 20, 2024
  13. 04/11 Platform Support PolicyTaylor Blau, Sep 20, 2024
  14. 05/11 : SHA 256 / Git 3.0Taylor Blau, Sep 20, 2024
  15. Junio C HamanoSep 20, 2024
  16. 06/11 Git and Software Freedom ConservancyTaylor Blau, Sep 20, 2024
  17. 07/11 New Contributors and DiscordTaylor Blau, Sep 20, 2024
  18. Junio C HamanoSep 20, 2024
  19. Kousik SanagavarapuSep 21, 2024
  20. Junio C HamanoSep 22, 2024
  21. Junio C HamanoSep 22, 2024
  22. Konstantin RyabitsevSep 23, 2024
  23. Junio C HamanoSep 23, 2024
  24. Konstantin RyabitsevSep 24, 2024
  25. Junio C HamanoSep 24, 2024
  26. Konstantin RyabitsevSep 24, 2024
  27. Phillip WoodSep 27, 2024
  28. Junio C HamanoSep 27, 2024
  29. Phillip WoodOct 1, 2024
  30. 08/11 Modern Build SystemsTaylor Blau, Sep 20, 2024
  31. Eli SchwartzSep 23, 2024
  32. Patrick SteinhardtSep 24, 2024
  33. 09/11 Bundle-URI on fetch / resume-able cloneTaylor Blau, Sep 20, 2024
  34. 10/11 Project TrackingTaylor Blau, Sep 20, 2024
  35. Junio C HamanoSep 20, 2024
  36. Junio C HamanoSep 20, 2024
  37. Phillip WoodSep 23, 2024
  38. 11/11 git-scm.com state of the siteTaylor Blau, Sep 20, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.