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 83B1E1382C5 for ; Thu, 4 Jun 2020 16:08:26 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6A9D0E089E; Thu, 4 Jun 2020 16:08:25 +0000 (UTC) Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) (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 5817CE089C for ; Thu, 4 Jun 2020 16:08:25 +0000 (UTC) Received: by mail-ej1-f47.google.com with SMTP id q19so6706597eja.7 for ; Thu, 04 Jun 2020 09:08:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=pJShnK8JkCmj7kSm0eaRs9yy/j7PmSFIjastRdqFeUA=; b=mft2NZnLbHO9OnAZCIE6WTQNmryp7a3IcFl5Wub5Jv0y5X5IGyZZt/B8UWU44XbUpY cMhIC3fcc1oWiVc7cEKFsg3rfl4qS/ol+EeViPwfEn9e/Wh2z9Kwq8XxFxLR9nChc/gy ZXqTgN/Eoy9fpFPwq6V4dPbyJXba8qterBPeGJ1Dmyaihescq3iyTm+5wBdNx8NfnAZ4 1hqcbJibPonghUjUF49vApYVTIvWVrgUYqgiZDe0jJtCalIq3AYSBCrPJ/d5fIec7i0i aE8pzuLRxFcXuXTFVaagZYzTjtFojBmX84himvSYpqzf9VhxPAx1xujaX/m2uJrqg52e dpsw== X-Gm-Message-State: AOAM533miGLMTtQVQOruavCvDcVBx1iNE/q+b2tPj4+WdwC1XY/XcELr e8PCnacCb7Fw1ftTblqMKsvGE8MMEVdDhZeqm8yOlwQ5 X-Google-Smtp-Source: ABdhPJwOPg39/yqY2yh7grMvxn5s1kV8kGFpmFfmh+vDj3SWra6vzeNV/Q2G87D/ZVGfYT6r81CSLA/POjflBj/L9AI= X-Received: by 2002:a17:906:b845:: with SMTP id ga5mr4477242ejb.300.1591286903360; Thu, 04 Jun 2020 09:08:23 -0700 (PDT) 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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <31f6f5b574e0818a8fca3549e696ea18793c22ab.camel@gentoo.org> <54fc3312c6c6bf95e8fbb26392bba94061fd261c.camel@gentoo.org> In-Reply-To: <54fc3312c6c6bf95e8fbb26392bba94061fd261c.camel@gentoo.org> From: Rich Freeman Date: Thu, 4 Jun 2020 12:08:12 -0400 Message-ID: Subject: Re: [gentoo-project] [RFC] Triumvirate in Gentoo To: gentoo-project Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: b0f3d8db-a744-4c41-b7d0-5d4f1d20406d X-Archives-Hash: 8854e309975e9be7d35eae577023dd9f (Keep in mind that these aren't intended as "hard" objections - just trying to flesh this out a bit.) On Thu, Jun 4, 2020 at 11:19 AM Micha=C5=82 G=C3=B3rny = wrote: > > On Thu, 2020-06-04 at 09:12 -0400, Rich Freeman wrote: > > On Thu, Jun 4, 2020 at 3:15 AM Micha=C5=82 G=C3=B3rny wrote: > > > > 3. Do all decisions require a majority of the 3, or will these > > individuals have their own scope? Will a new technical GLEP just be > > approved by the "tech lead" or all three? Could the two non-tech > > leads override the tech lead on a tech decision? Obviously the goal > > is collaboration but presumably you want this to solve situations > > where collaboration already fails. I won't go on forever but I could > > see challenges either way. > > I dare say that one of them can make decisions if the two other don't > object to them. So it's mostly a matter of establishing an agreement > between the three whether they want to get involved every time, > or approve deferring specific kind of decisions to one of them. > Ok. I agree that this is how this would normally work, but if there is disagreement it is 2/3 majority rules. I'll get to intentional game-playing at the end, but let's assume a completely innocent scenario. Imagine Joe is great with financials and has interest in the org lead role, and there isn't much other interest in the job. The community is happy with his work in the org lead role. However, due to the fact that delegation to the tech lead is only by mutual agreement, Joe ends up having a bit of an extra influence on the tech side of the distro even though nobody really wants him in that role. If nothing else he has way more of a voice in the leadership team than an average dev/etc. You could argue that this is a feature or a bug depending on your perspective. Joe is putting in a lot of work, so maybe a bit of extra bikeshedding should be a perk. On the other hand, why should Joe be allowed that role? And of course Joe and the people lead might think we're about to make a really stupid tech decision and override the tech lead. Not suggesting this is a show-stopper - just something to consider. > > 5. I could see a lot of bleed-over. If you want to stack the > > leadership with pro/anti-emacs members, why would you limit that to > > only the technical role? Obviously I'm more concerned with more > > timely issues but we all know of a bunch of hot-button topics where > > top-down control can be used to push an agenda. So you could end up > > with an org lead who cares little about the financials simply because > > they have the right position on the hot topic of the day. Today these > > jobs are more delegated so that the elected board can represent the > > community but delegate the actual work to people who are more focused > > on the actual work. Sure, you could blame the voters for this sort of > > problem, but we already know how people tend to vote so we're not > > entirely blame-free if we set it up this way... > > > > I don't really understand why you assume that such a thing would happen. > Did we ever really have someone *that* unprofessional on the Council or > Trustees to push puny personal agenda over the best interest > of the distribution? I don't see any possible change here. The same > problem can happen whether we're talking of 1, 3, 7 or 12 people > in charge. Well, you could even argue that the latter is even more > possible because the responsibility is diluted, while if there's just > one responsible person, then the full blame goes to that person. I'm just thinking about human nature here. Maybe it is concerning systemd. Or maybe it is concerning the Code of Conduct or Social Contract. There are always going to be contentious issues that are often only semi-technical in nature and you can't always solve it with a USE flag. One of the differences today is that we separate the role of SME from the role of decider. You can have a board that is just focused on direction and overall policy/strategy, but they aren't the ones leading QA. You can have a board of directors who oversees everything, but they can appoint a Treasurer. Campaigns for Council/Trustees in the past certainly have touched on ideological issues (role of comrel/CoC and level of enforcement, Foundation vs umbrella, etc). In this model the decider is more of an SME. It is more of a technocracy. The problem is that how do you vote to support having an umbrella org if the most competent person to actually make sure the taxes get filed wants us to run our own Foundation? There is less separation of policymaking from execution this way. I think the result is that ideology will still end up dominating, and instead of the most competent SME for tech/people/org you end up with 3 people who have the views everybody likes the most who will just appoint other people do do the tech/people/org, which basically makes it no different from what we have now. I'd argue that instead of 3 separate elections it might be better to just have one election and take the top 3 that way, and not give them titles - it just turns into a combined Council/Trustees of 3. The problem with having 3 separate elections is the first-past-the-post issue: if 55% of the community is pro-systemd you end up with 3 pro-systemd candidates, instead of maybe more of a diverse mix with a majority in one direction. In an ideal world I agree that this wouldn't be a problem, but I'm just thinking about human nature here. And I'm not saying people are even being greedy - they just want to see their viewpoints represented. In this sense, the disagreement across Council/Trustee members maybe should be seen as more of a feature and less of a bug. Sure, decisions would be easier if they all agreed, but that also means that decisions would be easier even if 40% of the community strongly disagreed with them. That spirit of independence in these bodies largely reflects the attitude of the Gentoo community as a whole. Again, this isn't meant to be some argument that we absolutely shouldn't do it this way. My intent here is to raise some things to think about. There are some cons that go with the pros, and we should just be aware of them. I'm not saying they all have to be mitigated in the design, though when straightforward to do so maybe some could be. --=20 Rich --=20 Rich