git.vger.kernel.org archive mirror
 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 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 NNTP newsgroup(s).