Re: [gentoo-project] RFC: "Trusted contributor model"

[Roy Bamford]

On 2022.07.22 12:56, Joonas Niilola wrote:
> Cross-posting to gentoo-dev and -project lists due to technical and
> non-technical nature. Reply-to is set to -project.
>
> Once again new council has been elected: congratulations to the chosen
> members! And once again many nominees expressed their wishes to see
> more
> non-developer contributors to become official developers. Yet, only
> very
> few people (if any) are interested in mentoring them. I get it, the
> relationship between a mentor and their mentee is very intimate, and
> mentoring takes a lot of time. While the Github PRs are helping us
> increase the user contributions merged, perhaps it's distancing us
> from
> creating stronger bonds with the contributors? But more about this
> topic
> later.
>
>
> 1st RFC: "Trusted contributor model"
>
> I'm proposing us to giving special commit access to our well-reputable
> contributors (mostly proxied maintainers). They'd have access _only_
> to
> their maintained package in git-tree. To understand what I mean, check
>   git shortlog -s -n net-im/telegram-desktop-bin/
>   git shortlog -s -n net-im/signal-desktop-bin/
>
> There are few packages like these where I'd already trust the core
> proxied maintainer to commit at their will. It's as ajak said during
> the
> council election; _We_ are the bottleneck currently reviewing and
> _testing_ contributions, and with these two examples above, 99 % of
> time
> everything's in condition and we just need to merge. Obviously if
> these
> trusted contributors had to touch another package, or anything in
> profiles/ (just basically anything outside their dedicated package
> directory) they'd have to do a PR or .patch file to be merged by
> official developers. And they'd still need a proxy Gentoo
> developer/project listed in metadata, at least for now, to take
> responsibility.
>
> On the technical side I'm not sure how to achieve this, but I know it
> can be done. For example the sync-repos are compiled like this all the
> time. If this proposal gains support, I'm willing to start figuring it
> out more in-depth.
>
> AFAIK Fedora and Arch have somewhat similar systems in place already.

Try it and see. 
Once access had been granted. Who is responsible for monitoring?
I would expect it to be the dev that usually made the commits but
due to the trust model, more or a random sample basis.

The access can be revoked, if required, so it seems to be a win/win.
  
Are these trusted contributors devs?
e.g. accounts on Woodpecker, standing/voting in council elections
and so on?


>
>
> 2nd RFC: Recruiting proven contributors without a mentor
>
> I'm aware recruiters don't really need to ask a permission here, but I
> believe it's great to gauge the general feelings about this
> beforehand.
> What would you say if recruiters started more actively approaching
> potential developers? And currently I'm talking about people who have
> been active for a very long time (+year or two), who keep up with
> development-wise changes in Gentoo (eclasses, EAPI, virtuals...),
> participate in the community, and always provide top-quality
> contributions, but for some reason never got a mentor? I'd like to
> point
> out that this method would only be for the very few ones and
> recruiting
> through mentoring would still be the desired method. Recruiting
> through
> recruiters would still require the candidate to fill the
> ebuild/developer quiz, and they'd have to pass it without a mentor. So
> I'll emphasize: Currently only few special ones would qualify.
>
> But seeing the general lack of interest towards mentoring, maybe this
> is
> something we _need_ to do in near future.

I'm more on the fence on this one. The mentors job does not stop
when recruitments completes. The mentor is still required to keep a
weather eye on progress for another six months.

How does the post recruitment mentoring happen with no mentor?
I can see how it works with the subjects in RFQ 1 ... they have 
been mentored since they obtained their trusted status but what 
about others?
 
>
> -- juippis
>

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64