1 |
How big is gentoo-council@? Do we want this discussion there or on |
2 |
gentoo-dev@? I'd like this to reach a majority of our community because |
3 |
I think it has global implications. |
4 |
|
5 |
On Thu, 2008-07-10 at 11:49 +0000, Jorge Manuel B. S. Vicetto wrote: |
6 |
> -----BEGIN PGP SIGNED MESSAGE----- |
7 |
> Hash: SHA1 |
8 |
> |
9 |
> Donnie Berkholz wrote: |
10 |
> | From this month's agenda: |
11 |
> | |
12 |
> | User Relations authority |
13 |
> | ------------------------ |
14 |
> | |
15 |
> | Ferris asks: Does userrel have the authority to enforce the Code of |
16 |
> | Conduct on users in the same way devrel does for developers? |
17 |
> |
18 |
> Yes, it does and it always had. If people want to invoke history, I'll |
19 |
> notice that imo, it was an option not to exercise that power. |
20 |
> |
21 |
> | Preparation: Donnie will start a thread on the -council list. Post |
22 |
> | your opinion there. If everyone's posted in advance of the meeting, |
23 |
> | status check at meeting to see who's ready to vote. |
24 |
> | |
25 |
> | Goal: Reach a decision on-list no later than July 17. |
26 |
> | |
27 |
> | Please respond with your thoughts. |
28 |
> | |
29 |
> |
30 |
> Ferris McCormick wrote: |
31 |
> | On Wed, 2008-07-09 at 01:40 -0700, Donnie Berkholz wrote: |
32 |
> |> On 05:30 Tue 01 Jul , Mike Frysinger wrote: |
33 |
> |> Here's the proposed agenda. Please respond if I forgot something, it's |
34 |
> |> unclear, or you have another suggestion. As before, since we have an |
35 |
> |> agenda in advance we won't be holding an open floor. |
36 |
> | |
37 |
> | I'll try to clarify my second agenda item on an absolute ban. Also I |
38 |
> | might edit my private request to make it pure vanilla and send it out, |
39 |
> | too, so that people may cross check my summary if they wish. If people |
40 |
> | want that, please respond saying so. |
41 |
> | |
42 |
> | 1. Your summary in the agenda is a fair reading of my request. |
43 |
> | However, I don't think it's realistic to expect a decision within a week |
44 |
> | because I think instituting a policy and procedure allowing a complete |
45 |
> | ban forever from Gentoo requires at the least a change to the Code of |
46 |
> | Conduct and a review cycle for that. |
47 |
> |
48 |
> Ferris, I know we disagree on this point, but my view is that this isn't |
49 |
> a new CoC, but instead a discussion on how to finally enforce the CoC in |
50 |
> extreme cases. |
51 |
> However, I agree with you that before we start doing it, we should have |
52 |
> clear rules and define procedures. |
53 |
> |
54 |
> | 2. I can't spell out exactly what people are thinking of when |
55 |
> | discussing absolute bans, because I get the sense that different people |
56 |
> | have different ideas about just what we would mean by that. So I think |
57 |
> | the first step is for someone who advocates such a procedure needs to |
58 |
> | spell out exactly what it would be and why we would do it and under |
59 |
> | whose authority, etc. As probably everyone knows, I am absolutely |
60 |
> | opposed to any such thing, so I am not the person to do this. |
61 |
> |
62 |
> Then let me present my old proposal about this issue. The two relevant |
63 |
> posts at the time were: |
64 |
> |
65 |
> http://article.gmane.org/gmane.linux.gentoo.devel/46846 |
66 |
> http://article.gmane.org/gmane.linux.gentoo.devel/46897 |
67 |
> |
68 |
> To summarize, my proposal was that we should have a method to "keep |
69 |
> away" people that do nothing but cause continuous issues - this is about |
70 |
> the "poisonous people" that are long-time and repeated offenders. |
71 |
> As I've stated back then "I believe that the greatest reward anyone can |
72 |
> have to participate in Gentoo is getting credit for work done on Gentoo. |
73 |
> As such, as a last measure, we must be ready to deny such contribution |
74 |
> from banned users." |
75 |
|
76 |
I don't think I've ever seen anyone at all who does nothing but |
77 |
continually causs "issues" and so qualifies as poisonous. We have a |
78 |
large community and everyone is abrasive at times, and everyone gets |
79 |
abuse at times (even me, but probably not from people you have in mind |
80 |
as "poisonous", if you have any). But I consider this just a normal |
81 |
part of doing business and can't imagine what it would take to get me to |
82 |
make a formal complaint about it. |
83 |
|
84 |
For example, I have had little contact with Linus Torvalds, but I have |
85 |
had a fair amount of contact with David Miller (davem --- the sparc |
86 |
kernel developer). I'm pretty sure that davem would seem more |
87 |
"poisonous" to us than anyone we've ever seen in Gentoo, and by |
88 |
reputation, Linus makes davem look like a pussy cat. (Although davem |
89 |
seems to be mellowing.) But I rather doubt that if for some reason |
90 |
either one started participating in Gentoo that we'd consider banning |
91 |
them or refusing their contributions. :) |
92 |
|
93 |
> As I've stated, that doesn't mean we don't accept the work someone does |
94 |
> upstream. Also, to avoid any doubts, I'm not suggesting we use someone's |
95 |
> work without giving him/her the credit - quite the opposite. Exactly |
96 |
> because of that, we must be ready to have additional work and not accept |
97 |
> their work and find an internal solution. About the security patches, if |
98 |
> they're provided by upstream or to upstream, there's no issue with them. |
99 |
> If they're provided directly to us, are we really that "bad" that in |
100 |
> such cases we're unable to find another contributor or to patch |
101 |
> ourselves the security flaw? |
102 |
> |
103 |
|
104 |
How do we or anyone else gain from that? Personally, I think we should |
105 |
be open to improvements from anyone wishing to provide them as long as |
106 |
we don't run into trademark or copyrignt or licensing issues. |
107 |
|
108 |
|
109 |
> Let others present different proposals. |
110 |
> |
111 |
> | 3. So, I don't think we can reach a decision on anything until we are |
112 |
> | all clear on what we are deciding on. |
113 |
> | |
114 |
> | 4. Here's what I think is meant by a complete ban. *These are only my |
115 |
> | own inferences from reading between the lines and trying to put |
116 |
> | different comments together in some coherent fashion.* |
117 |
> | Under some rather unclear conditions, some combination of |
118 |
> | devrel/userrel/trustees/infra could decide to impose a complete, |
119 |
> | permanent ban on a member (user or, I suppose developer) of our |
120 |
> | community. This would have the following effects: |
121 |
> |
122 |
> Some people seem to support that userrel can make such decisions on its |
123 |
> own. As I've stated, as an userrel member, I was willing to involve |
124 |
> other teams. We also need to agree to which body should appeals be sent. |
125 |
> |
126 |
|
127 |
I would not support giving userrel that authority or userrel+devrel that |
128 |
authority. Now, I oppose this absolutely. But in general I don't thing |
129 |
any group(s) in gentoo should have such sweeping authority to make such |
130 |
major decisions secretely in private. If we want to impose such a ban |
131 |
on someone, we really should have the courage and resolve to work in |
132 |
public. |
133 |
|
134 |
I really hate "Star Chamber" like actions, and especially in a volunteer |
135 |
organization like Gentoo which prides itself in being open. |
136 |
|
137 |
|
138 |
> | a. The person could post to no gentoo mailing list; |
139 |
> | b. The person could not post to gentoo bugzilla; |
140 |
> |
141 |
> check |
142 |
> |
143 |
> | c. The person could not participate in #gentoo- IRC |
144 |
> | channels (although this runs into conflict with individual |
145 |
> | channel policy); |
146 |
> |
147 |
> I think the proposal was more along #gentoo-dev, #gentoo and a few other |
148 |
> channels. This point was to prevent people from abusing irc channels and |
149 |
> in the case of #gentoo-dev to prevent other devs from giving +v on |
150 |
> moderated channels to people that keep abusing them. |
151 |
> |
152 |
> | d. The person could not contribute to gentoo (hence my corner |
153 |
> | case of a security fix) except perhaps through a proxy; |
154 |
> |
155 |
> See the above reasoning for my proposal |
156 |
> |
157 |
> | e. (Perhaps any upstream projects in which the person banned |
158 |
> | would be notified of the ban??? --- I'm not sure). |
159 |
> |
160 |
> My comment about this has always been that in extreme cases and if we |
161 |
> have a close partnership with upstream, we might want to share with them |
162 |
> our decision and let them judge for themselves if the actions that made |
163 |
> such person be banned on Gentoo are relevant to them or not. |
164 |
> |
165 |
Why? It's hardly our concern who participates upstream. |
166 |
|
167 |
> | 5. I am told that nothing is forever, and that if whatever problems |
168 |
> | triggered such a ban were corrected, the ban might be lifted. I note, |
169 |
> | however, that since the banned person could not participate in Gentoo |
170 |
> | things, as a practical matter we'd never know if anything was corrected |
171 |
> | or not. (Except through 3rd parties.) |
172 |
> |
173 |
> The point here is that such a decision is not terminal. If people feel |
174 |
> more comfortable about it, don't call it permanent bans, but call it a |
175 |
> ban until further notice. |
176 |
|
177 |
What's the practical difference? And why not make it something sensible |
178 |
and definite? The authority to lift an indefinite ban most likely rests |
179 |
with whoever imposed it in the first place, and that doesn't provide for |
180 |
much. |
181 |
|
182 |
> |
183 |
> | 6. Presumably, all of this would be done in secret and whoever is being |
184 |
> | hit by such a ban would have no opportunity to respond before the ban's |
185 |
> | imposition. I suppose there would be a right to appeal to council, |
186 |
> | assuming council took no part in deciding on the ban. |
187 |
> |
188 |
> I assume what you mean here is that there would be no attempt of |
189 |
> mediation with said person. As my proposal states this is an *extreme* |
190 |
> decision meant only for *long-time* and *repeated* offenders. When we |
191 |
> get there, there's no possibility for mediation - that's something that |
192 |
> would have been tried a long time before we get there. |
193 |
|
194 |
See above. And as i said, I've never seen anyone who fits such a |
195 |
profile, so perhaps we're spending a lot of time here defining how we |
196 |
treat the empty set. |
197 |
|
198 |
> |
199 |
> | 7. [Argument] I view this as a pretty major change in how Gentoo |
200 |
> | operates. So someone needs to clarify my inferences in paragraph 4, and |
201 |
> | then we should think very carefully about it before allowing for any |
202 |
> | such practice. |
203 |
> |
204 |
> I've replied above. |
205 |
> |
206 |
> | 8. [Argument] I note that we are likely to institute some form of |
207 |
> | possible moderation for the gentoo-dev mailing list (presumably based on |
208 |
> | Code of Conduct violations), and if we do that, it effectively satisfies |
209 |
> | the intent of any absolute ban, but is not nearly so traumatic to the |
210 |
> | system. I note that this is a minority view among those who have |
211 |
> | discussed this. |
212 |
> |
213 |
> Ferris, I do hope the moderation will prevent so many abuses on the mls, |
214 |
> but it alone won't change people's mindsets and actions. Although posts |
215 |
> can be moderated, it doesn't mean that people will stop trying to send |
216 |
> abusive mails and that a few might even get to the lists. Also, it |
217 |
> doesn't address irc, bugzilla and other mediums abuse. |
218 |
> |
219 |
|
220 |
If we have your hypothetical poisonous person running around loose |
221 |
somewhere and put him (or her) into a must-be-moderated list for |
222 |
gentoo-dev, the problem there should disappear because posts will be |
223 |
shunted to the moderators. #gentoo-dev is a more general concern than |
224 |
just a few specific people and falls generally under Code of Conduct for |
225 |
immediate correction. Bugzilla looks like a bigger problem than it is, |
226 |
because when it explodes it can be spectacular. But it is not limited |
227 |
to one or two people, either (even I have lost control on bugzilla, and |
228 |
I generally appear pretty calm and rational, I think). |
229 |
|
230 |
> | Donnie, |
231 |
> | I don't know if that clarifies anything or just makes things more |
232 |
> | confusing. It's the best I can come up with. |
233 |
> | |
234 |
> | Regards, |
235 |
> | Ferris |
236 |
> |
237 |
> - -- |
238 |
> Regards, |
239 |
> |
240 |
> Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org |
241 |
> Gentoo- forums / Userrel / SPARC / KDE |
242 |
> -----BEGIN PGP SIGNATURE----- |
243 |
> Version: GnuPG v2.0.9 (GNU/Linux) |
244 |
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |
245 |
> |
246 |
> iEYEARECAAYFAkh19z8ACgkQcAWygvVEyAJYbACgnAIEcXC1xyR3ZffRkCtLqyVJ |
247 |
> /w0AnA3u+58ui3/Ih/aLvjXoL2bZwn/v |
248 |
> =M4kk |
249 |
> -----END PGP SIGNATURE----- |
250 |
|
251 |
Jorge, you know, if you and I were both forced to come up with a list of |
252 |
five poisonous people to consider for application of such a ban, I |
253 |
suspect their intersection might be empty. What then? |
254 |
|
255 |
It is my view that both userrel and devrel may enforce the Code of |
256 |
Conduct, but also Code of Conduct should be limited to quick response to |
257 |
immediate situations. |
258 |
|
259 |
I think devrel and userrel are the wrong bodies to be rooting around in |
260 |
the past if that's what you are proposing. Neither of us is set up to |
261 |
do that. We act on current behavior, and if discipline is warranted, |
262 |
then we can take to past behavior for guidance if we wish. I don't |
263 |
think anyone in Gentoo currently has the charter to look at the |
264 |
community and say "X has been causing trouble long enough --- let's just |
265 |
boot X." Nor do I think we want anyone to have such authority --- |
266 |
surely we're more tolerant and flexible than that. |
267 |
|
268 |
I've gone on too long once again. Others, please respond. |
269 |
|
270 |
Regards, |
271 |
Ferris |
272 |
-- |
273 |
Ferris McCormick (P44646, MI) <fmccor@g.o> |
274 |
Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees) |