All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: git@vger.kernel.org
Subject: [TOPIC 07/11] New Contributors and Discord
Date: Fri, 20 Sep 2024 10:20:42 -0400	[thread overview]
Message-ID: <Zu2Eup+vjI3dALYu@nand.local> (raw)
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

  parent reply	other threads:[~2024-09-20 14:20 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-20 14:15 Notes from the Git Contributor's Summit, 2024 Taylor Blau
2024-09-20 14:17 ` [TOPIC 01/11] Rust Taylor Blau
2024-09-20 16:20   ` rsbecker
2024-09-23  2:25     ` Sean Allred
2024-09-23 12:17       ` rsbecker
2024-09-24 15:30         ` Phillip Wood
2024-09-24 22:44           ` rsbecker
2024-09-27  9:37             ` Sean Allred
2024-09-27 12:23               ` rsbecker
2024-09-27 17:40                 ` rsbecker
2024-09-20 14:17 ` [TOPIC 02/11] Top-level lib/ directory Taylor Blau
2024-09-20 14:18 ` [TOPIC 03/11] Structured Error Handling Taylor Blau
2024-09-20 14:19 ` [TOPIC 04/11] Platform Support Policy Taylor Blau
2024-09-20 14:19 ` [TOPIC 05/11]: SHA 256 / Git 3.0 Taylor Blau
2024-09-20 19:22   ` Junio C Hamano
2024-09-20 14:20 ` [TOPIC 06/11] Git and Software Freedom Conservancy Taylor Blau
2024-09-20 14:20 ` Taylor Blau [this message]
2024-09-20 22:48   ` [TOPIC 07/11] New Contributors and Discord Junio C Hamano
2024-09-21 17:02   ` Kousik Sanagavarapu
2024-09-22 19:15     ` Junio C Hamano
2024-09-22 19:44       ` Junio C Hamano
2024-09-23 13:51       ` Konstantin Ryabitsev
2024-09-23 21:31         ` Junio C Hamano
2024-09-24 18:06           ` Konstantin Ryabitsev
2024-09-24 19:15             ` Junio C Hamano
2024-09-24 19:23               ` Konstantin Ryabitsev
2024-09-27 10:08           ` Phillip Wood
2024-09-27 19:22             ` Junio C Hamano
2024-10-01 15:23               ` Phillip Wood
2024-09-20 14:21 ` [TOPIC 08/11] Modern Build Systems Taylor Blau
2024-09-23  2:01   ` Eli Schwartz
2024-09-24 12:13     ` Patrick Steinhardt
2024-09-20 14:22 ` [TOPIC 09/11] Bundle-URI on fetch / resume-able clone Taylor Blau
2024-09-20 14:22 ` [TOPIC 10/11] Project Tracking Taylor Blau
2024-09-20 19:41   ` Junio C Hamano
2024-09-20 19:49     ` Junio C Hamano
2024-09-23  9:15     ` Phillip Wood
2024-09-20 14:23 ` [TOPIC 11/11] git-scm.com state of the site Taylor Blau
  -- strict thread matches above, loose matches on Subject: below --
2024-08-24 17:20 [GSoC][PATCH] unit-tests: add tests for oidset.h Ghanshyam Thakkar
2024-08-26  7:02 ` Patrick Steinhardt
2024-08-26  9:31 ` Christian Couder
2024-08-26 15:46   ` Junio C Hamano
2024-09-26 18:28   ` Junio C Hamano
2024-09-26 19:12     ` [PATCH] howto-maintain-git: discarding inactive topics Junio C Hamano
2024-09-27  8:57     ` [GSoC][PATCH] unit-tests: add tests for oidset.h Christian Couder
2024-09-27 18:47       ` Junio C Hamano
2024-09-28  7:02         ` Patrick Steinhardt
2024-09-30 18:48           ` Junio C Hamano

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=Zu2Eup+vjI3dALYu@nand.local \
    --to=me@ttaylorr.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.