Re: [gentoo-project] Gentoo Council 2022-23: Questions for Candidates: how to increase contributions

[Sam James]

> On 16 Jun 2022, at 19:06, Robin H. Johnson <robbat2@g.o> wrote:
>
> A question I'd like the candidates to answer.
>

I think mgorny's point about the questions is spot on -- they're not bad ones at all,
but they need the whole community to engage on them (so I hope non-nominees
might engage too). Council can't dictate things, and a lot of these aren't
within its gift, but it is of course important to know what we feel is important.

All that to say, I hope it prompts a discussion from all corners of the community,
not just candidates.

> What do you feel that Council can do to increase the contributions to
> Gentoo?
>
> - how do you feel development velocity of Gentoo should be measured?

> - how do you feel technical debt of Gentoo should be measured?
> - how do we make it easier to get orders of magnitude more contributors?


I've been trying to spend a lot of time on mentoring new developers and it's
worked pretty well, I think: https://dev.gentoo.org/~mgorny/gentoo-family.svg.

The problem is, I can't do everything (nor do I want to), and while more contributors
actually helps reduce workload in the long run, it still requires some up front
effort.

I worry a bit about how most developers don't seem to end up mentoring
either many or in a lot of cases, anybody at all. It's totally okay not to -
not everybody enjoys it, or has time, etc, but I hope that the reason is
something like time rather than being worried about how to do it correctly.

I'm interested in whether folks who haven't mentored anybody - or who
haven't in a good few years - have any insight on maybe guidance
recruiters could be offering (or people who have mentored extensively)
to make it less intimidating?

(CC'd recruiters@ in case they have any insight on why it tends to only
be a few of us doing that.)

Anyway, I really do believe the way forward is to keep prioritising mentoring
and bringing in new talent. For a while, I believed that people would make
themselves obvious (as in, get to the point where you think "why aren't
they a developer yet?"), but actually, that misses out a load of people!

Approaching folks who seem to do a good job but need some help
has been fruitful. I'd assumed before that maybe they wouldn't be
interested (if they hadn't approached _us_, then maybe it just wasn't
on their radar, and they're happy to proxy maintain bits), but actually,
everybody I've approached has been up for starting the process.

We need more folks coming in who can then in turn process more
contributions and ultimately recruit more.

> - how do we make it easier to do QA on significantly more contributions?

I think gitlab will be a good step forward here for its ease of wiring up
CI runners.

mgorny made reference to possibly running our current CI on every push
which would be a nice win too.

I think a lot of it is tied into the next question, i.e. it's easier to do QA on them
if we know we have good documentation for them and can point them to
resources instead of explaining the same thing informally over and over -
which doesn't scale.

> - what blockers do you perceive in the contribution processes, and how
>  do you think they should be tackled?

- GCO sign off continues to be a bit of an issue for some, but less than it used to be.
I'd continue to advocate for some leniency on the part of the merger if
they deem the changes non-copyrightable. Ultimately, would like to see
some of the GLEP suggestions proposed on -project a while ago possibly revived,
but would need to read through it all again to see where we landed.

Don't intend to rehash the whole thing right now though in this email as
I don't think it's the #1 factor at all.

- Better documentation for our workflow and tooling.

I think we're getting there. Standardising on pkgcheck is helpful here,
because we don't have to include two workflows on every wiki page
and so on.

I've had some feedback that we need some better use case-based
documentation - i.e. "If you want to do X, this is the right way".

I've spent a lot of time on improving the devmanual for bits like this and
plan on continuing with that, although I think the wiki is probably where
most of the confusing resources I hear about are.

- Lack of mergers!

People do tend to get frustrated with time taken to merge PRs. We do
alright or pretty well most of the time (depending on circumstances)
but only a handful of us merge PRs at all en-masse.

We need more people to be comfortable merging PRs - CI
to verify patches apply, a simple default USE flags build works
would go a long way here.

As for patches via Bugzilla, we don't get much of those, and it's
hard for me to have visibility into how many of them get merged.

The occasional mailing list patch to the proxy paint ML goes okay.

Both of those are really insignificant in terms of numbers compared
to PRs though, which is why I focused on it.

>
> Many of the developers I nominated in my previous email to the -project
> list were because are the very prolific contributors or have significant
> impact in their contributors: how can we increase not just the prolific
> contributors, but get many more contributors everywhere?
>

I think I've accidentally answered this above, but generally
feel quite strongly about reducing territoriality, which we can
do by making people feel "safe" and knowing their packages
will be taken care of.

For my part, I'm trying to document any gotchas or tricky parts
in any of my packages (both directly and indirectly in projects
I'm a member of).

Do aspire to possibly having a set of notes on the wiki or in metadata.xml
(proposed it before on gentoo-dev, may revive) which would help
a fair bit with this.

The gist being I think we need to make it less scary to step into
an area you don't know.

Best,
sam