1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
On 22-04-2010 21:55, Richard Freeman wrote: |
5 |
> On 04/22/2010 07:41 AM, Jorge Manuel B. S. Vicetto wrote: |
6 |
>> My concern here is the idea that the council should be able to "disband" |
7 |
>> a project or turn it around 180 degrees. If we open the door to this, |
8 |
>> then we'll be throwing away the principles that any developer can create |
9 |
>> a project, that a team acts as its members choose to and that in the end |
10 |
>> some choices fall to those who do the work. |
11 |
> |
12 |
> Not at all - developers could still do all of this, as long as they |
13 |
> don't do anything so drastically bad for the distro that the council |
14 |
> would need to step in. |
15 |
> |
16 |
> The council should of course use discretion in its actions, and it |
17 |
> should always just talk to somebody before they go booting people/etc. |
18 |
> |
19 |
>> Besides, if the council |
20 |
>> were to "disband" a team or try to force a policy on it, how do you |
21 |
>> think that would work if there were no team members left and no one |
22 |
>> stepped up? |
23 |
> |
24 |
> Again, a good reason for the council to use discretion. However, in |
25 |
> some cases it would be better to not have a team at all than to have a |
26 |
> team acting contrary to the overall distro's interests. |
27 |
> |
28 |
>> Finally, in extreme cases, the council can also have a word |
29 |
>> regarding individual developers and or projects. |
30 |
> |
31 |
> How? This is exactly what I'm proposing - that in extreme cases the |
32 |
> council can intervene directly as needed. If the council can't do this, |
33 |
> then how can they "have a word" unless you literally mean nothing more |
34 |
> than words. |
35 |
|
36 |
I read your proposal as giving unlimited powers to the council without |
37 |
some form of check and balances. I gather from your last reply that you |
38 |
want to ensure they have enough leeway to be able to act, but that they |
39 |
should only do it in extreme cases. It seems there's room to try to find |
40 |
a balance. |
41 |
|
42 |
>> Gentoo isn't exactly a "democracy" and therefore such comparisons |
43 |
>> usually are not adequate for us. |
44 |
> |
45 |
> Perhaps not purely so, it is a bit more of a meritocracy, but it is |
46 |
> essentially democratic. I don't see why democracy is a bad thing, as |
47 |
> long as it doesn't involve those who don't do anything wielding power |
48 |
> over those who do. Having at least a little control over the membership |
49 |
> roles should mitigate this. |
50 |
|
51 |
I don't think democracy is bad, I just wanted to highlight that not |
52 |
everything in Gentoo is subject to democratic rules. |
53 |
|
54 |
>> Gentoo (the distribution) is not a Corporation, so that comparison isn't |
55 |
>> adequate as well. |
56 |
> |
57 |
> What is a corporation? It is essentially a body of people aligned to a |
58 |
> common purpose. The same governance models apply to everything from |
59 |
> businesses to clubs to professional organizations to churches to |
60 |
> parliaments. Perhaps all these organizations have figured out that this |
61 |
> model works fairly well - or at least better than the alternatives. |
62 |
> Honestly, I don't really see what cohesive alternative you're offering |
63 |
> other than a loose confederation with oversight by closed bodies. |
64 |
|
65 |
You have a point as I haven't submitted any alternative yet. I do want |
66 |
to submit a proposal but I'm still thinking about it and evaluating old |
67 |
thoughts about Gentoo's meta-structure. |
68 |
|
69 |
>> But Developer Relations isn't a "Boy's Club" or the only "not so open" |
70 |
>> group in Gentoo. There's also User Relations. The infrastructure team, |
71 |
>> for its own responsibility and abilities, as far as I know, has always |
72 |
>> invited members in and doesn't have open membership. To a certain extent |
73 |
>> the QA team has worked that way too and I'm sure most of us would like |
74 |
>> QA members to exhibit certain qualities. Then there's PR. |
75 |
> |
76 |
> I don't think that any of these organizations are doing a bad job. I'm |
77 |
> not sure they should be open to anybody who wants to sign up. However, |
78 |
> there should always be oversight. That is really all I'm proposing. |
79 |
> Having council oversight actually frees up these organzations to not |
80 |
> feel as beholden to admit devs at large, since the council can hold them |
81 |
> accountable. |
82 |
> |
83 |
> In the end there will always be oversight - right now it isn't written |
84 |
> down, but in the end SOMEBODY or some group is in charge. I guess it |
85 |
> effectively is whoever has root on the servers, or perhaps the trustees |
86 |
> since they can determine who can use the name Gentoo. All I'm saying is |
87 |
> that we should realize that governance is necessary and set up the best |
88 |
> form of governance we can have. |
89 |
|
90 |
I agree fully with you about oversight. I don't think any project on |
91 |
Gentoo can and should be able to run without oversight. My question is |
92 |
about what type of oversight and what tools it should have at its disposal. |
93 |
|
94 |
>> A former council did have some influence, not directly in the KDE |
95 |
>> project, but by having DevRel evaluate and act on one of its members - |
96 |
>> at the time the Lead. That action did had a profound impact in the |
97 |
>> project - it almost killed it and it took a long time for KDE to get |
98 |
>> back in shape. |
99 |
> |
100 |
> And in the end, was Gentoo as a whole better off or worse off? Sometimes |
101 |
> you need to take a step back to take a step forward. I have no idea |
102 |
> what the specifics of this situation were, so I can't comment on whether |
103 |
> I agree or disagree with what the council did. However, if a key |
104 |
> contributor to Gentoo is doing more harm than good by driving others |
105 |
> away, then it might be better for them to not be around. |
106 |
|
107 |
I purposely avoided making a judgement about that decision. All I wanted |
108 |
to do is to pick in an example from a team you mentioned to highlight |
109 |
the consequences the type of council decisions we're talking about may have. |
110 |
|
111 |
> Donnie gave a good talk to this effect: |
112 |
> http://www.mefeedia.com/watch/21519531 |
113 |
|
114 |
I know his talk and some older talks about the same issue. The type of |
115 |
behaviour at stake is something that in the short term falls under |
116 |
either Developer Relations or User Relations. A discussion about what to |
117 |
do in the long term was started by previous Councils, but a conclusion |
118 |
wasn't reached. |
119 |
|
120 |
>> To be clear, I do want the Council to have influence over Gentoo, but I |
121 |
>> don't like the idea of "carte blanche" and therefore am concerned about |
122 |
>> the degree and method by which the council should "leverage" its |
123 |
>> influence. |
124 |
> |
125 |
> Well, are there any alternatives short of the Council being able to do |
126 |
> nothing but ask people nicely to not destroy the distro? I'm fine with |
127 |
> checks and balances, but in the end somebody needs to have the final |
128 |
> say, and I'd rather see that be a body elected by all - either the |
129 |
> trustees or the council. |
130 |
|
131 |
I don't have any alternatives yet, but that's what I'd like to find. |
132 |
|
133 |
> Maybe there are some ways to address the concern of a runaway council. |
134 |
|
135 |
Yes, that may be part of the solution. |
136 |
|
137 |
> Rich |
138 |
> |
139 |
|
140 |
- -- |
141 |
Regards, |
142 |
|
143 |
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org |
144 |
Gentoo- forums / Userrel / Devrel / KDE / Elections |
145 |
-----BEGIN PGP SIGNATURE----- |
146 |
Version: GnuPG v2.0.15 (GNU/Linux) |
147 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
148 |
|
149 |
iQIcBAEBAgAGBQJL0ROwAAoJEC8ZTXQF1qEP8FoQAMPpJ7ZeVIxczYlzor5Phhwh |
150 |
eyqNRRnEwupoM64ozm45g1u4Cy/R2++aPgbJQQ6Xw+8I0iHdf2mFTyCWmeLAQbdc |
151 |
UtzIehsZI/PaVehhaYz6WuvY/EAsWFQBWCRDjMb9mAim5DES/Q0nyh7C051ROb58 |
152 |
jbwJ8832xwLLYU0kNoMw81GYBNsBKED+MkAlhKvxIJ53VrcwtSdBM/6Kc0udcVCa |
153 |
CxzxhQeWvtT/CSz1ggx+fE1gmOpzSDiBCmSjYB0WNorMxSkPiZLRzfLlB1sQt8YQ |
154 |
wyZTzLOFQhnqMBwC6qK4KZXmTaLE2n92GNMuyiD9Ts31QBD8nnvoJjOt5cHjQfGt |
155 |
DToYyg4gb25QjbNlccmcsVrUl2WdhtOjekhqqRvpE5VIM5oqByTlmL3wA/0+1ijq |
156 |
Gp5r4GsShLaTOKRmAlYabA51MXknsk+TTN/5MS4UuI5VY9tMsC99l2azbLOf5xKd |
157 |
kE8J5di3uDeFSzBMpSYX1iILgkw/TR5DoIphYfs7ejysCy5i4//yfhMWJFFeppaK |
158 |
CzijcN3MbwUvqxa9cEi6QE4byLzje1NfUekCragtOfI4N8r9c5J3ymwa9ZSVsKBt |
159 |
Kzoh7vRuuWWRyIUhOoyLSgX426SZutVZ+uZtAk0fW/1jhZX9klsTR6+VWaygz6Yc |
160 |
1lFVBWhQQFfF1K3TtaPN |
161 |
=Szcn |
162 |
-----END PGP SIGNATURE----- |