1 |
On Mon, Nov 5, 2018 at 5:11 PM Sam Jorna (wraeth) <wraeth@g.o> wrote: |
2 |
> |
3 |
> On 3/11/18 2:05 am, Michał Górny wrote: |
4 |
> > Hello, |
5 |
> > |
6 |
> > The Undertakers team has frequently received various forms of |
7 |
> > 'criticism' of their effort in attempting to find and retire inactive |
8 |
> > developers. This is getting as far as to claim that we shouldn't retire |
9 |
> > anyone because there are no limits on commit slots. |
10 |
> > |
11 |
> > Therefore, I would like to ask the wider community a general question: |
12 |
> > how do you feel about preserving commit access for people who no longer |
13 |
> > actively commit to Gentoo? I'm talking about extreme cases, say, |
14 |
> > no commits to any user-visible repository for over a year. |
15 |
> |
16 |
> Hello. |
17 |
> |
18 |
> I'd like to suggest that developers be allowed to retain commit |
19 |
> privileges until and unless they are unresponsive to status queries or |
20 |
> have demonstrated some kind of negative intent. |
21 |
|
22 |
> I understand the concern of allowing commit access to persist for AWOL |
23 |
> contributors, but for those with low commit frequency it's effectively |
24 |
> saying "your volunteer contributions aren't enough". |
25 |
|
26 |
And this is not in my opinion the kind of message we want to send, |
27 |
unless we want gentoo to become an elitist that only welcomes people |
28 |
who are "productive enough", which in my opinion also aggravates the |
29 |
risk of burnout. Quite frankly, "you aren't active enough to deserve |
30 |
to keep your developer status" is rather demoralizing, especially |
31 |
since we aren't actually being paid to work on Gentoo, at least not |
32 |
out of the Foundation's budget. |
33 |
|
34 |
From what I know, the undertakers project already has procedures in |
35 |
place for determining if a developer is inactive before they are |
36 |
retired, and I think the same procedures would apply just as easily |
37 |
|
38 |
> For myself, due to various factors my time for productive commit |
39 |
> development is severely limited, but as I only maintain a couple of |
40 |
> packages which, to my knowledge, don't have any issues, removing commit |
41 |
> access just means those that I do maintain become orphaned, and when I |
42 |
> do get time to work on something I have to work through GitHub or |
43 |
> Bugzilla, increasing work for whichever developer is kind enough to |
44 |
> facilitate my contribution. I am, however, able to be reached quickly, |
45 |
> and responsive to queries. |
46 |
> |
47 |
> If a developer is present, is not neglecting anything they maintain, has |
48 |
> not demonstrated any malicious intent, and is offering to spend what |
49 |
> time they can on contributions when they have the time to ensure they |
50 |
> don't break anything, why stop them? |
51 |
|
52 |
I second this motion. Having been removed from proxy maintainers for |
53 |
inactivity myself (and against my objections as well) I can speak to |
54 |
the increased load of being made aware of future bugs in the projects |
55 |
I used to work on. It adds unnecessary red tape to make developers |
56 |
jump through hoops to contribute. |
57 |
|
58 |
At the very least, once someone has passed muster with recruiters and |
59 |
whatnot they shouldn't have to do a heap of paperwork just to get back |
60 |
in. Maybe email once every few months to see if they're still |
61 |
responsive, and a quick check to make sure their SSH/GPG keys are |
62 |
still |
63 |
valid and that there are no technical issues, but I oppose any changes |
64 |
in one's status as a developer just on inactivity alone. |
65 |
|
66 |
Also, I would like to advance an example I personally encountered: |
67 |
|
68 |
What if there's simply nothing for the developer to do? Like if for |
69 |
example they're maintaining a package that's gone quiet upstream but |
70 |
which doesn't have any bugs open against it either? |
71 |
|
72 |
No, this doesn't include the idle developer simply finding a neglected |
73 |
area of gentoo to work on instead. The pool of available work to |
74 |
perform is still going to be finite, and on top of that the areas of |
75 |
gentoo needing attention when another area stops giving developers |
76 |
something to do may simply be outside their expertise. |
77 |
|
78 |
If someone has proven they can contribute and be trusted they |
79 |
shouldn't be removed in my opinion. As long as they aren't slacking |
80 |
off or sabotaging the distro. Going AWOL /with/ outstanding work on |
81 |
your desk, such as open bugs against packages you maintain? That is |
82 |
more serious and should probably warrant attention from the |
83 |
undertakers. But just going quiet period? Not so much since their |
84 |
absence isn't hurting Gentoo. The question is: is their retention of |
85 |
access causing harm to gentoo or obstructing development? |
86 |
|
87 |
If they answer their emails from the undertakers that should be good |
88 |
enough assuming they haven't actively gone against Gentoo. |
89 |
|
90 |
I would also like to ask: |
91 |
|
92 |
Why should we remove them in the first place? As far as I know, |
93 |
letting people keep developer status and commit access doesn't burden |
94 |
Gentoo unduly. |
95 |
|
96 |
* If they're contributing, the overhead of incorporating their |
97 |
contributions is an investment |
98 |
* If they're not contributing, but haven't done anything harmful, then |
99 |
there's no burden |
100 |
* If they're harming the distro then they can be removed whether |
101 |
they're a burden or not. |
102 |
|
103 |
> Thanks; |
104 |
> -- |
105 |
> Sam Jorna (wraeth) |
106 |
> GPG ID: 0xD6180C26 |
107 |
> |