1 |
Hi Michał! |
2 |
|
3 |
El 15/04/18 a las 14:22, Michał Górny escribió: |
4 |
> W dniu nie, 15.04.2018 o godzinie 13∶44 +0200, użytkownik Francisco Blas |
5 |
> Izquierdo Riera (klondike) napisał: |
6 |
>> Hi Michał! |
7 |
>> |
8 |
>> El 14/04/18 a las 09:24, Michał Górny escribió: |
9 |
>>> W dniu pią, 13.04.2018 o godzinie 23∶28 +0200, użytkownik Francisco Blas |
10 |
>>> Izquierdo Riera (klondike) napisał: |
11 |
>>>> Hi Michał, |
12 |
>>>> |
13 |
>>>> Taking into account that the letter and not the spirit of GLEP 39 is |
14 |
>>>> usually thrown around as a weapon ("INFORMATIVE", HAH!). I strongly |
15 |
>>>> disrecommend having more "informative" policies. |
16 |
>>>> |
17 |
>>>> Not to say that whether you like it or not, not all non ebuild related |
18 |
>>>> developer work is necessarily tied to a project. Even GLEP 39 mentions |
19 |
>>>> this: "Not everything (or everyone) needs a project." |
20 |
>>> If you have a good example of a developer contributing to Gentoo without |
21 |
>>> having commit access and without being tied to a project, I'm all ears. |
22 |
>> Here are some randomly picked tasks that don't require belonguing to a |
23 |
>> project: |
24 |
>> * Keeping the documentation on the wiki up to date and clear. |
25 |
>> * Writting new, relevant documentation. |
26 |
>> * Helping address users concerns over one of our official channels |
27 |
>> (forums, gentoo-user mailing list, IRC, etc.). |
28 |
>> * Helping users provide relevant information on bug reports. |
29 |
> Which of those tasks strictly require developer status? That said, some |
30 |
> of them fall into scope of one or more project -- e.g. Forums project or |
31 |
> Bug Wranglers project. |
32 |
|
33 |
None of them. In the same way it is not needed to be a developer to |
34 |
contribute ebuilds. But there is this thing called motivation and |
35 |
approval by their peers that tends to motivate most volunteers when |
36 |
there is no other incentives. Also: |
37 |
* Being a developer makes new/changed documentation more turst worthy |
38 |
(and that can be particularly important in some cases=. |
39 |
* Users are more likely to accept any input from a developer. |
40 |
* Users are more likely to follow directions by a developer. |
41 |
|
42 |
All of them things not "strictly" needed but particularly helpful for |
43 |
the cases I propose. Also keep in mind that the fact there is a project |
44 |
covering some of those cases doesn't mean that the specific developer is |
45 |
willing or needs to be part of it. You don't need to be part of bug |
46 |
wranglers to help with bug management. You don't need to be part of the |
47 |
forums project to answer questions on the forums nor you need to be part |
48 |
of the OPS project to assist users over IRC. |
49 |
|
50 |
>> All those are tasks making a very significant contribution to Gentoo. |
51 |
>> All of those are tasks that don't require being a member of any project |
52 |
>> to be performed, just having the relevant experience and skills. |
53 |
>> So here is my proof. Where is yours? |
54 |
>> |
55 |
>> Also why have to be the project leads the one determining the activity |
56 |
>> non ebuild developers do? After all GLEP39 clearly states too: " Instead |
57 |
>> the practical responsibility of a lead is "whatever the members |
58 |
>> require", and if that isn't satisfied, the members can get a new lead |
59 |
>> (if they can find somebody to take the job!)." Which doesn't names |
60 |
>> "determining the activity non ebuild developers do". Or maybe could it |
61 |
>> be that you are planning to force project leads to define those |
62 |
>> activites in which case you should modify ALSO GLEP 39. |
63 |
> First of all, I should point out to you that 'GLEP 39' was created at |
64 |
> the time when 'developers' were only people having commit access. While |
65 |
> people doing other tasks were called 'staffers' and therefore were not |
66 |
> covered by GLEP 39. Is reducing their privileges what you're really |
67 |
> pursuing? |
68 |
|
69 |
No, I'm pursuing that they are treated in the same way a developer is! |
70 |
|
71 |
> That said, all I'm doing here is noting down the current Undertaker |
72 |
> policies. The classification into two groups determines the two main |
73 |
> methods of checking developer's activity. In case of developers with |
74 |
> repo/gentoo.git commit access, it is easy. In case of the remaining |
75 |
> developers, this is much harder. |
76 |
> |
77 |
> I think that so far the largest group of non-commit-access developers |
78 |
> were Forum project members. Others were also contributing to some kind |
79 |
> of project (e.g. Infra). The only reasonably tangible method were |
80 |
> querying the relevant projects to determine whether their members were |
81 |
> active and to establish a good way of measuring one's activity. |
82 |
> |
83 |
> Of course, if you insist we could just say that Undertakers determine |
84 |
> the activity at their own accord, and retire people who are apparently |
85 |
> inactive without consulting the project leads. However, that seems |
86 |
> inferior to the current practice. |
87 |
|
88 |
This is not what I'm saying. In fact current practice is different from |
89 |
what you purvey: |
90 |
* Ebuild developers are usually asked about reassignment: see |
91 |
https://bugs.gentoo.org/show_bug.cgi?id=vapier or |
92 |
https://bugs.gentoo.org/show_bug.cgi?id=hwoarang |
93 |
* If they state they are interested in maintaining the packages they are |
94 |
allowed to do so (I guess unless the council decides to reassign them). |
95 |
|
96 |
Here is a similar approach that would work for both: |
97 |
* Once a developer has been inactive for x time (for example not having |
98 |
voted on two consecutive council electiions), the developer is contacted |
99 |
by undertakers and asked whether he/she/it is still interested in Gentoo |
100 |
and has contributed soomething that went missing in this period. |
101 |
Undertakers also give a deadline for a reply. |
102 |
** If the answer is afirmative and the developer sends some |
103 |
contributions the undertakers close the issue. |
104 |
** If the answer is negative but the developer wants to continue |
105 |
contributing, the undertaker can provide advice on how to do so and |
106 |
extend the deadline a bit (after which the developer will be retired and |
107 |
invited to take the tests). |
108 |
** If the answer is negative and the developer is okay with retiring, |
109 |
retirement is done. |
110 |
** If no reply is obtained before the deadline, retirement is done. |
111 |
|
112 |
Turns out that this is, in a way, the process documented on the |
113 |
Undertakers project itself: https://wiki.gentoo.org/wiki/Project:Undertakers |
114 |
|
115 |
> What is the problem you're trying to solve here? Are you just arguing |
116 |
> for the sake of arguing? Or are you pursuing the concept of 'every |
117 |
> developer obtains his developer status forever, until he agrees to |
118 |
> retire'? |
119 |
|
120 |
I'm saying that: |
121 |
* It is the responsability of the developers to provide signs of |
122 |
activity if none was detected. |
123 |
* It is usually a bad idea to forcefully retire an inactive developer as |
124 |
that person may not come back once its life circumstances change. |