Re: [TOPIC 07/11] New Contributors and Discord

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 20, 2024, 22:48 UTC
Message-ID: <xmqqjzf6c56s.fsf@gitster.g>
In-Reply-To: <Zu2Eup+vjI3dALYu@nand.local>

Taylor Blau <me@ttaylorr.com> writes:

Show 20 quoted lines

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

Show 7 quoted lines

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

Show 15 quoted lines

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