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 6933B1382C5 for ; Sat, 21 Apr 2018 17:22:01 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 476ACE0855; Sat, 21 Apr 2018 17:22:00 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 EBEE8E0848 for ; Sat, 21 Apr 2018 17:21:59 +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 1968A335C74 for ; Sat, 21 Apr 2018 17:21:57 +0000 (UTC) From: "Francisco Blas Izquierdo Riera (klondike)" Subject: Re: [gentoo-project] pre-GLEP: Gentoo Developer status To: Gentoo project list 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> <1523815089.1347.47.camel@gentoo.org> Message-ID: <939bd60f-021a-7733-6e4a-a16f38c1c876@gentoo.org> Date: Sat, 21 Apr 2018 19:21:05 +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: <1523815089.1347.47.camel@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1Ny1fMD3m0jPuxzpVknBmMToPThKkP4VQ" X-Archives-Salt: 175cdb21-d6ab-4ba5-a469-fd8eb72f57a8 X-Archives-Hash: 9d889dfd8fc0f819e02929f53e8e5513 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1Ny1fMD3m0jPuxzpVknBmMToPThKkP4VQ Content-Type: multipart/mixed; boundary="WliUU4ANfe2r2tt1RZ4Ci5W9JWO0ycyCe"; protected-headers="v1" From: "Francisco Blas Izquierdo Riera (klondike)" To: Gentoo project list Message-ID: <939bd60f-021a-7733-6e4a-a16f38c1c876@gentoo.org> 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> <1523815089.1347.47.camel@gentoo.org> In-Reply-To: <1523815089.1347.47.camel@gentoo.org> --WliUU4ANfe2r2tt1RZ4Ci5W9JWO0ycyCe 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 19:58, Micha=C5=82 G=C3=B3rny escribi=C3=B3: > W dniu nie, 15.04.2018 o godzinie 18=E2=88=B655=E2=80=89+0200, u=C5=BCy= tkownik Francisco Blas > Izquierdo Riera (klondike) napisa=C5=82: >> 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=BC= ytkownik 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 strongl= y >>>>>> disrecommend having more "informative" policies. >>>>>> >>>>>> Not to say that whether you like it or not, not all non ebuild rel= ated >>>>>> developer work is necessarily tied to a project. Even GLEP 39 ment= ions >>>>>> this: "Not everything (or everyone) needs a project." >>>>> If you have a good example of a developer contributing to Gentoo wi= thout >>>>> having commit access and without being tied to a project, I'm all e= ars. >>>> 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, s= ome >>> of them fall into scope of one or more project -- e.g. Forums project= or >>> 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: > Yes and no. We are not giving 'free commit access' to contributors.=20 > Unlike, say, Wiki edits, accepting ebuilds from users involves > significant work on an existing developer with commit access (proxy > maintainer). So it's not 'the same way'. You are misinterpreting the argument here and providing a straw man. Do all developers need "free commit access"? No. Do any developers need "free commit access"? No as long as they can proxy commits through other developers who have access to the parts of the tree that developer can't access in this hypothetical case. Is it helpful for some developer to have "free commit access"? Yes, a clear example maybe AT. The fact is that when a developer comments on a bug, bugzilla shows a dev mark. When a developer posts to a mailing list it uses a gentoo.org address. When a developer uses IRC it has a gentoo cloak. The only exception is the wiki and even that is something that maybe should be considered. Turns out all of these things help developers perform some of the above mentioned tasks in a more efficient way, just in the same way that giving full tree access does for some tree related tasks. >> * Being a developer makes new/changed documentation more turst worthy >> (and that can be particularly important in some cases=3D. > Given that our documentation is mostly hosted on Wiki, I'd like to poin= t > out that I seriously doubt that most of our users check page history to= > see who has written which part of the document. I should also point ou= t > that 'normally' Wikis are edited by everyone and their quality is > 'assured' not by access restrictions but by large number of reviewers > who correct articles. You go explain that to the Gentoo Hardened users, will you? In fact that was one of the reasons to have the Gentoo Hardened project pages protected on wiki migration, keeping the reliability of the doc. So whilst maybe not for you, we have a subset of users for which being able to go back to a version of the document verified by a developer provides a lot of value. > As a side note, I'm aware that some of the 'areas' of the wiki are > restricted to editing by developers. However, there is no real > agreement about it and there are people who strongly believe that > documentation should be kept open for user edits. > >> * Users are more likely to accept any input from a developer. >> * Users are more likely to follow directions by a developer. > This is somewhat correct. However, the truth is most of the users are > also more likely to accept input from someone who behaves like he were > a developer even though he isn't one. We have had a number of verbose > users on the mailing lists whose opinions were considered higher than > those of developers because they expressed them with a tone > of authority. Or maybe because of their history. The gentoo.org address is a hint at the existence of prior good contributions by somebody but is not the only one. Users are more likely to trust and hold higher opinion on those who have helped them in the past. > On the other hand, if you look through the Forums you'd notice how many= > users actually follow bad advises given by non-developers. For this argument to be valid you'll have to consider only the cases where bad advice was provided by a non-dev and good advice was provided by a dev within a reasonable amount of time. Mostly because if no good advise is provided by a developer or it is provided too late, the user will follow the bad advice as it was the only input that person got. >> 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 projec= t >> 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 th= e >> forums project to answer questions on the forums nor you need to be pa= rt >> of the OPS project to assist users over IRC. > To some degree, yes. However, the relevant projects still keep some > degree of power over the specific area. As you mention, you don't have= > to be part of bug-wranglers but you *need* to follow their rules. If > you start wrangling bugs against the rules set by bug-wranglers, we > aren't going to be happy about it. > > Plus, getting recruited involves someone confirming your skills > and mentoring you. If your intent is to help in any of those areas, it= > seems reasonable that someone *already working on them* should help you= > and vouch for you. Therefore, projects. At the beginning yes, but people change over time and so may do their contributions. Sunrise project is dead, X11 https://wiki.gentoo.org/wiki/Project:X11 doesn't list you as a member and these two where the projects that scarabeus mentioned in your developer recruitment bug. Like you a non ebuild developer may still be contributing to areas other than these in which it began its career and it may do so without even belonging to a project. >>>> All those are tasks making a very significant contribution to Gentoo= =2E >>>> All of those are tasks that don't require being a member of any proj= ect >>>> 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 activi= ty >>>> non ebuild developers do? After all GLEP39 clearly states too: " Ins= tead >>>> the practical responsibility of a lead is "whatever the members >>>> require", and if that isn't satisfied, the members can get a new lea= d >>>> (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. Wh= ile >>> people doing other tasks were called 'staffers' and therefore were no= t >>> 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 ki= nd >>> of project (e.g. Infra). The only reasonably tangible method were >>> querying the relevant projects to determine whether their members wer= e >>> 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 apparentl= y >>> 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 fro= m >> 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 a= re >> allowed to do so (I guess unless the council decides to reassign them)= =2E > The fact is, what you perceive as current practice is pretty much > the 'optimistic' solution. I don't think we really had many cases of > people who tried to abuse this to keep the developer status after reall= y > stopping to contribute to Gentoo, and I don't think we really consider > it urgent to 'kick' them. However, this doesn't mean that it wouldn't > happen if need so. > > I don't like to point to specific people but we've recently retired > an ex-Forums project member who stopped contributing years ago > but wanted to keep the status. So why don't just update the undertakers policy to account for such cases then? Anyways a developer who is not happy about its retirement is likely to ask council to address the issue. >> Here is a similar approach that would work for both: >> * Once a developer has been inactive for x time (for example not havin= g >> voted on two consecutive council electiions), the developer is contact= ed >> by undertakers and asked whether he/she/it is still interested in Gent= oo >> and has contributed soomething that went missing in this period. > This opens a loophole for people who keep the developer status only to > vote in elections. Do you consider it fair to give the same level of > vote to people who spend many hours each week contributing to Gentoo, > and people who don't contribute at all but only keep the status to have= > control over Gentoo? No, but somebody who hasn't voted in elections for say two years is probably inactive (or not interested), that is why the clause is "for example" and not "only and only if". That said, I'm going to give you a different question: "Do you consider it fair to give the same level of vote to people who spend many hours each week contributing to Gentoo without keeping up with any policy changes unless pointed to making other people lose time as to people who make small contributions now and then but actively keep themselves up to date so that these have high value and require little or no work from others?" >> 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 a= nd >> 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. > Well, let me just summarize the problem: it is really hard to 'measure'= > contributions. We don't want to make people who contribute in unusual > ways to feel offended because Undertakers were not aware of this > (and yes, we also had pretty offensive behavior from people who > apparently were contributed in non-Undertaker visible ways). We don't > want to create a huge catalog of possible contributions. In the end, w= e > don't want to really end up judging quantities of contributions to > distinguish between people actually contributing and 'trying to work > around the mechanisms'. > > That said, what you're saying is pretty much the case. The main idea > with project leads is that they say Undertakers how to determine > the activity in specific areas in Gentoo. In fact, we could take this > even further and say you don't have to be member of Forums, bug- > wranglers etc. -- but leads of those projects may be asked to verify > your contributions. The point you are missing is that project leads may not be aware of a specific developer's contributions, but a developer is expected to, at least, know which its most significant ones were. Also I'm not expecting undertakers to measure contributions, just to reason if they are positive for the project in some way. In general it's an awful idea to retire anybody who has even a small positive impact on Gentoo because then you are likely to go from small positive impact to no impact at all. >> Turns out that this is, in a way, the process documented on the >> Undertakers project itself: https://wiki.gentoo.org/wiki/Project:Under= takers >> >>> What is the problem you're trying to solve here? Are you just arguin= g >>> 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. >> > This is really covered by Undertakers policy, and the GLEP explicitly > says it doesn't cover it. Where? In the "However, there seems to be no single document binding all of them together. This GLEP aims to be precisely that." Because that pretty much sounds as "This document replaces said policies by bringing them together" to me.=C2=A0 To prove my point here is a different definition: A *Gentoo Developer* is a person who has successfully passed the recruitment procedure (as defined at the time of his/her joining) and is making positive contributions to Gentoo Linux project in some way. Simple, straightforward and keeps every developer under the same standards in particular "making positive contributions to Gentoo Linux project in some way". Klondike PS: Sending this also to gentoo-project as I didn't add the address befor= e. --WliUU4ANfe2r2tt1RZ4Ci5W9JWO0ycyCe-- --1Ny1fMD3m0jPuxzpVknBmMToPThKkP4VQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJIBAEBCgAyFiEEDaSLWSPwfVgqfnPQ9L3S7+j/ePkFAlrbcwEUHGtsb25kaWtl QGdlbnRvby5vcmcACgkQ9L3S7+j/ePl8hxAAqfTE45dpozRtJptKsSqz0hTb1TwE qp83ShjpwgwJZQe4uAAPxfU/hq33cd+n1v96a7nvDYD/x4+3TfE0oyfZyyIq/3J5 IjMYji6jwmIBe7OAF/MYfyqFsvhVN7AovuFA+CnCPKnkUMK3RJTfyL57ZJR8AfJW QbJ19AwHuVG5yOxoppVVlE/bNO0SaJDpRULi5pv6lxylvewtK7QoOA8r/VadCpen AnySpfZSSnQKV4S+7PWrRgvTcx/WstXQx7hRF7bIjV1gk/eAqunQRGkugm9duNdf RhbADB6m1vmnNcWpV5rFM0oyOZKtAqbzkUQIi83ilFkC28vOKq7Z1AwOH8o9RbHr 0/efuLD6+LfU0T4IiPGY+rd2BKYPWuhRrh7gzTK4kFztkSuxZmbCl16Sq9BBwbLK /bIjRLMLXqqDq0Yvc8a9gE90uFoShpUxihYd0UPm1BRlf50auN6jfL3Rmpwf3Mc4 BqoV8hgdnemYPQBYelkfHIDImSAZLniMcaYebdjBECntBtZntxOgIEDdpjIhi6UZ q1v3xaA/SrJuIwg+f6lSHPH13H6qbMPaZPrQhdCP15jyBoOEprbrwuY2hHMwHB+F fdh5rejIVPz7OSaQgLd0epT1HhQnxHeK6w8dnWI8zAUaC2ULssUDcoI212UCodxn owvPwPu4auyNtVU= =wXtH -----END PGP SIGNATURE----- --1Ny1fMD3m0jPuxzpVknBmMToPThKkP4VQ--