1 |
Hi Michał! |
2 |
|
3 |
El 15/04/18 a las 19:58, Michał Górny escribió: |
4 |
> W dniu nie, 15.04.2018 o godzinie 18∶55 +0200, użytkownik Francisco Blas |
5 |
> Izquierdo Riera (klondike) napisał: |
6 |
>> Hi Michał! |
7 |
>> |
8 |
>> El 15/04/18 a las 14:22, Michał Górny escribió: |
9 |
>>> W dniu nie, 15.04.2018 o godzinie 13∶44 +0200, użytkownik Francisco Blas |
10 |
>>> Izquierdo Riera (klondike) napisał: |
11 |
>>>> Hi Michał! |
12 |
>>>> |
13 |
>>>> El 14/04/18 a las 09:24, Michał Górny escribió: |
14 |
>>>>> W dniu pią, 13.04.2018 o godzinie 23∶28 +0200, użytkownik Francisco Blas |
15 |
>>>>> Izquierdo Riera (klondike) napisał: |
16 |
>>>>>> Hi Michał, |
17 |
>>>>>> |
18 |
>>>>>> Taking into account that the letter and not the spirit of GLEP 39 is |
19 |
>>>>>> usually thrown around as a weapon ("INFORMATIVE", HAH!). I strongly |
20 |
>>>>>> disrecommend having more "informative" policies. |
21 |
>>>>>> |
22 |
>>>>>> Not to say that whether you like it or not, not all non ebuild related |
23 |
>>>>>> developer work is necessarily tied to a project. Even GLEP 39 mentions |
24 |
>>>>>> this: "Not everything (or everyone) needs a project." |
25 |
>>>>> If you have a good example of a developer contributing to Gentoo without |
26 |
>>>>> having commit access and without being tied to a project, I'm all ears. |
27 |
>>>> Here are some randomly picked tasks that don't require belonguing to a |
28 |
>>>> project: |
29 |
>>>> * Keeping the documentation on the wiki up to date and clear. |
30 |
>>>> * Writting new, relevant documentation. |
31 |
>>>> * Helping address users concerns over one of our official channels |
32 |
>>>> (forums, gentoo-user mailing list, IRC, etc.). |
33 |
>>>> * Helping users provide relevant information on bug reports. |
34 |
>>> Which of those tasks strictly require developer status? That said, some |
35 |
>>> of them fall into scope of one or more project -- e.g. Forums project or |
36 |
>>> Bug Wranglers project. |
37 |
>> None of them. In the same way it is not needed to be a developer to |
38 |
>> contribute ebuilds. But there is this thing called motivation and |
39 |
>> approval by their peers that tends to motivate most volunteers when |
40 |
>> there is no other incentives. Also: |
41 |
> Yes and no. We are not giving 'free commit access' to contributors. |
42 |
> Unlike, say, Wiki edits, accepting ebuilds from users involves |
43 |
> significant work on an existing developer with commit access (proxy |
44 |
> maintainer). So it's not 'the same way'. |
45 |
|
46 |
You are misinterpreting the argument here and providing a straw man. Do |
47 |
all developers need "free commit access"? No. Do any developers need |
48 |
"free commit access"? No as long as they can proxy commits through other |
49 |
developers who have access to the parts of the tree that developer can't |
50 |
access in this hypothetical case. Is it helpful for some developer to |
51 |
have "free commit access"? Yes, a clear example maybe AT. |
52 |
|
53 |
The fact is that when a developer comments on a bug, bugzilla shows a |
54 |
dev mark. When a developer posts to a mailing list it uses a gentoo.org |
55 |
address. When a developer uses IRC it has a gentoo cloak. The only |
56 |
exception is the wiki and even that is something that maybe should be |
57 |
considered. Turns out all of these things help developers perform some |
58 |
of the above mentioned tasks in a more efficient way, just in the same |
59 |
way that giving full tree access does for some tree related tasks. |
60 |
|
61 |
>> * Being a developer makes new/changed documentation more turst worthy |
62 |
>> (and that can be particularly important in some cases=. |
63 |
> Given that our documentation is mostly hosted on Wiki, I'd like to point |
64 |
> out that I seriously doubt that most of our users check page history to |
65 |
> see who has written which part of the document. I should also point out |
66 |
> that 'normally' Wikis are edited by everyone and their quality is |
67 |
> 'assured' not by access restrictions but by large number of reviewers |
68 |
> who correct articles. |
69 |
|
70 |
You go explain that to the Gentoo Hardened users, will you? In fact that |
71 |
was one of the reasons to have the Gentoo Hardened project pages |
72 |
protected on wiki migration, keeping the reliability of the doc. So |
73 |
whilst maybe not for you, we have a subset of users for which being able |
74 |
to go back to a version of the document verified by a developer provides |
75 |
a lot of value. |
76 |
|
77 |
> As a side note, I'm aware that some of the 'areas' of the wiki are |
78 |
> restricted to editing by developers. However, there is no real |
79 |
> agreement about it and there are people who strongly believe that |
80 |
> documentation should be kept open for user edits. |
81 |
> |
82 |
>> * Users are more likely to accept any input from a developer. |
83 |
>> * Users are more likely to follow directions by a developer. |
84 |
> This is somewhat correct. However, the truth is most of the users are |
85 |
> also more likely to accept input from someone who behaves like he were |
86 |
> a developer even though he isn't one. We have had a number of verbose |
87 |
> users on the mailing lists whose opinions were considered higher than |
88 |
> those of developers because they expressed them with a tone |
89 |
> of authority. |
90 |
|
91 |
Or maybe because of their history. The gentoo.org address is a hint at |
92 |
the existence of prior good contributions by somebody but is not the |
93 |
only one. Users are more likely to trust and hold higher opinion on |
94 |
those who have helped them in the past. |
95 |
|
96 |
> On the other hand, if you look through the Forums you'd notice how many |
97 |
> users actually follow bad advises given by non-developers. |
98 |
|
99 |
For this argument to be valid you'll have to consider only the cases |
100 |
where bad advice was provided by a non-dev and good advice was provided |
101 |
by a dev within a reasonable amount of time. Mostly because if no good |
102 |
advise is provided by a developer or it is provided too late, the user |
103 |
will follow the bad advice as it was the only input that person got. |
104 |
|
105 |
>> All of them things not "strictly" needed but particularly helpful for |
106 |
>> the cases I propose. Also keep in mind that the fact there is a project |
107 |
>> covering some of those cases doesn't mean that the specific developer is |
108 |
>> willing or needs to be part of it. You don't need to be part of bug |
109 |
>> wranglers to help with bug management. You don't need to be part of the |
110 |
>> forums project to answer questions on the forums nor you need to be part |
111 |
>> of the OPS project to assist users over IRC. |
112 |
> To some degree, yes. However, the relevant projects still keep some |
113 |
> degree of power over the specific area. As you mention, you don't have |
114 |
> to be part of bug-wranglers but you *need* to follow their rules. If |
115 |
> you start wrangling bugs against the rules set by bug-wranglers, we |
116 |
> aren't going to be happy about it. |
117 |
> |
118 |
> Plus, getting recruited involves someone confirming your skills |
119 |
> and mentoring you. If your intent is to help in any of those areas, it |
120 |
> seems reasonable that someone *already working on them* should help you |
121 |
> and vouch for you. Therefore, projects. |
122 |
|
123 |
At the beginning yes, but people change over time and so may do their |
124 |
contributions. Sunrise project is dead, X11 |
125 |
https://wiki.gentoo.org/wiki/Project:X11 doesn't list you as a member |
126 |
and these two where the projects that scarabeus mentioned in your |
127 |
developer recruitment bug. Like you a non ebuild developer may still be |
128 |
contributing to areas other than these in which it began its career and |
129 |
it may do so without even belonging to a project. |
130 |
|
131 |
|
132 |
>>>> All those are tasks making a very significant contribution to Gentoo. |
133 |
>>>> All of those are tasks that don't require being a member of any project |
134 |
>>>> to be performed, just having the relevant experience and skills. |
135 |
>>>> So here is my proof. Where is yours? |
136 |
>>>> |
137 |
>>>> Also why have to be the project leads the one determining the activity |
138 |
>>>> non ebuild developers do? After all GLEP39 clearly states too: " Instead |
139 |
>>>> the practical responsibility of a lead is "whatever the members |
140 |
>>>> require", and if that isn't satisfied, the members can get a new lead |
141 |
>>>> (if they can find somebody to take the job!)." Which doesn't names |
142 |
>>>> "determining the activity non ebuild developers do". Or maybe could it |
143 |
>>>> be that you are planning to force project leads to define those |
144 |
>>>> activites in which case you should modify ALSO GLEP 39. |
145 |
>>> First of all, I should point out to you that 'GLEP 39' was created at |
146 |
>>> the time when 'developers' were only people having commit access. While |
147 |
>>> people doing other tasks were called 'staffers' and therefore were not |
148 |
>>> covered by GLEP 39. Is reducing their privileges what you're really |
149 |
>>> pursuing? |
150 |
>> No, I'm pursuing that they are treated in the same way a developer is! |
151 |
>> |
152 |
>>> That said, all I'm doing here is noting down the current Undertaker |
153 |
>>> policies. The classification into two groups determines the two main |
154 |
>>> methods of checking developer's activity. In case of developers with |
155 |
>>> repo/gentoo.git commit access, it is easy. In case of the remaining |
156 |
>>> developers, this is much harder. |
157 |
>>> |
158 |
>>> I think that so far the largest group of non-commit-access developers |
159 |
>>> were Forum project members. Others were also contributing to some kind |
160 |
>>> of project (e.g. Infra). The only reasonably tangible method were |
161 |
>>> querying the relevant projects to determine whether their members were |
162 |
>>> active and to establish a good way of measuring one's activity. |
163 |
>>> |
164 |
>>> Of course, if you insist we could just say that Undertakers determine |
165 |
>>> the activity at their own accord, and retire people who are apparently |
166 |
>>> inactive without consulting the project leads. However, that seems |
167 |
>>> inferior to the current practice. |
168 |
>> This is not what I'm saying. In fact current practice is different from |
169 |
>> what you purvey: |
170 |
>> * Ebuild developers are usually asked about reassignment: see |
171 |
>> https://bugs.gentoo.org/show_bug.cgi?id=vapier or |
172 |
>> https://bugs.gentoo.org/show_bug.cgi?id=hwoarang |
173 |
>> * If they state they are interested in maintaining the packages they are |
174 |
>> allowed to do so (I guess unless the council decides to reassign them). |
175 |
> The fact is, what you perceive as current practice is pretty much |
176 |
> the 'optimistic' solution. I don't think we really had many cases of |
177 |
> people who tried to abuse this to keep the developer status after really |
178 |
> stopping to contribute to Gentoo, and I don't think we really consider |
179 |
> it urgent to 'kick' them. However, this doesn't mean that it wouldn't |
180 |
> happen if need so. |
181 |
> |
182 |
> I don't like to point to specific people but we've recently retired |
183 |
> an ex-Forums project member who stopped contributing years ago |
184 |
> but wanted to keep the status. |
185 |
|
186 |
So why don't just update the undertakers policy to account for such |
187 |
cases then? Anyways a developer who is not happy about its retirement is |
188 |
likely to ask council to address the issue. |
189 |
|
190 |
>> Here is a similar approach that would work for both: |
191 |
>> * Once a developer has been inactive for x time (for example not having |
192 |
>> voted on two consecutive council electiions), the developer is contacted |
193 |
>> by undertakers and asked whether he/she/it is still interested in Gentoo |
194 |
>> and has contributed soomething that went missing in this period. |
195 |
> This opens a loophole for people who keep the developer status only to |
196 |
> vote in elections. Do you consider it fair to give the same level of |
197 |
> vote to people who spend many hours each week contributing to Gentoo, |
198 |
> and people who don't contribute at all but only keep the status to have |
199 |
> control over Gentoo? |
200 |
|
201 |
No, but somebody who hasn't voted in elections for say two years is |
202 |
probably inactive (or not interested), that is why the clause is "for |
203 |
example" and not "only and only if". |
204 |
|
205 |
That said, I'm going to give you a different question: "Do you consider |
206 |
it fair to give the same level of vote to people who spend many hours |
207 |
each week contributing to Gentoo without keeping up with any policy |
208 |
changes unless pointed to making other people lose time as to people who |
209 |
make small contributions now and then but actively keep themselves up to |
210 |
date so that these have high value and require little or no work from |
211 |
others?" |
212 |
|
213 |
>> Undertakers also give a deadline for a reply. |
214 |
>> ** If the answer is afirmative and the developer sends some |
215 |
>> contributions the undertakers close the issue. |
216 |
>> ** If the answer is negative but the developer wants to continue |
217 |
>> contributing, the undertaker can provide advice on how to do so and |
218 |
>> extend the deadline a bit (after which the developer will be retired and |
219 |
>> invited to take the tests). |
220 |
>> ** If the answer is negative and the developer is okay with retiring, |
221 |
>> retirement is done. |
222 |
>> ** If no reply is obtained before the deadline, retirement is done. |
223 |
> Well, let me just summarize the problem: it is really hard to 'measure' |
224 |
> contributions. We don't want to make people who contribute in unusual |
225 |
> ways to feel offended because Undertakers were not aware of this |
226 |
> (and yes, we also had pretty offensive behavior from people who |
227 |
> apparently were contributed in non-Undertaker visible ways). We don't |
228 |
> want to create a huge catalog of possible contributions. In the end, we |
229 |
> don't want to really end up judging quantities of contributions to |
230 |
> distinguish between people actually contributing and 'trying to work |
231 |
> around the mechanisms'. |
232 |
> |
233 |
> That said, what you're saying is pretty much the case. The main idea |
234 |
> with project leads is that they say Undertakers how to determine |
235 |
> the activity in specific areas in Gentoo. In fact, we could take this |
236 |
> even further and say you don't have to be member of Forums, bug- |
237 |
> wranglers etc. -- but leads of those projects may be asked to verify |
238 |
> your contributions. |
239 |
|
240 |
The point you are missing is that project leads may not be aware of a |
241 |
specific developer's contributions, but a developer is expected to, at |
242 |
least, know which its most significant ones were. |
243 |
|
244 |
Also I'm not expecting undertakers to measure contributions, just to |
245 |
reason if they are positive for the project in some way. In general it's |
246 |
an awful idea to retire anybody who has even a small positive impact on |
247 |
Gentoo because then you are likely to go from small positive impact to |
248 |
no impact at all. |
249 |
|
250 |
>> Turns out that this is, in a way, the process documented on the |
251 |
>> Undertakers project itself: https://wiki.gentoo.org/wiki/Project:Undertakers |
252 |
>> |
253 |
>>> What is the problem you're trying to solve here? Are you just arguing |
254 |
>>> for the sake of arguing? Or are you pursuing the concept of 'every |
255 |
>>> developer obtains his developer status forever, until he agrees to |
256 |
>>> retire'? |
257 |
>> I'm saying that: |
258 |
>> * It is the responsability of the developers to provide signs of |
259 |
>> activity if none was detected. |
260 |
>> * It is usually a bad idea to forcefully retire an inactive developer as |
261 |
>> that person may not come back once its life circumstances change. |
262 |
>> |
263 |
> This is really covered by Undertakers policy, and the GLEP explicitly |
264 |
> says it doesn't cover it. |
265 |
|
266 |
|
267 |
Where? In the "However, there seems to be no single document binding all |
268 |
of them together. This GLEP aims to be precisely that." Because that |
269 |
pretty much sounds as "This document replaces said policies by bringing |
270 |
them together" to me. |
271 |
|
272 |
|
273 |
To prove my point here is a different definition: |
274 |
|
275 |
A *Gentoo Developer* is a person who has successfully passed the |
276 |
recruitment procedure (as defined at the time of his/her joining) and is |
277 |
making positive contributions to Gentoo Linux project in some way. |
278 |
|
279 |
Simple, straightforward and keeps every developer under the same |
280 |
standards in particular "making positive contributions to Gentoo Linux |
281 |
project in some way". |
282 |
|
283 |
Klondike |
284 |
|
285 |
PS: Sending this also to gentoo-project as I didn't add the address before. |