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 EF9F113877A for ; Wed, 2 Jul 2014 13:10:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 01786E08C5; Wed, 2 Jul 2014 13:10:59 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 58F30E08BB for ; Wed, 2 Jul 2014 13:10:58 +0000 (UTC) Received: from [IPv6:2a01:4f8:191:22ca::2:1003] (vpn-c3.not-your-server.de [IPv6:2a01:4f8:191:22ca::2:1003]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jlec) by smtp.gentoo.org (Postfix) with ESMTPSA id D35FC33FD55; Wed, 2 Jul 2014 13:10:56 +0000 (UTC) Message-ID: <53B404DD.7000501@gentoo.org> Date: Wed, 02 Jul 2014 15:10:53 +0200 From: "Justin (jlec)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 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 To: hasufell , gentoo-project@lists.gentoo.org CC: dilfridge@gentoo.org Subject: Re: [gentoo-project] Gentoo Council 2014 / 2015 election References: <539BD2E2.7030803@gentoo.org> <1757239.UAu395ci7F@kailua> <53B2E4CA.1080408@gentoo.org> <53B2FE38.7040508@gentoo.org> <53B3E74C.9080109@gentoo.org> In-Reply-To: <53B3E74C.9080109@gentoo.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sPe8HINtDXt6Wap7DU6w1XMlT61U5uf24" X-Archives-Salt: 2158c671-3bbd-4014-ad83-43b54179320e X-Archives-Hash: cf32e0ad4684cc98632186de2b01eafd This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sPe8HINtDXt6Wap7DU6w1XMlT61U5uf24 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/07/14 13:04, hasufell wrote: > Rich Freeman: >> On Tue, Jul 1, 2014 at 2:30 PM, hasufell wrote: >>> So you are basically saying a conflict of interest can happen and whe= n >>> it does, everyone will actually realize it and also act appropriately= =2E >>> >> >> Well, if people don't do that, then you're up the creek no matter what= >> system of governance you come up with. >> >> SOMEBODY has to make the final decision, and they can always have a >> conflict of interest. >> >> Unless half the council is in on the original offense, it really only >> makes a difference if it is a close call. So, avoid doing things that= >> would tick off half the council and you should be fine. :) >> >> This is no different than a majority of trustees being able to sell >> the Foundation to your least favorite IT vendor. If you're going to >> vote a bunch of untrustworthy individuals into office, then you might >> not like the result. >> >> I don't see a practical alternative. The kinds of skills that you >> need to be a decent Trustee, Council member, or Comrel member overlap >> significantly. We aren't exactly a huge organization. So, we either >> have to accept overlap, or put people into these roles that we might >> otherwise not want to. There is also QA and Infra to consider - do we= >> not allow anybody to be on more than one of these teams? >> >=20 >=20 > Then I hope dilfridge and jlec respond to this thread, so I can make a > decision on how to vote. >=20 Hi Julian, I definitely understand your worries that placing the power of Comrel and its controlling counterpart into the same person. And I thought about this before, but as said by others, there are a number of reason why the situation isn't as bad as it seems. Each team, council and ComRel consists of several members who should counterbalance any problematic situation. Two thoughts came to my mind here, should we regulate the number of people being in both teams? and should we exclude council members being in ComRel from any decision where the council needs to act upon ComRel? The first one would avoid that ComRel takes over the council and the second obviously would tackle your concerns. Has there been a case where a "conflict of interest" happened in reality? And couldn't be solved? I don't know any, but I can be wrong here. Nevertheless, we shouldn't forget the argument Rich came up with, we aren't many people and if there are persons who bring the competency for both jobs and are willing to spent the time, then we really should try to build on that rather then trying to create a problem. I am a doing recruiting, which is a subproject of ComRel and makes me to a ComRel member. But normally I don't feel responsible to act in the interpersonal cases. So in the end there are different types of ComRel members. In the end, I would look onto the person and not onto the tables telling you in which teams they are. There will be double seated ComRel+Council members who will be fair and objective, but there also will be solely council members, who will be pain when you need the council to resolve conflicts. So we should choose the right persons based on their personali= ty. Justin --sPe8HINtDXt6Wap7DU6w1XMlT61U5uf24 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTtATdXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQyQ0JDQjFGMzBDQ0UxMjFGNENDNDgxMDdC OUQ0RjIzMUJEMTU1OEFCAAoJELnU8jG9FVirTZsP/3c9UR9Gob6vEOFYp8EmucyL snb8I6nyN0DAPTeu8AlZpqJm/DLY5lAxjITowcUoex5ks9hMzgn8FxvKEwHpVET9 zK2FL//RQCEopsti26GXvwWxw63sjoCD8UgFPy9o0FmdSWRcOA1XWniD3H3Ju1XP 11KJiunBuBZK/QYHl6o9QvsNtF9t1gLoyjGhjh1rmt8CYdxtCOzKyloYtogYtjqq /YP4avIeFfNip5S2fX5Na2Fb9HsoZdDaBeurwBkdRKW1TYB7kCDs4YH97mcSIVQv WAjc5le5mXqstlYTc4lSqBhI9a3Al+Ek7XbllBLhNi9EoGDvHVyEVGt7xfjEpm7m 0VI7JYv2KXrFcXf6nFzRU/sej4zKA2gd0bdOnYTf95sQqo73SAHk35rRZrsTHHeF VNXpxQJ7z/eKKFdj6HgTUOO3xjuQRZX7EMjdE5yEsczQVElU9c5fqkeBHMlABRXJ yYJNpSseEedj1ZB5Ab8qNA4nxbFMKEarSH3w7nMVaXN3YwrHj69XejaKMOgcUZ1l y3/zeSWpQ86OmaNaJ1zkJDn0pM2AVxoxGi1t9k/6TsORnCRb4LgNF8Lv59LsCBfX ZclKZFMVRibOa4u8XPJ4HANidm6l8M1NNee7xFp3nZh9Whas53utHuyEQ9tBzJUP PDeUsezW+bWDJ3d1WwHo =ceX5 -----END PGP SIGNATURE----- --sPe8HINtDXt6Wap7DU6w1XMlT61U5uf24--