Gentoo Archives: gentoo-project

From: "Andreas K. Huettel" <dilfridge@g.o>
To: gentoo-project@l.g.o
Cc: Aaron Bauman <bman@g.o>
Subject: Re: [gentoo-project] Council meeting Sunday 10/June/2018 18:00 UTC
Date: Sun, 10 Jun 2018 16:34:51
Message-Id: 2619723.dyicR4dehs@pinacolada
In Reply to: Re: [gentoo-project] Council meeting Sunday 10/June/2018 18:00 UTC by Aaron Bauman
1 Am Sonntag, 10. Juni 2018, 17:24:28 CEST schrieb Aaron Bauman:
2
3 > No sitting council members may be appointed to the project liaison
4 > role. If this individual is under the strict instruction of the council
5 > this there is no purpose for a dual-hatted individual. As such, the
6 > project laision should be capable of disagreement with the council and not
7 > fear retribution by being unseated. This position should be highly coveted
8 > as it will *directly* impact the current and future health of *our*
9 > project.
10
11 Well... The initial intention was the precise opposite - for reason of
12 avoiding unnecessary bureaucracy and intermediate steps, my first draft even
13 contained "a council member" instead of "a Gentoo developer". You need to take
14 into account that whoever does the job will have to become closely involved
15 and *present*.
16
17 Then again, if there's a suitable candidate, why not, so I loosened the
18 restriction to "a Gentoo developer". The only real limitation *for now* would
19 be "no Foundation personnel", to avoid legal complications.
20
21 > Additionally, the project liaison should be given some avenue of reprisal.
22 > First thought would be to introduce an all hands developer vote be called to
23 > unseat that project liaison.
24 > e.g. council appointed, but developer community removed.
25
26 That could be doable, but we need to make sure that this is not an "easy
27 process". I.e., if someone goes completely astray, it needs to be possible
28 when there is wide support, but only then... Say, 2/3 of yes votes and a
29 quorum of 1/2 of all devs...
30
31 > Disagreements between the council and
32 > their appointed liaison should not be simply squashed by introducing a new
33 > liaison who will blindly do things the way the council wants.
34
35 This does not make sense. The liaison is bound to the instructions of the
36 counil, so in case of disagreement the council needs to be able to pick a new
37 one.
38
39 > Ultimately, we *ought* to ensure that it is done the proper way. Please put
40 > the proper checks and balances in place.
41
42 I'm more worried that at the moment we're all checks and balances (or more
43 precisely, unclear areas of responsibility and unclear procedures), so that in
44 the end nothing gets done.
45
46 The council members do get elected... Maybe this would even be an argument
47 *for* requiring a council member as liaison.
48
49 In any case, this is a discussion of details that we still have quite some
50 time for. The motion is primarily whether we should approach SPI with the
51 intention of becoming an associated project. Then comes the question whether
52 they will accept us. And only after that the precise procedures need to be
53 agreed upon.
54
55 --
56 Andreas K. Hüttel
57 dilfridge@g.o
58 Gentoo Linux developer
59 (council, toolchain, perl, libreoffice, comrel)

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies