| 1 |
On Sat, Jun 18, 2016 at 4:26 PM, Daniel Campbell <zlg@g.o> wrote: |
| 2 |
> |
| 3 |
> The less admin/bureaucratic overhead we have, the better. From what I |
| 4 |
> gather even the Council feels this way, but that's just my two cents. |
| 5 |
> |
| 6 |
|
| 7 |
++ |
| 8 |
|
| 9 |
Certainly I feel this way. I'd say that most of m peers would agree. |
| 10 |
Not that this ultimately matters since for the next two weeks the |
| 11 |
final say in what the council should be really rests with the |
| 12 |
developers. |
| 13 |
|
| 14 |
This topic has come up before. If you actually look at what powers |
| 15 |
the council has in practice they are: |
| 16 |
1. Approve GLEPs. |
| 17 |
2. Appeals for comrel actions. |
| 18 |
3. Resolve disagreements within the community (such as between projects, etc). |
| 19 |
|
| 20 |
The ability for the council itself to actually get anything done is |
| 21 |
purely dependent on how much its members want to spend their time |
| 22 |
doing it themselves. The council doesn't actually have the power to |
| 23 |
make anybody do anything. It does have the power to prevent somebody |
| 24 |
from doing something, and to pick a side in a dispute to settle it. |
| 25 |
For example, there was a dispute over how games should be managed, and |
| 26 |
the Council decided that developers could form a new games project if |
| 27 |
they wished, or maintain games outside of the project, and that it was |
| 28 |
not necessary to use the games eclass or follow the previous games |
| 29 |
project policies. What the Council can't actually do is force |
| 30 |
somebody to go in and modify all the games ebuilds to stop using the |
| 31 |
eclass. Maybe we could have all the games that use the eclass |
| 32 |
treecleaned, but that would be like swatting a fly with a howitzer. |
| 33 |
So, until somebody wants to actually implement the changes we're left |
| 34 |
with the status quo. However, nobody is actually complaining about |
| 35 |
the status quo, so it can't be that bad. Indeed, if somebody thought |
| 36 |
it was bad, they'd just fix it, and with the council decisions in hand |
| 37 |
nobody could interfere with their work. |
| 38 |
|
| 39 |
Ultimately that is the practical role of the council. If there is |
| 40 |
something you want to do in Gentoo, then DO IT. And if somebody gets |
| 41 |
in your way, the Council can get them out of your way, or help find a |
| 42 |
middle way that lets everybody accomplish their goals. |
| 43 |
|
| 44 |
When it comes down to actually leading initiatives, well, we already |
| 45 |
have GLEP 39 which basically says that anybody can do it. You don't |
| 46 |
need to be on the Council to make a big project happen. You just need |
| 47 |
to appeal to devs to contribute. If your appeal falls on deaf ears, |
| 48 |
trust me, being on the council isn't going to make it go any better. |
| 49 |
To the degree that any of us have sway in the community we had it |
| 50 |
before we ever joined the council, and maintain it apart from our |
| 51 |
participation in the council. |
| 52 |
|
| 53 |
Now, if you view the Council as a badge of honor or something to be |
| 54 |
put on a resume, then I certainly can understand frustration when |
| 55 |
people with low commit rates/etc or low rates of making big proposals |
| 56 |
aren't on the Council. However, if you view the role of the Council |
| 57 |
as running interference for the people who really are getting the work |
| 58 |
done, then you might appreciate that it isn't always beneficial to |
| 59 |
have the Council buried in implementing portage enhancements or |
| 60 |
whatever. Often "calmer heads" is one of the more important |
| 61 |
attributes, as well as technical competence. |
| 62 |
|
| 63 |
Oh, and a willingness to write up meeting summaries never hurts. :) |
| 64 |
|
| 65 |
-- |
| 66 |
Rich |
Archives