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.
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
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.
Cross-posting to gentoo-dev and -project lists due to technical and non-technical nature. Reply-to is set to -project....
1st RFC: "Trusted contributor model"Conceptually, yes, I think this is a good improvement. I'd like upstream
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/
On the technical side I'm not sure how to achieve this, but I know itTechnically, I've got some implementation problems.
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.
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?
But seeing the general lack of interest towards mentoring, maybe this is something we _need_ to do in near future.Yes, let's make it possible to join by the quiz, and the recruiting
How would you suggest we track who has commit access, etc? The same
way we do with developers, via a developer bug?
I ask because I've noticed a lot of inactive proxied maintainers—one
of which had been listed in metadata.xml for 6 years but had never
committed to ::gentoo.
..., via Github PR or other means. I'd say pushing these
experimental packages is rather rare (for proxied people at least), and
can also be added without KEYWORDS for example.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 475 |
Nodes: | 16 (2 / 14) |
Uptime: | 17:19:56 |
Calls: | 9,487 |
Calls today: | 6 |
Files: | 13,617 |
Messages: | 6,121,089 |