Gentoo Archives: gentoo-council

From: Ferris McCormick <fmccor@g.o>
To: gentoo-council <gentoo-council@l.g.o>
Subject: Re: [gentoo-council] User Relations authority
Date: Thu, 10 Jul 2008 13:55:34
Message-Id: 1215698128.12648.290.camel@liasis.inforead.com
In Reply to: Re: [gentoo-council] User Relations authority by "Jorge Manuel B. S. Vicetto"
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)

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-council] User Relations authority "Petteri Räty" <betelgeuse@g.o>
Re: [gentoo-council] User Relations authority Donnie Berkholz <dberkholz@g.o>