On Fri, Jul 22, 2022 at 4:56 AM Joonas Niilola <juip...@gentoo.org> 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.
Who decides which contributor gets access to which package? Is there a flow to eventually onboard contributors as developers? Why are the contributors not developers themselves, just with scoped ::gentoo access? -A > > AFAIK Fedora and Arch have somewhat similar systems in place already. > > > 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. > > -- juippis
