1 |
W dniu nie, 15.04.2018 o godzinie 18∶55 +0200, użytkownik Francisco Blas |
2 |
Izquierdo Riera (klondike) napisał: |
3 |
> Hi Michał! |
4 |
> |
5 |
> El 15/04/18 a las 14:22, Michał Górny escribió: |
6 |
> > W dniu nie, 15.04.2018 o godzinie 13∶44 +0200, użytkownik Francisco Blas |
7 |
> > Izquierdo Riera (klondike) napisał: |
8 |
> > > Hi Michał! |
9 |
> > > |
10 |
> > > El 14/04/18 a las 09:24, Michał Górny escribió: |
11 |
> > > > W dniu pią, 13.04.2018 o godzinie 23∶28 +0200, użytkownik Francisco Blas |
12 |
> > > > Izquierdo Riera (klondike) napisał: |
13 |
> > > > > Hi Michał, |
14 |
> > > > > |
15 |
> > > > > Taking into account that the letter and not the spirit of GLEP 39 is |
16 |
> > > > > usually thrown around as a weapon ("INFORMATIVE", HAH!). I strongly |
17 |
> > > > > disrecommend having more "informative" policies. |
18 |
> > > > > |
19 |
> > > > > Not to say that whether you like it or not, not all non ebuild related |
20 |
> > > > > developer work is necessarily tied to a project. Even GLEP 39 mentions |
21 |
> > > > > this: "Not everything (or everyone) needs a project." |
22 |
> > > > |
23 |
> > > > If you have a good example of a developer contributing to Gentoo without |
24 |
> > > > having commit access and without being tied to a project, I'm all ears. |
25 |
> > > |
26 |
> > > Here are some randomly picked tasks that don't require belonguing to a |
27 |
> > > project: |
28 |
> > > * Keeping the documentation on the wiki up to date and clear. |
29 |
> > > * Writting new, relevant documentation. |
30 |
> > > * Helping address users concerns over one of our official channels |
31 |
> > > (forums, gentoo-user mailing list, IRC, etc.). |
32 |
> > > * Helping users provide relevant information on bug reports. |
33 |
> > |
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 |
> |
38 |
> None of them. In the same way it is not needed to be a developer to |
39 |
> contribute ebuilds. But there is this thing called motivation and |
40 |
> approval by their peers that tends to motivate most volunteers when |
41 |
> there is no other incentives. Also: |
42 |
|
43 |
Yes and no. We are not giving 'free commit access' to contributors. |
44 |
Unlike, say, Wiki edits, accepting ebuilds from users involves |
45 |
significant work on an existing developer with commit access (proxy |
46 |
maintainer). So it's not 'the same way'. |
47 |
|
48 |
> * Being a developer makes new/changed documentation more turst worthy |
49 |
> (and that can be particularly important in some cases=. |
50 |
|
51 |
Given that our documentation is mostly hosted on Wiki, I'd like to point |
52 |
out that I seriously doubt that most of our users check page history to |
53 |
see who has written which part of the document. I should also point out |
54 |
that 'normally' Wikis are edited by everyone and their quality is |
55 |
'assured' not by access restrictions but by large number of reviewers |
56 |
who correct articles. |
57 |
|
58 |
As a side note, I'm aware that some of the 'areas' of the wiki are |
59 |
restricted to editing by developers. However, there is no real |
60 |
agreement about it and there are people who strongly believe that |
61 |
documentation should be kept open for user edits. |
62 |
|
63 |
> * Users are more likely to accept any input from a developer. |
64 |
> * Users are more likely to follow directions by a developer. |
65 |
|
66 |
This is somewhat correct. However, the truth is most of the users are |
67 |
also more likely to accept input from someone who behaves like he were |
68 |
a developer even though he isn't one. We have had a number of verbose |
69 |
users on the mailing lists whose opinions were considered higher than |
70 |
those of developers because they expressed them with a tone |
71 |
of authority. |
72 |
|
73 |
On the other hand, if you look through the Forums you'd notice how many |
74 |
users actually follow bad advises given by non-developers. |
75 |
|
76 |
> All of them things not "strictly" needed but particularly helpful for |
77 |
> the cases I propose. Also keep in mind that the fact there is a project |
78 |
> covering some of those cases doesn't mean that the specific developer is |
79 |
> willing or needs to be part of it. You don't need to be part of bug |
80 |
> wranglers to help with bug management. You don't need to be part of the |
81 |
> forums project to answer questions on the forums nor you need to be part |
82 |
> of the OPS project to assist users over IRC. |
83 |
|
84 |
To some degree, yes. However, the relevant projects still keep some |
85 |
degree of power over the specific area. As you mention, you don't have |
86 |
to be part of bug-wranglers but you *need* to follow their rules. If |
87 |
you start wrangling bugs against the rules set by bug-wranglers, we |
88 |
aren't going to be happy about it. |
89 |
|
90 |
Plus, getting recruited involves someone confirming your skills |
91 |
and mentoring you. If your intent is to help in any of those areas, it |
92 |
seems reasonable that someone *already working on them* should help you |
93 |
and vouch for you. Therefore, projects. |
94 |
|
95 |
> > > All those are tasks making a very significant contribution to Gentoo. |
96 |
> > > All of those are tasks that don't require being a member of any project |
97 |
> > > to be performed, just having the relevant experience and skills. |
98 |
> > > So here is my proof. Where is yours? |
99 |
> > > |
100 |
> > > Also why have to be the project leads the one determining the activity |
101 |
> > > non ebuild developers do? After all GLEP39 clearly states too: " Instead |
102 |
> > > the practical responsibility of a lead is "whatever the members |
103 |
> > > require", and if that isn't satisfied, the members can get a new lead |
104 |
> > > (if they can find somebody to take the job!)." Which doesn't names |
105 |
> > > "determining the activity non ebuild developers do". Or maybe could it |
106 |
> > > be that you are planning to force project leads to define those |
107 |
> > > activites in which case you should modify ALSO GLEP 39. |
108 |
> > |
109 |
> > First of all, I should point out to you that 'GLEP 39' was created at |
110 |
> > the time when 'developers' were only people having commit access. While |
111 |
> > people doing other tasks were called 'staffers' and therefore were not |
112 |
> > covered by GLEP 39. Is reducing their privileges what you're really |
113 |
> > pursuing? |
114 |
> |
115 |
> No, I'm pursuing that they are treated in the same way a developer is! |
116 |
> |
117 |
> > That said, all I'm doing here is noting down the current Undertaker |
118 |
> > policies. The classification into two groups determines the two main |
119 |
> > methods of checking developer's activity. In case of developers with |
120 |
> > repo/gentoo.git commit access, it is easy. In case of the remaining |
121 |
> > developers, this is much harder. |
122 |
> > |
123 |
> > I think that so far the largest group of non-commit-access developers |
124 |
> > were Forum project members. Others were also contributing to some kind |
125 |
> > of project (e.g. Infra). The only reasonably tangible method were |
126 |
> > querying the relevant projects to determine whether their members were |
127 |
> > active and to establish a good way of measuring one's activity. |
128 |
> > |
129 |
> > Of course, if you insist we could just say that Undertakers determine |
130 |
> > the activity at their own accord, and retire people who are apparently |
131 |
> > inactive without consulting the project leads. However, that seems |
132 |
> > inferior to the current practice. |
133 |
> |
134 |
> This is not what I'm saying. In fact current practice is different from |
135 |
> what you purvey: |
136 |
> * Ebuild developers are usually asked about reassignment: see |
137 |
> https://bugs.gentoo.org/show_bug.cgi?id=vapier or |
138 |
> https://bugs.gentoo.org/show_bug.cgi?id=hwoarang |
139 |
> * If they state they are interested in maintaining the packages they are |
140 |
> allowed to do so (I guess unless the council decides to reassign them). |
141 |
|
142 |
The fact is, what you perceive as current practice is pretty much |
143 |
the 'optimistic' solution. I don't think we really had many cases of |
144 |
people who tried to abuse this to keep the developer status after really |
145 |
stopping to contribute to Gentoo, and I don't think we really consider |
146 |
it urgent to 'kick' them. However, this doesn't mean that it wouldn't |
147 |
happen if need so. |
148 |
|
149 |
I don't like to point to specific people but we've recently retired |
150 |
an ex-Forums project member who stopped contributing years ago |
151 |
but wanted to keep the status. |
152 |
|
153 |
> Here is a similar approach that would work for both: |
154 |
> * Once a developer has been inactive for x time (for example not having |
155 |
> voted on two consecutive council electiions), the developer is contacted |
156 |
> by undertakers and asked whether he/she/it is still interested in Gentoo |
157 |
> and has contributed soomething that went missing in this period. |
158 |
|
159 |
This opens a loophole for people who keep the developer status only to |
160 |
vote in elections. Do you consider it fair to give the same level of |
161 |
vote to people who spend many hours each week contributing to Gentoo, |
162 |
and people who don't contribute at all but only keep the status to have |
163 |
control over Gentoo? |
164 |
|
165 |
> Undertakers also give a deadline for a reply. |
166 |
> ** If the answer is afirmative and the developer sends some |
167 |
> contributions the undertakers close the issue. |
168 |
> ** If the answer is negative but the developer wants to continue |
169 |
> contributing, the undertaker can provide advice on how to do so and |
170 |
> extend the deadline a bit (after which the developer will be retired and |
171 |
> invited to take the tests). |
172 |
> ** If the answer is negative and the developer is okay with retiring, |
173 |
> retirement is done. |
174 |
> ** If no reply is obtained before the deadline, retirement is done. |
175 |
|
176 |
Well, let me just summarize the problem: it is really hard to 'measure' |
177 |
contributions. We don't want to make people who contribute in unusual |
178 |
ways to feel offended because Undertakers were not aware of this |
179 |
(and yes, we also had pretty offensive behavior from people who |
180 |
apparently were contributed in non-Undertaker visible ways). We don't |
181 |
want to create a huge catalog of possible contributions. In the end, we |
182 |
don't want to really end up judging quantities of contributions to |
183 |
distinguish between people actually contributing and 'trying to work |
184 |
around the mechanisms'. |
185 |
|
186 |
That said, what you're saying is pretty much the case. The main idea |
187 |
with project leads is that they say Undertakers how to determine |
188 |
the activity in specific areas in Gentoo. In fact, we could take this |
189 |
even further and say you don't have to be member of Forums, bug- |
190 |
wranglers etc. -- but leads of those projects may be asked to verify |
191 |
your contributions. |
192 |
|
193 |
> Turns out that this is, in a way, the process documented on the |
194 |
> Undertakers project itself: https://wiki.gentoo.org/wiki/Project:Undertakers |
195 |
> |
196 |
> > What is the problem you're trying to solve here? Are you just arguing |
197 |
> > for the sake of arguing? Or are you pursuing the concept of 'every |
198 |
> > developer obtains his developer status forever, until he agrees to |
199 |
> > retire'? |
200 |
> |
201 |
> I'm saying that: |
202 |
> * It is the responsability of the developers to provide signs of |
203 |
> activity if none was detected. |
204 |
> * It is usually a bad idea to forcefully retire an inactive developer as |
205 |
> that person may not come back once its life circumstances change. |
206 |
> |
207 |
|
208 |
This is really covered by Undertakers policy, and the GLEP explicitly |
209 |
says it doesn't cover it. |
210 |
|
211 |
-- |
212 |
Best regards, |
213 |
Michał Górny |