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 A759D138330 for ; Fri, 7 Oct 2016 14:05:39 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 36B1EE0C1A; Fri, 7 Oct 2016 14:05:37 +0000 (UTC) Received: from mail-pf0-f172.google.com (mail-pf0-f172.google.com [209.85.192.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0550EE0C19 for ; Fri, 7 Oct 2016 14:05:36 +0000 (UTC) Received: by mail-pf0-f172.google.com with SMTP id 190so24219133pfv.0 for ; Fri, 07 Oct 2016 07:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:subject:to:message-id:in-reply-to:references:mime-version; bh=RVM0f7vGA+ixkurwgNCxaffR9RgUt2UXihK7GxfzIp4=; b=GIKyVZoQSXBDjHaXNpvxWMtWewCxXbXeqWHLi8QptN1T9TLtezNG4QxcDPgEkU3GUl KE2ZmpYeYeImSwMpZK8151sAJugPHWmlomj81/XigV/84TggU++FI+b1VeWGn2Cud1+7 Yc+C1YPTiTFcWC/GZioI3LWWCImCr8TZpEwjjafghGGFTHaQi0l8zVNSAoPxSZzd15rX wTK69jxF2VFseOJ4NkR0W9Dyl51Ex9eMPWmGvhkggKQKxMjCEJM0nxNhpCH5JHuNUPEr mlsn1YlyuFD0HbD9VSn3/FWjvelUl1jY+1P9orlD8x4XS6nqCt1XyakxiJ5Ils4oKaIC U6Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:subject:to:message-id:in-reply-to :references:mime-version; bh=RVM0f7vGA+ixkurwgNCxaffR9RgUt2UXihK7GxfzIp4=; b=ldA13lGHa17fl3rDk3Xck0xUq8cMj0iEjKE5vN2T6c87JP/inWNmgyYoH61YxDEGZd 9q8Ey6spOUI/TeXB9VhOPsHw7NLFcjUkqG3sAzsUJBp5AGyTspFRgPSx+DGGCAmXD8cl D/j641LCpFG63JxSRwvKrsQI0F1SrRx3iq+RcXtvDn37mSBZdIh5PC3DsNdDfv8Igrrp fybqgqUeGbT3LeaL9kl0QYorzGenyxu5FrVsPHxfx1j2E0OwYbQDvlvg2/mJ5g7pwoTG eZRQrPti+/Cwf+QaFJDIvpUclVqRPWCLKmWaU64qwYrTghPZJw1la/F1EVOPGTzUn/Yk +Q1g== X-Gm-Message-State: AA6/9RlGBZootgYkS8N8STUs//ZOGoldptcM2klZ+aX2OoMksal93nn9KOYAxBlqsORN+Q== X-Received: by 10.98.90.133 with SMTP id o127mr27576357pfb.61.1475849135367; Fri, 07 Oct 2016 07:05:35 -0700 (PDT) Received: from [10.0.0.3] (66-191-43-18.static.snfr.nc.charter.com. [66.191.43.18]) by smtp.gmail.com with ESMTPSA id wa9sm31420860pac.35.2016.10.07.07.05.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Oct 2016 07:05:33 -0700 (PDT) Date: Fri, 07 Oct 2016 07:05:32 -0700 From: Raymond Jennings Subject: Re: [gentoo-project] Re: Trying to become a Gentoo Developer again spanning 8 years... To: gentoo-project@lists.gentoo.org Message-Id: <1475849132.4388.1@smtp.gmail.com> In-Reply-To: References: <832d6b86-ee0e-4509-7f74-1e19fd4e4db9@gentoo.org> <46323553-e9c0-8d52-3c2a-a75b0245c7ce@gentoo.org> <1475842976.4388.0@smtp.gmail.com> X-Mailer: geary/0.11.1 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 Content-Type: text/plain; charset=utf-8; format=flowed X-Archives-Salt: e02cfd64-9d8a-427b-a008-ea23c2fa4003 X-Archives-Hash: 282d94206d8b0c67ab0cd740b8a13bfe On Fri, Oct 7, 2016 at 5:45 AM, Rich Freeman wrote: > On Fri, Oct 7, 2016 at 8:22 AM, Raymond Jennings > wrote: >> On Fri, Oct 7, 2016 at 4:58 AM, Rich Freeman >> wrote: >>> >>> If somebody was harassing somebody else, and Comrel boots them, >>> and it >>> turns out that they didn't file some information correctly, is it >>> better to let the booted dev back in and tell Comrel to boot them >>> again correctly this time? >> >> >> In my opinion, sorta >> >> Appropriate procedure IMHO is: >> >> 1. Make comrel redo the "paperwork" properly >> 2. Give comrel a deadline of 7 days to do so >> 3. If the new "paperwork" supports the booting, leave them booted >> 4. Otherwise, let the dev back in provisionally until they can be >> booted >> correctly. >> 4.a It is probably implicit that the developer in question will be >> on >> implied probation. >> >> Letting a bad developer back in is bad for gentoo, but if they >> really are >> provably bad then it should be easy for comrel to fix the >> paperwork. If >> they can't fix it in a timely manner, that's a sign that their >> original case >> was messed up to begin with. > > Or maybe it is just a sign that Comrel is overworked, or doesn't put a > lot of priority on such things? My opinion is that if a developer is bad enough to keep out, its also important enough to get the paperwork fixed to prove it. If they have a clean case it *should* be very easy to get the paperwork right. >> My main concern is making sure that a bad developer stays >> booted...but also >> making sure comrel can prove they're bad. Letting the bad paperwork >> stagnate in limbo is bad for everyone. > > Sure, but so is letting the bad dev back in. Basically we're > punishing the community because of a failure to go through due > process. But its the "due process" here that proves the developer is bad to begin with. If comrel screwed up and there was a mistake and the developer is actually meritorious, its bad for gentoo to keep them out. >>> When somebody doesn't commit a package properly we tell them not >>> to do >>> it again, and we make any appropriate fixes. >> >> I'd prefer to make them fix it themselves, or at least ask for their >> permission to do it for them. > > That really depends. If the tree is broken, it is against everybody's > interests to just leave it that way until the original dev checks > their email/irc/etc. If the problem is minor, sure, let it wait. > However, for a serious problem we might not have that luxury. Agreed, and I was citing regressions as one such "serious problem" There are special cases, yes. >> In my opinion, a trial court should be held responsible to do the >> best job >> it possibly can. An appeals court should be held responsible to >> review the >> cases it gets to the best of its ability. BOTH should treat their >> responsibilities with utmost care and should assume that any >> mistake they >> make is NOT going to be caught. > > No argument. But at the same time if Comrel currently has a backlog > of cases they aren't dealing with then there is a cost to increasing > the level of rigor. What is the cost of *not* increasing the rigor? Honestly, I see removing a good developer by mistake as a social version of a regression-type bug. > That was one thing we didn't get a measure of. > How many cases are brought to Comrel and not seriously evaluated due > to lack of time? Maybe comrel should adopt the same sort of "triage" procedures that ubuntu uses to classify bugs? I think every comrel petition should be kept on record, and then we have a class-based priority for which ones get solved first. Comrel stays as busy as it wants to, and it deals with the most important issues first. A toxic asshole who is sabotaging the community and can do a lot of damage if not removed, would probably be a high priority case, for example. If nothing else, the number of "lower priority" cases left dangling in "backlog" could be a useful statistic. Also, I just realized that the "everyone votes" blocks comrel manpower from scaling. What if each member of comrel was granted the discretion to handle everything as they themselves saw fit, subject to the provision that the comrel lead/comrel as a group/the council could receive appeals? Judge Dredds all on a squad, but all of them watched by higher powers ot make sure they do the best they can and can have their badges guided or if necessary yanked if they screw up a decision. >>> That actually brings up a separate issue with how Comrel operates. >>> Right now the most common interpretation of the code of conduct >>> says >>> that the only person who can appeal a Comrel decision is somebody >>> being punished by Comrel. If dev A complains to Comrel about dev B >>> doing something wrong, and Comrel decides to take no action against >>> dev B, dev A has no recourse for appeal. >> >> I think that dev A should have recourse for appeal...especially if >> they or >> their gentoo work was hampered by dev B's actions. >> >> But I should emphasize that dev A should have a valid basis for the >> appeal, >> and it should be important enough that its worth the time of dev A >> taking >> the time ot make the appeal instead of fixing it himself. > > Well, any dev should have a valid basis of appeal. Right now we have > few Comrel decisions in the first place, let alone appeals. However, > I'm aware of one appeal on the basis of Comrel inaction. I don't > think it is harmful to say that in that case the Council didn't feel > Comrel had reached a point yet where escalation was necessary. > However, that does create a bit of a challenge because Council doesn't > really want to deal with the entire backlog of Comrel cases if Comrel > isn't able to keep up. See earlier point about letting individual comrel members having discretion to handle things on the spot Judge Dredd style...so long as they are supervised by someone who can evaluate their performance and if necessary intervene. > Imagine if stale stablereqs could be appealed > to Council... :) Maybe not stale stablereqs themselves. This is a volunteer project with finite manpower. However, someone deliberately *ignoring* a stablereq when there's a large need for it MIGHT be more worthy of an escalation. But merely being overworked should not be an offense, and it would probably go through comrel first. > -- > Rich >