1 |
On 13/11/16 13:59, Rich Freeman wrote: |
2 |
> On Sun, Nov 13, 2016 at 7:52 AM, M. J. Everitt <m.j.everitt@×××.org> wrote: |
3 |
>> On 13/11/16 12:33, Luca Barbato wrote: |
4 |
>>> On 13/10/2016 01:30, Robin H. Johnson wrote: |
5 |
>>>> TL;DR: move comrel, infra, PR to Foundation. Have strict(er) |
6 |
>>>> application of policies to them in line with their powers. |
7 |
>>> The foundation was made only to collect and redistribute money. In order |
8 |
>>> to do that it was made sort of copyright collector as well (but that was |
9 |
>>> actively blocked by the fact the EU law prevents that). |
10 |
>>> |
11 |
>>> In short and sweet summary: |
12 |
>>> |
13 |
>>> - The Council was made to be the team leading Gentoo, we have elections |
14 |
>>> for that reason. |
15 |
>>> - Recruitment should get new wonderful people as Developers, either by |
16 |
>>> inviting them or by vetting them. |
17 |
>>> - Comrel is offloading from the council the management of conflicts |
18 |
>>> between developers. Incidentally it had to manage also troublemakers, |
19 |
>>> creeps, and other horrible people that the recruitment process failed to |
20 |
>>> recognize as such (luckily happened really few times). |
21 |
>>> - Q/A is offloading from the council the management of day-by-day |
22 |
>>> technical issues and possibly prevent people not so skilled from destroy |
23 |
>>> systems. |
24 |
>>> - Foundation should just care of money on behalf of the council and not |
25 |
>>> interfere with the community. |
26 |
>>> |
27 |
>>> Giving the Foundation more power than act as financial operations is a |
28 |
>>> quite bad idea to me. |
29 |
>>> |
30 |
>> EWW .. forgive my boldness, but that is the Exact Opposite of what needs |
31 |
>> to happen. What you are, in effect, proposing, is that for all intents |
32 |
>> and purposes, you can merge the Function of the foundation INTO council. |
33 |
>> Why keep them separate if the legal body is the Council and it is |
34 |
>> adequately ratified by its developers, but yet not the general community |
35 |
>> and membership at large. |
36 |
> Why would we want people who don't make any significant contributions |
37 |
> to the organization to be voting on how it ought to operate? |
38 |
> |
39 |
> Those who do make significant contributions ought to sign up to be |
40 |
> developers/staff/whatever (you don't need to write ebuilds to be a |
41 |
> developer), and then they get to vote for Council. |
42 |
Yes, but status quo (unless I'm mistaken) is not all contributors (just |
43 |
ebuild devs??) vote for council, or am I mistaken ... could easily be |
44 |
mistaken here .. and appropriate stats would have to be found to |
45 |
demonstrate that non-ebuild devs were still actively being represented |
46 |
on the council (possibly even my a single defined non-technical |
47 |
role?).... another bike-shed .. I apologise ... |
48 |
> Even if we were to put the Foundation on top I don't think that people |
49 |
> who aren't recognized as developers/staff/whatever (don't want to make |
50 |
> this about the label) should be voting for the board. |
51 |
> |
52 |
> I get that letting everybody on the planet vote for how we do things |
53 |
> sounds more open, but the reality is that we need to maintain an |
54 |
> environment where people want to contribute to Gentoo. If Gentoo |
55 |
> doesn't work for the people who contribute the most, then there isn't |
56 |
> going to be much left for the people who just want to use it. |
57 |
> |
58 |
>> This only goes to reinforce the status quo that |
59 |
>> the council is a self-serving self-reinforcing body.... A single-headed |
60 |
>> monster if you will. |
61 |
> The council serves the distro, and is elected by the developer |
62 |
> community. I don't get how it could possibly be considered |
63 |
> self-reinforcing. You could argue that the developer community as a |
64 |
> whole might be, but they're also the ones doing all the work to make |
65 |
> things happen (and people doing a lot of work who aren't in the |
66 |
> developer community should be added as long as they abide by the |
67 |
> standards). |
68 |
[snip] |
69 |
> |
70 |
> Ultimately I think we need to remember why we're here. |
71 |
> |
72 |
> We're not here to run a Foundation. |
73 |
> |
74 |
> We're not here to buy and run servers. |
75 |
> |
76 |
> We're not even here to run an HR department or be on Council. |
77 |
> |
78 |
> We're here to create a Linux distribution. Ultimately all of these |
79 |
> things need to serve that larger goal. |
80 |
^ This .. this cannot be overstated. It seems we frequently lose sight |
81 |
of this ... |
82 |
> So, I think in some sense it could make sense to just have one overall |
83 |
> body that looks after the needs of the distro, which is elected by the |
84 |
> contributors to the distro, and then everything else falls into |
85 |
> projects/etc around this. We have a project for QA, we have a project |
86 |
> for Infra, and we could have a project for the US Foundation, or a |
87 |
> project to manage a relationship with an umbrella organization like |
88 |
> SPI if we don't want the hassle of running a Foundation ourselves |
89 |
> (which seems to be more of the trend lately, as Debian and Arch now |
90 |
> use SPI instead of running their own Foundation). What you call the |
91 |
> one overall body seems secondary to its purpose of keeping all the |
92 |
> pieces working together smoothly while being accountable to the |
93 |
> contributors. |
94 |
> |
95 |
Conceivably this would also work .. a 'Finance' project .. a 'Legal' |
96 |
project.. if that's the way you want to do it, great. But the flow of |
97 |
accountability should be clear and transparent. And if there should be a |
98 |
problem with the council, ever, there should be an independent body (a |
99 |
Trust frequently or other Board of Directors, non-executive, etc) which |
100 |
can review and rectify any exclusively council issues, upholding the key |
101 |
aim of creating a Linux Distro. |