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) |