Taylor Blau <me@xxxxxxxxxxxx> 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.
