1 |
Cross-posting to gentoo-dev and -project lists due to technical and |
2 |
non-technical nature. Reply-to is set to -project. |
3 |
|
4 |
Once again new council has been elected: congratulations to the chosen |
5 |
members! And once again many nominees expressed their wishes to see more |
6 |
non-developer contributors to become official developers. Yet, only very |
7 |
few people (if any) are interested in mentoring them. I get it, the |
8 |
relationship between a mentor and their mentee is very intimate, and |
9 |
mentoring takes a lot of time. While the Github PRs are helping us |
10 |
increase the user contributions merged, perhaps it's distancing us from |
11 |
creating stronger bonds with the contributors? But more about this topic |
12 |
later. |
13 |
|
14 |
|
15 |
1st RFC: "Trusted contributor model" |
16 |
|
17 |
I'm proposing us to giving special commit access to our well-reputable |
18 |
contributors (mostly proxied maintainers). They'd have access _only_ to |
19 |
their maintained package in git-tree. To understand what I mean, check |
20 |
git shortlog -s -n net-im/telegram-desktop-bin/ |
21 |
git shortlog -s -n net-im/signal-desktop-bin/ |
22 |
|
23 |
There are few packages like these where I'd already trust the core |
24 |
proxied maintainer to commit at their will. It's as ajak said during the |
25 |
council election; _We_ are the bottleneck currently reviewing and |
26 |
_testing_ contributions, and with these two examples above, 99 % of time |
27 |
everything's in condition and we just need to merge. Obviously if these |
28 |
trusted contributors had to touch another package, or anything in |
29 |
profiles/ (just basically anything outside their dedicated package |
30 |
directory) they'd have to do a PR or .patch file to be merged by |
31 |
official developers. And they'd still need a proxy Gentoo |
32 |
developer/project listed in metadata, at least for now, to take |
33 |
responsibility. |
34 |
|
35 |
On the technical side I'm not sure how to achieve this, but I know it |
36 |
can be done. For example the sync-repos are compiled like this all the |
37 |
time. If this proposal gains support, I'm willing to start figuring it |
38 |
out more in-depth. |
39 |
|
40 |
AFAIK Fedora and Arch have somewhat similar systems in place already. |
41 |
|
42 |
|
43 |
2nd RFC: Recruiting proven contributors without a mentor |
44 |
|
45 |
I'm aware recruiters don't really need to ask a permission here, but I |
46 |
believe it's great to gauge the general feelings about this beforehand. |
47 |
What would you say if recruiters started more actively approaching |
48 |
potential developers? And currently I'm talking about people who have |
49 |
been active for a very long time (+year or two), who keep up with |
50 |
development-wise changes in Gentoo (eclasses, EAPI, virtuals...), |
51 |
participate in the community, and always provide top-quality |
52 |
contributions, but for some reason never got a mentor? I'd like to point |
53 |
out that this method would only be for the very few ones and recruiting |
54 |
through mentoring would still be the desired method. Recruiting through |
55 |
recruiters would still require the candidate to fill the |
56 |
ebuild/developer quiz, and they'd have to pass it without a mentor. So |
57 |
I'll emphasize: Currently only few special ones would qualify. |
58 |
|
59 |
But seeing the general lack of interest towards mentoring, maybe this is |
60 |
something we _need_ to do in near future. |
61 |
|
62 |
-- juippis |