| 1 |
Note - references below to specific teams like Devrel are purely for |
| 2 |
illustrative purposes. I don't intend to suggest that the council |
| 3 |
actually needs to step in right now to fix anything in any of these teams. |
| 4 |
|
| 5 |
On 04/21/2010 08:27 PM, Jorge Manuel B. S. Vicetto wrote: |
| 6 |
> On 18-04-2010 11:58, Richard Freeman wrote: |
| 7 |
>> All other positions of leadership/etc exist to facilitate day to |
| 8 |
>> day work. All are subordinate to one of these two bodies. The |
| 9 |
>> council may be voting enact or revoke policy on behalf of any |
| 10 |
>> project/etc, and may make administrative decisions regarding |
| 11 |
>> project leads/etc. |
| 12 |
> I'll try to write my ideas on this subject in another reply to this |
| 13 |
> thread, but for now I'll just say that we should try to find a |
| 14 |
> balance between individual projects and their elected leads and the |
| 15 |
> council. Furthermore, we have some special projects like Developer |
| 16 |
> Relations and Infrastructure that need particular care as their |
| 17 |
> "subordinate role" is either not so clear or not so desirable. |
| 18 |
|
| 19 |
Here is my concern. I didn't vote for the lead of any of Gentoo's |
| 20 |
projects. At best I might get a chance to vote for one or two. |
| 21 |
However, I do vote for the council. So, the council represents the |
| 22 |
developers of Gentoo as a whole. If a project team wants to do |
| 23 |
something that the council considers detrimental to the distro as a |
| 24 |
whole (though perhaps it is optimal from the POV of the single team), |
| 25 |
then they should have the right to step in and make amends. |
| 26 |
|
| 27 |
The council and trustees are the most democratic bodies in Gentoo, and |
| 28 |
it is fitting that they ultimately wield the most power. |
| 29 |
|
| 30 |
> To address specifically your point about conflict of interest, that |
| 31 |
> is something that we should never waive casually. |
| 32 |
|
| 33 |
Agreed, that is why the council shouldn't just step in and deal with an |
| 34 |
issue unless it is a serious one. Who gets to decide if an issue is |
| 35 |
serious enough? Well, that would be the council, since they're the most |
| 36 |
trusted body in the organization. |
| 37 |
|
| 38 |
> But we have a policy on how to deal with developers and the eagerness |
| 39 |
> on the idea to throw it away and just let the council (the single |
| 40 |
> body council?) do what it wants, is very disturbing to me. |
| 41 |
|
| 42 |
Who voted to create this policy? Who gets to change it? If I want to |
| 43 |
change devrel policy, how would I do that? Suppose 85% of the Gentoo |
| 44 |
devs want to change it? Right now they'd need to somehow convince a |
| 45 |
majority of the members of Devrel to change the policy, or elect a lead |
| 46 |
that would. If the members of devrel are mostly from the 15% who |
| 47 |
disagree with the change then that might not happen. If devrel just |
| 48 |
boots the council on some pretense, should the council not be allowed to |
| 49 |
hear their own appear since it is a conflict of interest? My point is |
| 50 |
basically that closed groups like devrel should always be subordinate to |
| 51 |
an elected body - either the trustees or the council. |
| 52 |
|
| 53 |
If you look at any other serious organization the purpose of committees |
| 54 |
and bureaucracy is to serve the organization, and the organization is |
| 55 |
represented overall by the board of directors, who are elected by the |
| 56 |
members/shareholders/etc. This system works well - ultimately the |
| 57 |
members have absolute authority in elections, but the directors oversee |
| 58 |
things from time to time, and the committees and bureaucracy deal with |
| 59 |
the day-to-day. |
| 60 |
|
| 61 |
For example, the KDE team shouldn't be running every decision past the |
| 62 |
council. They probably should try to communicate to the community what |
| 63 |
they're up to, and they're one of the teams I'd actually consider among |
| 64 |
the better in this regard. If the council sees a big problem then they |
| 65 |
should be able to step in if necessary, but they should of course use |
| 66 |
discretion before doing so. |
| 67 |
|
| 68 |
That's really all I'm saying. The council should not wield its power |
| 69 |
with a heavy hand, but it should not be prevented from intervening on |
| 70 |
behalf of the community when necessary. To be honest, the complaint |
| 71 |
around here (perhaps warranted, perhaps not) seems to be more that the |
| 72 |
council doesn't do enough - I'm not sure that any council in memory |
| 73 |
would be eager to micromanage every project team. However, this is why |
| 74 |
devs should consider maturity when electing the council. |
| 75 |
|
| 76 |
The council doesn't do what it wants - it does what the developers as a |
| 77 |
whole want. By all means throw in a recall provision in the GLEP if you |
| 78 |
want, but if the dispute is between the council (elected by all) and |
| 79 |
some project lead (maybe elected by a few devs they work closely with), |
| 80 |
I'd say the council will have the best overall perspective. |
| 81 |
|
| 82 |
Rich |
Archives