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