1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
On 22-04-2010 01:23, Richard Freeman wrote: |
5 |
> Note - references below to specific teams like Devrel are purely for |
6 |
> illustrative purposes. I don't intend to suggest that the council |
7 |
> actually needs to step in right now to fix anything in any of these teams. |
8 |
> |
9 |
> On 04/21/2010 08:27 PM, Jorge Manuel B. S. Vicetto wrote: |
10 |
>> On 18-04-2010 11:58, Richard Freeman wrote: |
11 |
>>> All other positions of leadership/etc exist to facilitate day to |
12 |
>>> day work. All are subordinate to one of these two bodies. The |
13 |
>>> council may be voting enact or revoke policy on behalf of any |
14 |
>>> project/etc, and may make administrative decisions regarding |
15 |
>>> project leads/etc. |
16 |
>> I'll try to write my ideas on this subject in another reply to this |
17 |
>> thread, but for now I'll just say that we should try to find a |
18 |
>> balance between individual projects and their elected leads and the |
19 |
>> council. Furthermore, we have some special projects like Developer |
20 |
>> Relations and Infrastructure that need particular care as their |
21 |
>> "subordinate role" is either not so clear or not so desirable. |
22 |
> |
23 |
> Here is my concern. I didn't vote for the lead of any of Gentoo's |
24 |
> projects. At best I might get a chance to vote for one or two. |
25 |
> However, I do vote for the council. So, the council represents the |
26 |
> developers of Gentoo as a whole. If a project team wants to do |
27 |
> something that the council considers detrimental to the distro as a |
28 |
> whole (though perhaps it is optimal from the POV of the single team), |
29 |
> then they should have the right to step in and make amends. |
30 |
|
31 |
My concern here is the idea that the council should be able to "disband" |
32 |
a project or turn it around 180 degrees. If we open the door to this, |
33 |
then we'll be throwing away the principles that any developer can create |
34 |
a project, that a team acts as its members choose to and that in the end |
35 |
some choices fall to those who do the work. |
36 |
I don't disagree with the council being able to influence or to |
37 |
cooperate with a particular project, but I don't like the idea of it |
38 |
having "nukes". Also, you'rd arguing that if a developer can't have |
39 |
influence on a team, they could try to go around it straight into the |
40 |
council. The vast majority of Gentoo projects are open to membership and |
41 |
that should be the preferred way to have influence on them - by sharing |
42 |
the load and working with the other members. Besides, if the council |
43 |
were to "disband" a team or try to force a policy on it, how do you |
44 |
think that would work if there were no team members left and no one |
45 |
stepped up? |
46 |
If and when a project or an individual developer exhibits a behaviour or |
47 |
takes action that compromises Gentoo or detriments its image, we should |
48 |
have tools to address that. We already have some tools though. |
49 |
Individual developers, depending on their actions, may be subject to |
50 |
DevRel action or have their access suspended by the infra team. If the |
51 |
issue has a legal base, the Foundation Trustees can be called to |
52 |
intervene. Finally, in extreme cases, the council can also have a word |
53 |
regarding individual developers and or projects. |
54 |
|
55 |
> The council and trustees are the most democratic bodies in Gentoo, and |
56 |
> it is fitting that they ultimately wield the most power. |
57 |
|
58 |
Gentoo isn't exactly a "democracy" and therefore such comparisons |
59 |
usually are not adequate for us. |
60 |
|
61 |
>> But we have a policy on how to deal with developers and the eagerness |
62 |
>> on the idea to throw it away and just let the council (the single |
63 |
>> body council?) do what it wants, is very disturbing to me. |
64 |
> |
65 |
> Who voted to create this policy? Who gets to change it? If I want to |
66 |
> change devrel policy, how would I do that? Suppose 85% of the Gentoo |
67 |
> devs want to change it? Right now they'd need to somehow convince a |
68 |
> majority of the members of Devrel to change the policy, or elect a lead |
69 |
> that would. If the members of devrel are mostly from the 15% who |
70 |
> disagree with the change then that might not happen. If devrel just |
71 |
> boots the council on some pretense, should the council not be allowed to |
72 |
> hear their own appear since it is a conflict of interest? My point is |
73 |
> basically that closed groups like devrel should always be subordinate to |
74 |
> an elected body - either the trustees or the council. |
75 |
> |
76 |
> If you look at any other serious organization the purpose of committees |
77 |
> and bureaucracy is to serve the organization, and the organization is |
78 |
> represented overall by the board of directors, who are elected by the |
79 |
> members/shareholders/etc. This system works well - ultimately the |
80 |
> members have absolute authority in elections, but the directors oversee |
81 |
> things from time to time, and the committees and bureaucracy deal with |
82 |
> the day-to-day. |
83 |
|
84 |
Gentoo (the distribution) is not a Corporation, so that comparison isn't |
85 |
adequate as well. |
86 |
|
87 |
Like it or not, a body like Developer Relations isn't democratic by |
88 |
nature. I don't think it ever had open membership as one of the concerns |
89 |
is that its members have some particular traits. Thus, as far as I know, |
90 |
all current and former members were always invited in. |
91 |
But Developer Relations isn't a "Boy's Club" or the only "not so open" |
92 |
group in Gentoo. There's also User Relations. The infrastructure team, |
93 |
for its own responsibility and abilities, as far as I know, has always |
94 |
invited members in and doesn't have open membership. To a certain extent |
95 |
the QA team has worked that way too and I'm sure most of us would like |
96 |
QA members to exhibit certain qualities. Then there's PR. |
97 |
So, as I said, some teams have particularities that need to be taken |
98 |
into account. Also, some policies like Developer Relations are never |
99 |
good candidates for a referendum. To have an effective and adequate |
100 |
policy, you want people to work on it with cool blood, to leverage some |
101 |
experience on it and not to be concerned with the document's |
102 |
"popularity". If DevRel were ever to try to introduce arbitrary measures |
103 |
in the policy contrary to Gentoo's interest and or of questionable |
104 |
nature, the Council should obviously have a say. I would say Trustees |
105 |
could also be called into action, but I don't see a direct way for them |
106 |
to intervene as long as the change impact only the people working on |
107 |
Gentoo and or the way they work on Gentoo and not the distribution in |
108 |
itself, but nothing prevents the Council asking for their help if they |
109 |
see it fit. |
110 |
|
111 |
> For example, the KDE team shouldn't be running every decision past the |
112 |
> council. They probably should try to communicate to the community what |
113 |
> they're up to, and they're one of the teams I'd actually consider among |
114 |
> the better in this regard. If the council sees a big problem then they |
115 |
> should be able to step in if necessary, but they should of course use |
116 |
> discretion before doing so. |
117 |
|
118 |
A former council did have some influence, not directly in the KDE |
119 |
project, but by having DevRel evaluate and act on one of its members - |
120 |
at the time the Lead. That action did had a profound impact in the |
121 |
project - it almost killed it and it took a long time for KDE to get |
122 |
back in shape. For this discussion the relevant part is that the action |
123 |
was done by DevRel, it was about an individual member behaviour and even |
124 |
though it followed procedure it still raised much concern about the |
125 |
council influence - so one can only imagine what would have been the |
126 |
reactions if council were able to take action directly. Furthermore, |
127 |
such influence in the end lead to most of the existing active members |
128 |
leaving the project and if there had been no new blood coming in, we |
129 |
might had been left without KDE on Gentoo. So a direct intervention by |
130 |
the Council on a project may have dire consequences. |
131 |
To be clear, I do want the Council to have influence over Gentoo, but I |
132 |
don't like the idea of "carte blanche" and therefore am concerned about |
133 |
the degree and method by which the council should "leverage" its influence. |
134 |
|
135 |
> That's really all I'm saying. The council should not wield its power |
136 |
> with a heavy hand, but it should not be prevented from intervening on |
137 |
> behalf of the community when necessary. To be honest, the complaint |
138 |
> around here (perhaps warranted, perhaps not) seems to be more that the |
139 |
> council doesn't do enough - I'm not sure that any council in memory |
140 |
> would be eager to micromanage every project team. However, this is why |
141 |
> devs should consider maturity when electing the council. |
142 |
> |
143 |
> The council doesn't do what it wants - it does what the developers as a |
144 |
> whole want. By all means throw in a recall provision in the GLEP if you |
145 |
> want, but if the dispute is between the council (elected by all) and |
146 |
> some project lead (maybe elected by a few devs they work closely with), |
147 |
> I'd say the council will have the best overall perspective. |
148 |
> |
149 |
> Rich |
150 |
> |
151 |
|
152 |
- -- |
153 |
Regards, |
154 |
|
155 |
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org |
156 |
Gentoo- forums / Userrel / Devrel / KDE / Elections |
157 |
-----BEGIN PGP SIGNATURE----- |
158 |
Version: GnuPG v2.0.15 (GNU/Linux) |
159 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
160 |
|
161 |
iQIcBAEBAgAGBQJL0DXWAAoJEC8ZTXQF1qEP8MgP/2NQP4CXYAzYd7UNP9QrQdq7 |
162 |
pE4vOyzEcXys8Bo0HQzOozNDFluDgVAAe+LreQ38dbU5FworyGpf48llG9q4R1VA |
163 |
Hemq0P21UJ+VmVGzMYnRIhZ7eSXdYOSs/W9CeT3VNSwZBBVIlv+W4/uBl/3FPtv2 |
164 |
321U/l1kiC7oSml+33ejnhnXjxZrz8y3XvoeQ6c796kKiumVJ/T9zi/uWsk/xeOZ |
165 |
S72tz7tPgOnVxrz3SD2ltTRNsdv94WA6QvnHxZwfjcsi6lNIITXxxsnoV14UIPub |
166 |
i91BMjiBP7YTgujhG6jtzn/L03dTgzSj6wnoZtpkFxMiVC2Sqbzq3WNuDVkBxkyR |
167 |
NhCmvqpk+kEPG3O9uUm67B8EV66gd4Sn3u5Qjm1iFNGui7pX8e15E1YhUUoTvTZv |
168 |
iaL35MzoRh4O9XkNhJWiOl8S5mPeyDcg6j5MmLKYprmHSJpTmZGI+AVbDX16uTzj |
169 |
Ra6Y0Wxgm559t7jpM7vlsF98OV2WxvFX9bLCwi0v+a0Qxlszenj1KgiLR9q8pWmU |
170 |
BfdMPbHAxtPkKDUpijeLF8R9N831MAgbgzwO46cGBYeIUmBNqcZMxy0x21WJU37U |
171 |
77CdoBtkdYT9EiLCRXKUq6uKq3fZnsApq0pa5ZnUzcqvN/2+WhCzsw9wcVfwQGla |
172 |
hqZ6665ij/t1/OIVeYQn |
173 |
=/wqa |
174 |
-----END PGP SIGNATURE----- |