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 17E52138334 for ; Wed, 11 Jul 2018 14:35:29 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 965DAE07ED; Wed, 11 Jul 2018 14:35:27 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 3D80AE076B for ; Wed, 11 Jul 2018 14:35:27 +0000 (UTC) Received: from [192.168.2.51] (62.65.229.81.cable.starman.ee [62.65.229.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: leio) by smtp.gentoo.org (Postfix) with ESMTPSA id D2D0C335C02 for ; Wed, 11 Jul 2018 14:35:24 +0000 (UTC) Message-ID: <1531319718.1445.35.camel@gentoo.org> Subject: Re: [gentoo-project] Gentoo Council nominee 2018/19 questions From: Mart Raudsepp To: gentoo-project@lists.gentoo.org Date: Wed, 11 Jul 2018 17:35:18 +0300 In-Reply-To: <1530087907.849.13.camel@gentoo.org> References: <1529997071.2250.6.camel@gentoo.org> <1530087907.849.13.camel@gentoo.org> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-tlva3FHlVc/z/5mYweOV" X-Mailer: Evolution 3.24.6 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-Archives-Salt: de4bea9f-f7ae-41fd-ba26-28439c4f1a48 X-Archives-Hash: 4b314bf2044fcceaa36b88f587d15eab --=-tlva3FHlVc/z/5mYweOV Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =C3=9Chel kenal p=C3=A4eval, K, 27.06.2018 kell 10:25, kirjutas Micha=C5=82= G=C3=B3rny: > 1. Do you believe that Council members should respect the requests of > the developer community even if they disagree with them? Or should > Council members decide based on their own judgment of arguments > presented? Council members should decide based on their own judgment, after having put in sufficient thought, research and opinions of the developer community. This is how such election based bodies generally work, really, as K_F has already expressed. You vote for someone you believe to have similar views and trust them to make thought out decisions, while advocating for what you want when you feel strongly towards it, but not having to worry about it otherwise, as there's someone you voted to do it for you. Example: there's a heated debate, and the majority of respondents > request that X is implemented. However, after reading all the > arguments > you don't think that X is a good idea but you haven't managed to > convince others. Would you vote for X (as your electorate demands) > or against it (as you believe is better for the distro)? Just following requests from developer community leads to issues like rubber stamping vocal minority, voting without research and thought. An elected persons job is to serve the electorate that voted for him/her. The election is anonymous, so you should assume you got voted in by people who believe your judgment is good for their views and for the elected body as a whole. Not a potential vocal minority, spur of the moment topics and so on. If this is truly a high majority that wants the decision to be implement, then a simple majority of council members will almost surely think the same. If not, there will be the option to adjust your votes distribution next time. In many other places the terms are much longer than a year (e.g. 4-7 years in democratic politics), and in the grand scheme of things, things work. 1 year is much less. I don't see how just rubber stamping a _perceived_ majority does us any good. >=20 > 2. Do you believe that the Council should proactively research the > state > of affairs and make decisions whenever they believe the direction > of the distribution needs to be adjusted? Or should it be passive > and avoid involvement unless developers explicitly request Council's > intervention? As I've expressed in my last years manifesto as well[1], I believe the council members should be leaders in Gentoo, individually. That means being proactive, finding global issues, describing them, empowering people to fix it, etc. This isn't something that needs one to be a member of the council, but I think it's the kind of people we need on the council. However council as a whole (in particular its voting) should be a backup when consensus seeking fails, or really global matters need the technical review decision (e.g. EAPIs). > 3. Do you believe the developer community should hold the power > to veto or dissolve the Council at any point? Provided there's a > global > developer vote agreeing on that. Given the 1 year only term and the potential for the next council to overturn things, I'm not sure it's something very important. However if such a thing is done, it should not be based on a majority of those who voted, but either a majority of eligible voters or a super-majority (66%, 75%, something like that) of who vote. We don't want to end up with every decision questioned and a general developer vote called for all of them. Gentoo developers want to spend their scarce free time improving Gentoo, not cast votes. Regarding a general vote, I think there are places for it, e.g. the council itself decides it needs global input from all developers to make a decision that isn't otherwise clear (especially cases where opinion matters a lot, while being a rather important decision to make overall too). [1] https://dev.gentoo.org/~leio/council/manifesto-2017.txt Mart --=-tlva3FHlVc/z/5mYweOV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQKTBAABCgB9FiEEUdZn9pOq0mlNjRvdEKbJ+k9JlgYFAltGFaZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDUx RDY2N0Y2OTNBQUQyNjk0RDhEMUJERDEwQTZDOUZBNEY0OTk2MDYACgkQEKbJ+k9J lgY/jQ/+NlTqANesm0HIvGVk+1MMZI+WN2oYgwwcGqRJ5kw96SwqYNbZVIfBGfMg R2x94l5N93Xf3Xmjcaglr1uhpiDz4TCEabmfYFIHEEP6C5s5gKxyRiy99lHA6/2+ 4jUZgoIQioCeMLaE0gdS0NQLOxg48gPvFPEETrIzoAUlYF110JfnwPirrs3qWgaB HOmGTG3ORvgF9D1909m/aLGoxjiHuHf07J1j0FFvvyDvcWRpfCm7zmaYiPuEn3bq 5HT0YuylWIusCBqPTBG/GorEr8AXRr8zrPjkP6UGblWrGbSPglfPqK3MnOqUAJGm FZUV5PgFyGOnsDawKyW2WY9uWLsee03ODUHWb8g53IJ3Sd6Aab7fjrmUXG9FrVPK e4g34BpH0dsBlyJxGiTJkNKs/P+Mcn85oMGVRjOewJurnA2Yf8HFv7tUL9ujGkSj m8x8MWts52J2/o70zbtF+rAt2P6ci3K9Kyu+L37slbawknXH27YcSZMEEZdLEtdi 2Iks9JD1/nZa2OSMoy/mC42oQ1EnxgnjmuHhvCVkla2n/5UhfpetK4XzMTdY77vj EPANQd2rukzIqRm/uYCI/IHaZxvSTfZl8IJqTUL2J+5FyvztwhRk2rZGeX/XHC5/ U3RpVELnR2Ow5kDHihEEGAPzmpC/M82fBw+MmVnSSovwm7gq7wo= =+f4Y -----END PGP SIGNATURE----- --=-tlva3FHlVc/z/5mYweOV--