From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 98BC01382C5 for ; Sun, 15 Apr 2018 16:56:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A78BAE086F; Sun, 15 Apr 2018 16:56:27 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 61269E0869 for ; Sun, 15 Apr 2018 16:56:27 +0000 (UTC) Received: from [192.168.1.215] (unknown [80.216.63.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: klondike) by smtp.gentoo.org (Postfix) with ESMTPSA id 289A6335C51 for ; Sun, 15 Apr 2018 16:56:25 +0000 (UTC) From: "Francisco Blas Izquierdo Riera (klondike)" Subject: Re: [gentoo-project] pre-GLEP: Gentoo Developer status To: gentoo-project@lists.gentoo.org References: <1523640697.5139.2.camel@gentoo.org> <1523690669.1482.5.camel@gentoo.org> <6b94d416-5521-2719-30db-993babefd04c@gentoo.org> <1523794944.1347.18.camel@gentoo.org> Message-ID: Date: Sun, 15 Apr 2018 18:55:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <1523794944.1347.18.camel@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vnSfHu0orIXOfg4kPvhE6ks4D7z7JGmjA" X-Archives-Salt: 7696b908-7e78-4909-974e-33ed839e4fed X-Archives-Hash: 5c03121eb5f0a83e32803ec457e49e05 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vnSfHu0orIXOfg4kPvhE6ks4D7z7JGmjA Content-Type: multipart/mixed; boundary="kESucVeatPZEvQ5LlwB9UhiTh9TB5PGUg"; protected-headers="v1" From: "Francisco Blas Izquierdo Riera (klondike)" To: gentoo-project@lists.gentoo.org Message-ID: Subject: Re: [gentoo-project] pre-GLEP: Gentoo Developer status References: <1523640697.5139.2.camel@gentoo.org> <1523690669.1482.5.camel@gentoo.org> <6b94d416-5521-2719-30db-993babefd04c@gentoo.org> <1523794944.1347.18.camel@gentoo.org> In-Reply-To: <1523794944.1347.18.camel@gentoo.org> --kESucVeatPZEvQ5LlwB9UhiTh9TB5PGUg Content-Type: text/plain; charset=utf-8 Content-Language: sv-FI Content-Transfer-Encoding: quoted-printable Hi Micha=C5=82! El 15/04/18 a las 14:22, Micha=C5=82 G=C3=B3rny escribi=C3=B3: > W dniu nie, 15.04.2018 o godzinie 13=E2=88=B644=E2=80=89+0200, u=C5=BCy= tkownik Francisco Blas > Izquierdo Riera (klondike) napisa=C5=82: >> Hi Micha=C5=82! >> >> El 14/04/18 a las 09:24, Micha=C5=82 G=C3=B3rny escribi=C3=B3: >>> W dniu pi=C4=85, 13.04.2018 o godzinie 23=E2=88=B628=E2=80=89+0200, u= =C5=BCytkownik Francisco Blas >>> Izquierdo Riera (klondike) napisa=C5=82: >>>> Hi Micha=C5=82, >>>> >>>> Taking into account that the letter and not the spirit of GLEP 39 is= >>>> usually thrown around as a weapon ("INFORMATIVE", HAH!). I strongly >>>> disrecommend having more "informative" policies. >>>> >>>> Not to say that whether you like it or not, not all non ebuild relat= ed >>>> developer work is necessarily tied to a project. Even GLEP 39 mentio= ns >>>> this: "Not everything (or everyone) needs a project." >>> If you have a good example of a developer contributing to Gentoo with= out >>> having commit access and without being tied to a project, I'm all ear= s. >> Here are some randomly picked tasks that don't require belonguing to a= >> project: >> * Keeping the documentation on the wiki up to date and clear. >> * Writting new, relevant documentation. >> * Helping address users concerns over one of our official channels >> (forums, gentoo-user mailing list, IRC, etc.). >> * Helping users provide relevant information on bug reports. > Which of those tasks strictly require developer status? That said, som= e > of them fall into scope of one or more project -- e.g. Forums project o= r > Bug Wranglers project. None of them. In the same way it is not needed to be a developer to contribute ebuilds. But there is this thing called motivation and approval by their peers that tends to motivate most volunteers when there is no other incentives. Also: * Being a developer makes new/changed documentation more turst worthy (and that can be particularly important in some cases=3D. * Users are more likely to accept any input from a developer. * Users are more likely to follow directions by a developer. All of them things not "strictly" needed but particularly helpful for the cases I propose. Also keep in mind that the fact there is a project covering some of those cases doesn't mean that the specific developer is willing or needs to be part of it. You don't need to be part of bug wranglers to help with bug management. You don't need to be part of the forums project to answer questions on the forums nor you need to be part of the OPS project to assist users over IRC. >> All those are tasks making a very significant contribution to Gentoo. >> All of those are tasks that don't require being a member of any projec= t >> to be performed, just having the relevant experience and skills. >> So here is my proof. Where is yours? >> >> Also why have to be the project leads the one determining the activity= >> non ebuild developers do? After all GLEP39 clearly states too: " Inste= ad >> the practical responsibility of a lead is "whatever the members >> require", and if that isn't satisfied, the members can get a new lead >> (if they can find somebody to take the job!)." Which doesn't names >> "determining the activity non ebuild developers do". Or maybe could it= >> be that you are planning to force project leads to define those >> activites in which case you should modify ALSO GLEP 39. > First of all, I should point out to you that 'GLEP 39' was created at > the time when 'developers' were only people having commit access. Whil= e > people doing other tasks were called 'staffers' and therefore were not > covered by GLEP 39. Is reducing their privileges what you're really > pursuing? No, I'm pursuing that they are treated in the same way a developer is! > That said, all I'm doing here is noting down the current Undertaker > policies. The classification into two groups determines the two main > methods of checking developer's activity. In case of developers with > repo/gentoo.git commit access, it is easy. In case of the remaining > developers, this is much harder. > > I think that so far the largest group of non-commit-access developers > were Forum project members. Others were also contributing to some kind= > of project (e.g. Infra). The only reasonably tangible method were > querying the relevant projects to determine whether their members were > active and to establish a good way of measuring one's activity. > > Of course, if you insist we could just say that Undertakers determine > the activity at their own accord, and retire people who are apparently > inactive without consulting the project leads. However, that seems > inferior to the current practice. This is not what I'm saying. In fact current practice is different from what you purvey: * Ebuild developers are usually asked about reassignment: see https://bugs.gentoo.org/show_bug.cgi?id=3Dvapier or https://bugs.gentoo.org/show_bug.cgi?id=3Dhwoarang * If they state they are interested in maintaining the packages they are allowed to do so (I guess unless the council decides to reassign them). Here is a similar approach that would work for both: * Once a developer has been inactive for x time (for example not having voted on two consecutive council electiions), the developer is contacted by undertakers and asked whether he/she/it is still interested in Gentoo and has contributed soomething that went missing in this period. Undertakers also give a deadline for a reply. ** If the answer is afirmative and the developer sends some contributions the undertakers close the issue. ** If the answer is negative but the developer wants to continue contributing, the undertaker can provide advice on how to do so and extend the deadline a bit (after which the developer will be retired and invited to take the tests). ** If the answer is negative and the developer is okay with retiring, retirement is done. ** If no reply is obtained before the deadline, retirement is done. Turns out that this is, in a way, the process documented on the Undertakers project itself: https://wiki.gentoo.org/wiki/Project:Undertak= ers > What is the problem you're trying to solve here? Are you just arguing > for the sake of arguing? Or are you pursuing the concept of 'every > developer obtains his developer status forever, until he agrees to > retire'? I'm saying that: * It is the responsability of the developers to provide signs of activity if none was detected. * It is usually a bad idea to forcefully retire an inactive developer as that person may not come back once its life circumstances change. --kESucVeatPZEvQ5LlwB9UhiTh9TB5PGUg-- --vnSfHu0orIXOfg4kPvhE6ks4D7z7JGmjA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJIBAEBCgAyFiEEDaSLWSPwfVgqfnPQ9L3S7+j/ePkFAlrThBMUHGtsb25kaWtl QGdlbnRvby5vcmcACgkQ9L3S7+j/ePnF5A//ZqkhDsOmqjWpvs4KjYuRHZsCe2Sz g3zeGVJgfE5DoOJdzQDYGW6P+K7bEQ+d1S7g9xyQE2fB09FfbN3SI/xphGefYnoR Lrq3ewkGdW/0Hh9A3KnKQFtUtGHARAeoZO50ypKHFf/JrjwJT9yS+vtOvl+jTsbm gYaVpxK05BK4AnVGdXbwqEc8QnrMRXK9oJYGrVlEz5oGiff5cn7M/ytNRmTk0eh1 sFhpuatK77WRHmCOWIPlwKXUmQVe5S9mEjM6UIYLTuzRUxq6l52smEMoVS6r/kKt lWuqS5UyswM04b8hgW38c29YXDBFWMWU/EIcd0c76+BB1fKKbAgs4IvvMdOpBH6S yktWdirdQApVkVipAA7fCyP4xG/iFfZ62bkWHdZGXjZrh9EZKU5O/Z8fA/5sqMT1 9NGHiIuqe3rtEloJ1Mm2WqbZ35BxJi5f0ofxE49xaETTIw+zlWAtrctUbVSjuJDS vmjRSedSTp+KJ3pZt0Vd+HE3BRFLck7mE3GdzrjfcWucNB1VaRS2xeZQOLk3XgY9 UKHLO+mQ8s+jVgyKvpSFt74dg/v6MN6wQuYjPe9MtfvuEx8J5RdJKv9w5QRfFIGo b6bN+jwMYLwMPTeNXBfDBMa3gxnvYPhBEQ+0lXcRcnCfsKfgzuNdzRHXopjX3twU ZngqwyI4i56AySM= =YJYs -----END PGP SIGNATURE----- --vnSfHu0orIXOfg4kPvhE6ks4D7z7JGmjA--