Gentoo Archives: gentoo-project

From: "Francisco Blas Izquierdo Riera (klondike)" <klondike@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] pre-GLEP: Gentoo Developer status
Date: Sun, 15 Apr 2018 16:56:28
Message-Id: dca9cb80-5ed1-b550-7826-92d5d4a30e88@gentoo.org
In Reply to: Re: [gentoo-project] pre-GLEP: Gentoo Developer status by "Michał Górny"
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.

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-project] pre-GLEP: Gentoo Developer status "M. J. Everitt" <m.j.everitt@×××.org>
Re: [gentoo-project] pre-GLEP: Gentoo Developer status "Michał Górny" <mgorny@g.o>