From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id D511D1392EF for ; Fri, 4 Jul 2014 16:12:12 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4221EE082B; Fri, 4 Jul 2014 16:12:11 +0000 (UTC) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 975BEE0829 for ; Fri, 4 Jul 2014 16:12:10 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id ij19so1739067vcb.22 for ; Fri, 04 Jul 2014 09:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=ffYabloNeDTbEVf/wSFqzwN5TbwEtLmt1SxsdPub3c4=; b=cV/Eof0V/iu/VSyTxk8cV7mR4W/ueUy1mVWZvFkBVnKnM+VuHb/wg0VjwkHOcaykf6 /d1X6zxxBMAL/NPQEfU8OiuMmXpZXb0e1SGug5+L2a5Ao2N7KROCSlDmO4GP94UVXXxf u6Lhy+fprm2asVFDKzQvocrOGg90wI1C+RUPTit8KxRsFm2L3Ct6QSPJm6CGAfUyS9lu AWRbVHp0+/LUOS/BeGdW/t9omNfyRO0XE6+RZR6fllkEeOwtsWVhpQyHCh1E/VjEZcIH fNmvjWnQkR8MzqtYgSN2ranqqAJYxrBs6IzWl8wkVKaQK0QPWnPJKvWWq+BTmC34EOu4 TbqQ== 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 X-Received: by 10.58.219.194 with SMTP id pq2mr29534vec.71.1404490329373; Fri, 04 Jul 2014 09:12:09 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.72.19 with HTTP; Fri, 4 Jul 2014 09:12:09 -0700 (PDT) In-Reply-To: References: <539BD2E2.7030803@gentoo.org> <3677509.vVmt2iqRkA@kailua> <53B53E12.10209@opensource.dyc.edu> <1827087.o57vyRvkxh@kailua> <53B58E33.5010906@gentoo.org> <53B6834C.5050003@gentoo.org> Date: Fri, 4 Jul 2014 12:12:09 -0400 X-Google-Sender-Auth: QX8tTFQUY4nH2QPDqZlKVnpZjUs Message-ID: Subject: Re: [gentoo-project] Gentoo Council 2014 / 2015 election From: Rich Freeman To: gentoo-project@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 91924f72-c204-4480-881f-b99652fa5e85 X-Archives-Hash: d3101b1ec089abe7fc01cbf971b4b27c On Fri, Jul 4, 2014 at 10:39 AM, Jorge Manuel B. S. Vicetto wrote: > On Fri, 4 Jul 2014, Rich Freeman wrote: >> 1. Announced elections, membership changes, etc. When these things >> happen, publish it on -project, or at least on the team page. Make it >> easy for everybody to see what is going on with the >> membership/leadership of ComRel. There is no need for the annual lead >> election to be secret. > > > If you mean the ballots should be public, I disagree... > If you mean that the result of an election should be public, I agree. We're on the same page here. > I agree with you that changes to policies should be discussed in the mls. We > did that a few years ago. We definitely need to publish the resulting policy > so everyone is aware of it. Again, we're actually on the same page here. I wasn't suggesting a free-for-all with conflict resolution. > >> 3. This is a bigger change, but I'd advocate doing with ComRel what >> was done last year with QA. Have the team self-governing for the most >> part, but with the Council having to confirm the lead and basically >> having the effective ability to take over if necessary. I'd highly >> discourage the Council ever doing that, but I'd look at it a bit like >> being able to Impeach or Recall an elected official - just a way to >> have accountability and the mandate that goes along with that. > > > I strongly object to this idea, just like I did with QA. > The goal / purpose of ComRel is not to be "cozy" team that everyone feels > great with. To have an effective ComRel team, it needs to be made of people > with certain traits (level headed, fair, independent, trustworthy) that do > their work with the best interest of Gentoo "at heart". That's why it can't > be a "open to everyone" team. > Besides, the council can always revert ComRel decisions and it always had > the power to deal with a "rotten" ComRel or ComRel lead. I'm not actually sure we're disagreeing here. This isn't about the Council picking the members of QA or ComRel. This is about having both teams govern themselves, but submitting their choice of leads to the Council to be blessed. I just view it as a way of "legitimizing" the teams, and making the elected Council members accountable for their actions. I was not proposing having open elections for these teams, or open membership as with most Gentoo teams. > > Even though I agree that there's a more visible QA team now, I don't > necessarily agree that we're better now. I hope and expect the new team will > get better with time, but they've been dragged into many and noisy > conflicts, which have even lead to complaints to ComRel. So, I can't say that I've agreed with how every issue has been handled, but it is a new team and I believe that creffet has been working hard to try to get the team to find the right balance between inactivity and overactivity. Of course a QA team that actually does things will trigger more ComRel complaints than one that does nothing - that's just the nature of the beast. The last month or two seems to have been fairly quiet judging from the lists and Council agendas. > Your setting of a precedent also worries me as a way for any particular new > council to decide it's time to replace QA, just because the 2013/2014 > council did it. The Council didn't replace QA, it populated it. There basically weren't any active members in QA when we did it. The GLEP clearly outlines how this year's Council agreed to do it in the future (not that future Councils couldn't change this). The QA lead basically holds the final say over what QA does, as is the structure of all of our projects in theory. In practice they shouldn't be ruling with an iron hand. QA chooses its own members, and they elect the lead. The lead then has to be confirmed by the Council, and I would generally expect that to be a rubber stamp most of the time. However, if there is an issue that is an opportunity for reform. But, if for whatever reason things really got out of hand, then Council absolutely should clean house if that is what they feel is the best option. What is the alternative? We can't have a Gentoo with half a dozen self-governing fiefdoms all doing whatever they feel is best regardless of what the overall developer community thinks. I'm not an advocate of the Council stepping on teams like QA/ComRel/Infra, but these are special teams that I believe require some kind of mandate. If your team isn't going to let any developer join, even if for good reason, then there needs to be some kind of accountability to the rest of the community. Otherwise people start complaining about cliques/etc. So, I'm an advocate of the Council being the buck-stops-here team, and if developers have a problem with our performance, they get the opportunity to get rid of us. Then all the grievances get aired, and we can all look at the results of an election and agree that they are fair. Sure, we'll still have our differences, but at least we can say that the majority of devs are happy with what is going on. But, accountability of ComRel is something for the next Council to decide on. I've been clear on my views - I want QA/ComRel/Infra to be subordinate to the Council, but self-governing in the day-to-day. I don't have strong feelings on whether ComRel/Infra are subordinate to the Council vs the Trustees - I think that they should be under one or the other but it could go either way. I also have stated before that I think that QA >> ComRel > Infra as far as priority of reform goes as well - QA was dysfunctional last fall and needed immediate action, ComRel and especially Infra are less broken and thus we shouldn't be in as much of a rush to "fix" them. Rich