public inbox for gentoo-project@lists.gentoo.org
 help / color / mirror / Atom feed
From: Aaron Bauman <bman@gentoo.org>
To: gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project] Council meeting Sunday 10/June/2018 18:00 UTC
Date: Sun, 10 Jun 2018 12:52:24 -0400	[thread overview]
Message-ID: <4F566163-0CA4-4228-8FC1-038C133BE509@gentoo.org> (raw)
In-Reply-To: <2619723.dyicR4dehs@pinacolada>



On June 10, 2018 12:34:37 PM EDT, "Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
>Am Sonntag, 10. Juni 2018, 17:24:28 CEST schrieb Aaron Bauman:
>
>> No sitting council members may be appointed to the project liaison
>> role.  If this individual is under the strict instruction of the
>council
>> this there is no purpose for a dual-hatted individual.  As such, the
>> project laision should be capable of disagreement with the council
>and not
>> fear retribution by being unseated.  This position should be highly
>coveted
>> as it will *directly* impact the current and future health of *our*
>> project.
>
>Well... The initial intention was the precise opposite - for reason of 
>avoiding unnecessary bureaucracy and intermediate steps, my first draft
>even 
>contained "a council member" instead of "a Gentoo developer". You need
>to take 
>into account that whoever does the job will have to become closely
>involved 
>and *present*.
>
>Then again, if there's a suitable candidate, why not, so I loosened the
>
>restriction to "a Gentoo developer". The only real limitation *for now*
>would 
>be "no Foundation personnel", to avoid legal complications.
>

I agree, they would need to be present.  So, hopefully you can find someone.  I intend to run for council otherwise I would throw my name out there for consideration.  In principle (regardless if others agree or not) I would not ask to be considered for a dual-hatted position.  It is important to me that we resolve our outstanding financial issues etc and ensure Gentoo is healthy.

>> Additionally, the project liaison should be given some avenue of
>reprisal.
>> First thought would be to introduce an all hands developer vote be
>called to
>> unseat that project liaison.
>> e.g. council appointed, but developer community removed.
>
>That could be doable, but we need to make sure that this is not an
>"easy 
>process". I.e., if someone goes completely astray, it needs to be
>possible 
>when there is wide support, but only then... Say, 2/3 of yes votes and
>a 
>quorum of 1/2 of all devs...
>

Agreed.  That is exactly what I was implying.

>> Disagreements between the council and
>> their appointed liaison should not be simply squashed by introducing
>a new
>> liaison who will blindly do things the way the council wants.
>
>This does not make sense. The liaison is bound to the instructions of
>the 
>counil, so in case of disagreement the council needs to be able to pick
>a new 
>one.
>

I completely disagree with this hence my previous wording.  Sure, they should follow the instructions of the council, but should there be any reprehensible things asked of said liaison then they should be able to rectify that without fear of retribution.  This covers moral conflicts, matters of principle, and consolidation of power.

Once again, this is about the health of Gentoo.  If SPI can solve that then wonderful.

>> Ultimately, we *ought* to ensure that it is done the proper way. 
>Please put
>> the proper checks and balances in place.
>
>I'm more worried that at the moment we're all checks and balances (or
>more 
>precisely, unclear areas of responsibility and unclear procedures), so
>that in 
>the end nothing gets done. 
>
>The council members do get elected... Maybe this would even be an
>argument 
>*for* requiring a council member as liaison.
>
>In any case, this is a discussion of details that we still have quite
>some 
>time for. The motion is primarily whether we should approach SPI with
>the 
>intention of becoming an associated project. Then comes the question
>whether 
>they will accept us. And only after that the precise procedures need to
>be 
>agreed upon.

Yes, this is a concern of mine as well.  I find that an alternative third party like SPI will solve this. 

The pool of people who comprise the council and Foundation are the issue IMHO.  Allowing developers to fill both roles has caused this dysfunction/struggle of power we currently see.

The council should remain developers and the trademarks, IP, etc should be done by someone like SPI who has a simple interest in perserving the health of Gentoo.  I am not implying that developers do not care, but that we have given an avenue for individuality/personality to cause filibusters.

Also, in that sense, we ought to consider that SPI related matters be *advised* by council and voted on by the dev community at large.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


  parent reply	other threads:[~2018-06-10 17:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-08 17:44 [gentoo-project] Council meeting Sunday 10/June/2018 18:00 UTC Andreas K. Huettel
2018-06-08 17:57 ` Michał Górny
2018-06-08 18:05   ` Andreas K. Huettel
2018-06-08 18:02 ` Andreas K. Huettel
2018-06-10 15:24   ` Aaron Bauman
2018-06-10 16:34     ` Andreas K. Huettel
2018-06-10 16:43       ` Andreas K. Huettel
2018-06-10 16:52       ` Aaron Bauman [this message]
2018-06-10 17:19       ` Rich Freeman
2018-06-10 17:25         ` Andreas K. Huettel
2018-06-10 19:51   ` [gentoo-project] Re: SPI as an alternate foundation Matthew Thode

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F566163-0CA4-4228-8FC1-038C133BE509@gentoo.org \
    --to=bman@gentoo.org \
    --cc=gentoo-project@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox