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 7741B138330 for ; Fri, 7 Oct 2016 12:23:08 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7373821C075; Fri, 7 Oct 2016 12:23:01 +0000 (UTC) Received: from mail-pf0-f181.google.com (mail-pf0-f181.google.com [209.85.192.181]) (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 402CA21C054 for ; Fri, 7 Oct 2016 12:23:01 +0000 (UTC) Received: by mail-pf0-f181.google.com with SMTP id i85so22984405pfa.3 for ; Fri, 07 Oct 2016 05:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:subject:to:cc:message-id:in-reply-to:references :mime-version; bh=GP6lfFKXxRNJ5FkgNGkNKfLv7iieod1ooNRjnUQe03Q=; b=yexs3xyiK1yRZ2jGv1EeX7r9FIPfNijYHcKRa/K4+vsq3NwWkuPm9F80w0REQRLDAO yxiJppkLrDTFR2ia2NhbA3OyA20q0MlS2mFG+XsiXGueDEvYrMUnS/7ZYsR2tkXkcukn fg4CRjSE6i/ITUYF2E7ju6BW4Ir8u6sKzxKdDhusNxx5ZMkWKFUyqaxGj8CgU0253Bj1 lQJY2EgFh1jBKLCAlO/hea6RKGjPYQqjxt1C/Asz0zUuWb0KgM6yutg6jF7mz7ddl+zI qQFLbvxzFEXXglP0LaIgKQ71tkTvqL0y7ljIt++1c3rfHmJeIkw/meQPOk4EW3lEwevP BFvA== 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:cc:message-id:in-reply-to :references:mime-version; bh=GP6lfFKXxRNJ5FkgNGkNKfLv7iieod1ooNRjnUQe03Q=; b=cxig8W9gfvu82NyYFJCCpegJTRzjDU90yZ8k/2a6AH+b6hfAhoM3vyQfrN7aorUTDr 0pX5IKK5tt7MZLAsw52zEGK38m+uyLXgwGOYOEUgK13+XHiZNvmbW0Qtm1tHy0NpuixE VHNRdGaSDQeglrErGmcfinB+h+J4TwPogyAZ8SaoaJ3DUUyinD6/RgQ3i7McIy8XrW6a V7iBmC8Ohp+5VaQRlLRZV+z9kB8SZY3v9m9qQW38uOUMv6BR3LoNJk/HjP9UTbm+ILmP 3TjDtrWTwoqBOXAyzwVZ4pck/GOHqxqCTfRyBzfO8azCNSCFPOqljsI+pckD90ohXRUb vFRQ== X-Gm-Message-State: AA6/9RlhEH5kA6V71RfQ1gXpmpWw14FBliQTJ5GO9lSMNZxWQO6dVG+4zbhH5gMhloEy+Q== X-Received: by 10.98.35.84 with SMTP id j81mr26918600pfj.166.1475842979815; Fri, 07 Oct 2016 05:22:59 -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 c15sm13649630pfl.88.2016.10.07.05.22.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Oct 2016 05:22:58 -0700 (PDT) Date: Fri, 07 Oct 2016 05:22:56 -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 Cc: NP-Hardass Message-Id: <1475842976.4388.0@smtp.gmail.com> In-Reply-To: References: <832d6b86-ee0e-4509-7f74-1e19fd4e4db9@gentoo.org> <46323553-e9c0-8d52-3c2a-a75b0245c7ce@gentoo.org> 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: bda46f01-f78d-47e3-851e-f10245df69fd X-Archives-Hash: 078dedd85f08a4887ddcaa8792e510b0 On Fri, Oct 7, 2016 at 4:58 AM, Rich Freeman wrote: > On Fri, Oct 7, 2016 at 12:57 AM, NP-Hardass > wrote: >> >> Well, what is the purpose of an appeal? >> Presumably, it is twofold: 1) that the procedures that lead up to >> the >> initial decision were just and appropriate, 2) that the logic that >> lead >> to the initial decision was valid and correct. >> > > It seems far more important to me that the purpose is to confirm > whether the underlying complaint is valid, and whether the action > taken by Comrel was appropriate. If the procedures/logic were flawed > that seems more like a refinement. > > 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. No, don't let the developer back in immediately, but do make sure that comrel gets a deadline to fix the paperwork if they want to keep the dev booted. 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. > 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. IMHO, they should be held responsible for their commits and bear the burden of correction so that they have an incentive not to screw up again...but we should also be ready to lend them a hand if they need it. Soap did this helpfully for me during a recent pmaint pull. I appreciated his ample help with the autotools stuff, and the only thing I resented was that he "messed up the paperwork" and I had to get my autotool lesson in a bit of a roundabout way. > We don't arbitrarily > revert the commit without thinking about the pros and cons of doing > this vs fixing the problem in some other way. Sometimes a reversion > is appropriate solution, but sometimes the right solution is to move > things forward to a better state. > Ultimately we need to be concerned > with the user experience. In my opinion, I think that whether the mistake constitutes a regression should be a strong factor in whether we revert or just press forward with fixes. Breaking something that worked before is a no-no. > In the same way we need to be concerned with the community experience. > Sometimes overturning a comrel decision might be the right move, but > sometimes it might just need a nudge in the right direction, or no > change at all as far as the outcome goes, even if something went wrong > along the way. Doing otherwise just leads to lawyering where we argue > over the process completely ignoring the reason why Comrel is > necessary in the first place. > >> The likelihood of a ComRel member changing their mind at the Council >> appeal stage should be minimal, and their decision is most likely >> against an individual at this point. This means that the votes in >> an >> appeal are already stacked against an individual if a Council >> member is >> a ComRel member. > > That makes sense. I think this may well be part of why the wiki history I cited earlier was written the way it was. >> Recusing oneself reduces an initial bias against an >> individual. > > I don't see this as bias, though bias has many definitions. Typically > bias implies some kind of unfairness. A fully-informed decision isn't > bias. > >> Hopefully it should be more clear as to why recusal or independence >> is >> being promoted as superior to the alternative. It promotes >> imparitality, something you'd hope for in an appeal. "Conflict of >> Interest" probably wasn't the proper terminology to use earlier. >> "Impartiality" is. > > Having previously heard a case doesn't mean that somebody isn't > treating all sides of the case equally, which is what partiality is. > > Note that most court systems do not generally strive for independence > between court levels. Usually lower courts are completely subject to > the higher ones. This makes sense when you consider how appeals work. > Imagine if a lower court and a higher court were completely in > disagreement. Anybody who the higher court felt was guilty was set > free by the lower court, and anybody the higher court felt was > innocent was declared guilty by the lower court. This would result in > a system where the lower court is a meaningless exercise in process, > because every single decision would be overturned. You want the lower > court to follow the direction of the higher court, so that the > majority of decisions are never appealed in the first place, and most > appeals fail. Yes, in my opinion, courts of appeal exist to serve as supervisors of lower courts. However, there should not be the assumption that the lower court should feel free to "um...I'll do the best I can but if the appeals court is watching my back I don't have to worry about screwing up". In the real world, lower courts are given WIDE deference on "issues of fact" once a jury or a judge has interpreted the evidence or testimony. it is VERY hard to make an appeal based on a factual issue. And on a side note, there are PLENTY of horror stories on slashdot about how the tango between trial court and appeals court winds up with each of them dumping responsibility on the other one, causing a circle of musical chairs where they BOTH drop the ball. Don't get me started on the USPTO and prior art. 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. > 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. > That is a system biased > against action because there are two opportunities to stop action, but > only one opportunity to take action. If Comrel simply ignored every > case or dismissed them all, they wouldn't be subject to any oversight > at all under the present system. > > In an ideal world I'd certainly prefer to see more fresh blood in > Comrel, but this is an area we need to be careful about. I'm less > keen on having Comrel entirely elected unless we fix the issue with > not being able to appeal inaction, because this essentially means we > have two different independent bodies steering CoC enforcement in > different directions. What if the comrel lead was elected by the council and not by the comrel members? Comrel is a special case, due to its power to remove developers, and I think it should therefore be accountable to the global community, and not just to its own members. TLDR: I don't think comrel should be treated as a standard project. > If people are upset about the independence of > Council and Trustees then adding more independent governing bodies > that aren't entirely subordinate seems like a step in the wrong > direction. Most organizations try to have just one body ultimately in > charge with delegation down from there. > > -- > Rich >