Gentoo Archives: gentoo-project

From: Alec Warner <antarus@g.o>
To: gentoo-project <gentoo-project@l.g.o>
Subject: Re: [gentoo-project] Groups under the Council or Foundation: the structure & processes thereof
Date: Sun, 13 Nov 2016 19:27:12
Message-Id: CAAr7Pr9qF4O0P-fdKP1wa2LeXMTYZ_U-KHTk-5KnRH-xotrZWw@mail.gmail.com
In Reply to: Re: [gentoo-project] Groups under the Council or Foundation: the structure & processes thereof by Alec Warner
1 On Sun, Nov 13, 2016 at 11:26 AM, Alec Warner <antarus@g.o> wrote:
2
3 > On Sun, Nov 13, 2016 at 4:33 AM, Luca Barbato <lu_zero@g.o> wrote:
4 >
5 >> On 13/10/2016 01:30, Robin H. Johnson wrote:
6 >> > TL;DR: move comrel, infra, PR to Foundation. Have strict(er)
7 >> > application of policies to them in line with their powers.
8 >>
9 >
10 >> The foundation was made only to collect and redistribute money. In order
11 >> to do that it was made sort of copyright collector as well (but that was
12 >> actively blocked by the fact the EU law prevents that).
13 >>
14 >
15 > What I think is actually true is that there are some risks the current
16 > board sees, and they (we?, I am on the board after all) see one way to
17 > reduce the risk is by this joining. I think we should also be open to
18 > evaluating the risks and seeking other avenues to mitigate them.
19 >
20 > I think, speaking in general terms, one risk is the following.
21 >
22 > 1) When a community member feels harmed by the community, they can file a
23 > suit. They can sue individuals, or they can sue the Foundation. They cannot
24 > sue "Comrel" for example, because Comrel is not an entity. They can sue the
25 > individuals that compose comrel, or they can sue the Foundation.
26 >
27 > 2) If they sue the Foundation, we are worried that a 100% hands-off
28 > solution is going to be an effective defense. In the current scheme, the
29 > Foundation has no real control over the operation of Comrel. I think there
30 > is a lack of confidence that this defense is sufficient to dismiss a suit
31 > though.
32 >
33
34 Er, sorry, a 100% hands off solution is *not* going to be effective, sorry.
35
36 -A
37
38
39 >
40 > So we discard that defense. What other defenses can we offer?
41 >
42 > 1) We can move Comrel under the Foundation. That way we have influence
43 > over their activities. We can create policies that provide better legal
44 > defenses (like the Code of Conduct for instance) but also many of the
45 > transparency policies you see on other threads.
46 >
47 > 2) We could also decide that having Comrel under the Foundation is a bad
48 > idea, but we could do other things. Many of these could be not direct
49 > governance, but merely oversight to insure that the governing Gentoo bodies
50 > are acting in a legal way.
51 >
52 > 3) We could decide the risk is worth it; secure insurance, and do nothing.
53 >
54 > I think speaking more generally, you could replace "Comrel" with any
55 > Gentoo project. At the end of the day the Foundation holds all the assets
56 > and pays all the bills. How do we mitigate the Foundation's liability for
57 > the actions of volunteers in the project?
58 >
59 > Ultimately that is the question I want addressed.
60 >
61 > -A
62 >
63 >
64 >> In short and sweet summary:
65 >>
66 >> - The Council was made to be the team leading Gentoo, we have elections
67 >> for that reason.
68 >> - Recruitment should get new wonderful people as Developers, either by
69 >> inviting them or by vetting them.
70 >> - Comrel is offloading from the council the management of conflicts
71 >> between developers. Incidentally it had to manage also troublemakers,
72 >> creeps, and other horrible people that the recruitment process failed to
73 >> recognize as such (luckily happened really few times).
74 >> - Q/A is offloading from the council the management of day-by-day
75 >> technical issues and possibly prevent people not so skilled from destroy
76 >> systems.
77 >> - Foundation should just care of money on behalf of the council and not
78 >> interfere with the community.
79 >>
80 >> Giving the Foundation more power than act as financial operations is a
81 >> quite bad idea to me.
82 >>
83 >> lu
84 >>
85 >>
86 >