git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: git@vger.kernel.org
Subject: Re: [TOPIC 07/11] New Contributors and Discord
Date: Fri, 20 Sep 2024 15:48:27 -0700	[thread overview]
Message-ID: <xmqqjzf6c56s.fsf@gitster.g> (raw)
In-Reply-To: <Zu2Eup+vjI3dALYu@nand.local> (Taylor Blau's message of "Fri, 20 Sep 2024 10:20:42 -0400")

Taylor Blau <me@ttaylorr.com> writes:

> * 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

Would money solve these, e.g., by hiring somebody?

The issue would be how to find somebody good ("known to be good with
past track record" would be a bonus) and ensure that the community
trusts the choice they make and the output they produce, in the
areas like UI design or tech writing, that we know are not our
strong points.  Would we be able to give them enough freedom to
produce their best product, yet be able to stop them if needed when
their output turns out not so good as we hoped initially?  Are we
equipped to fairly evaluate their output?

> * 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?
> ...
> * moderation on discord is an issue - having an unmoderated discord will
>   actually drive away contributors. that means actual dedicated
>   moderation

It is not "discord" per-se, but lowering the barrier to entry would
mean you'll get more people with different background and different
idea of what is normal to deal with.

> * patrick: new contributors sending changes but the changes being
>   ignored

Paraphrase.  More patches written, not enough are reviewed.

> * 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

There needs to be a mechanism to ensure the technical correctness of
the result to replace the public reviewing on the mailing list for
the above model to work.

>    * 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

Sounds like a good way to make it easier to link names with faces.



  reply	other threads:[~2024-09-20 22:48 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 ` [TOPIC 07/11] New Contributors and Discord Taylor Blau
2024-09-20 22:48   ` Junio C Hamano [this message]
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=xmqqjzf6c56s.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    /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).