From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1KGwcP-0004mL-LC for garchives@archives.gentoo.org; Thu, 10 Jul 2008 13:55:34 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B905CE05DD; Thu, 10 Jul 2008 13:55:32 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 40B1EE05DD for ; Thu, 10 Jul 2008 13:55:32 +0000 (UTC) Received: from [192.168.1.213] (unknown [74.92.132.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 07313677DA; Thu, 10 Jul 2008 13:55:30 +0000 (UTC) Subject: Re: [gentoo-council] User Relations authority From: Ferris McCormick To: gentoo-council In-Reply-To: <4875F740.8050206@gentoo.org> References: <20080710054946.GB8666@comet> <4875F740.8050206@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-+MLbNvioxsjCr4FfSg+D" Date: Thu, 10 Jul 2008 13:55:28 +0000 Message-Id: <1215698128.12648.290.camel@liasis.inforead.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-council@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 X-Archives-Salt: ec31d2af-80d4-47a7-ac12-d35198e93fdb X-Archives-Hash: e13e7a86975e58ddaa3aeb67f90ffe2b --=-+MLbNvioxsjCr4FfSg+D Content-Type: text/plain Content-Transfer-Encoding: quoted-printable How big is gentoo-council@? Do we want this discussion there or on gentoo-dev@? I'd like this to reach a majority of our community because I think it has global implications. On Thu, 2008-07-10 at 11:49 +0000, Jorge Manuel B. S. Vicetto wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Donnie Berkholz wrote: > | From this month's agenda: > | > | User Relations authority > | ------------------------ > | > | Ferris asks: Does userrel have the authority to enforce the Code of > | Conduct on users in the same way devrel does for developers? >=20 > Yes, it does and it always had. If people want to invoke history, I'll > notice that imo, it was an option not to exercise that power. >=20 > | Preparation: Donnie will start a thread on the -council list. Post > | your opinion there. If everyone's posted in advance of the meeting, > | status check at meeting to see who's ready to vote. > | > | Goal: Reach a decision on-list no later than July 17. > | > | Please respond with your thoughts. > | >=20 > Ferris McCormick wrote: > | On Wed, 2008-07-09 at 01:40 -0700, Donnie Berkholz wrote: > |> On 05:30 Tue 01 Jul , Mike Frysinger wrote: > |> Here's the proposed agenda. Please respond if I forgot something, it's > |> unclear, or you have another suggestion. As before, since we have an > |> agenda in advance we won't be holding an open floor. > | > | I'll try to clarify my second agenda item on an absolute ban. Also I > | might edit my private request to make it pure vanilla and send it out, > | too, so that people may cross check my summary if they wish. If people > | want that, please respond saying so. > | > | 1. Your summary in the agenda is a fair reading of my request. > | However, I don't think it's realistic to expect a decision within a wee= k > | because I think instituting a policy and procedure allowing a complete > | ban forever from Gentoo requires at the least a change to the Code of > | Conduct and a review cycle for that. >=20 > Ferris, I know we disagree on this point, but my view is that this isn't > a new CoC, but instead a discussion on how to finally enforce the CoC in > extreme cases. > However, I agree with you that before we start doing it, we should have > clear rules and define procedures. >=20 > | 2. I can't spell out exactly what people are thinking of when > | discussing absolute bans, because I get the sense that different people > | have different ideas about just what we would mean by that. So I think > | the first step is for someone who advocates such a procedure needs to > | spell out exactly what it would be and why we would do it and under > | whose authority, etc. As probably everyone knows, I am absolutely > | opposed to any such thing, so I am not the person to do this. >=20 > Then let me present my old proposal about this issue. The two relevant > posts at the time were: >=20 > http://article.gmane.org/gmane.linux.gentoo.devel/46846 > http://article.gmane.org/gmane.linux.gentoo.devel/46897 >=20 > To summarize, my proposal was that we should have a method to "keep > away" people that do nothing but cause continuous issues - this is about > the "poisonous people" that are long-time and repeated offenders. > As I've stated back then "I believe that the greatest reward anyone can > have to participate in Gentoo is getting credit for work done on Gentoo. > As such, as a last measure, we must be ready to deny such contribution > from banned users." I don't think I've ever seen anyone at all who does nothing but continually causs "issues" and so qualifies as poisonous. We have a large community and everyone is abrasive at times, and everyone gets abuse at times (even me, but probably not from people you have in mind as "poisonous", if you have any). But I consider this just a normal part of doing business and can't imagine what it would take to get me to make a formal complaint about it. For example, I have had little contact with Linus Torvalds, but I have had a fair amount of contact with David Miller (davem --- the sparc kernel developer). I'm pretty sure that davem would seem more "poisonous" to us than anyone we've ever seen in Gentoo, and by reputation, Linus makes davem look like a pussy cat. (Although davem seems to be mellowing.) But I rather doubt that if for some reason either one started participating in Gentoo that we'd consider banning them or refusing their contributions. :) > As I've stated, that doesn't mean we don't accept the work someone does > upstream. Also, to avoid any doubts, I'm not suggesting we use someone's > work without giving him/her the credit - quite the opposite. Exactly > because of that, we must be ready to have additional work and not accept > their work and find an internal solution. About the security patches, if > they're provided by upstream or to upstream, there's no issue with them. > If they're provided directly to us, are we really that "bad" that in > such cases we're unable to find another contributor or to patch > ourselves the security flaw? >=20 How do we or anyone else gain from that? Personally, I think we should be open to improvements from anyone wishing to provide them as long as we don't run into trademark or copyrignt or licensing issues. > Let others present different proposals. >=20 > | 3. So, I don't think we can reach a decision on anything until we are > | all clear on what we are deciding on. > | > | 4. Here's what I think is meant by a complete ban. *These are only my > | own inferences from reading between the lines and trying to put > | different comments together in some coherent fashion.* > | Under some rather unclear conditions, some combination of > | devrel/userrel/trustees/infra could decide to impose a complete, > | permanent ban on a member (user or, I suppose developer) of our > | community. This would have the following effects: >=20 > Some people seem to support that userrel can make such decisions on its > own. As I've stated, as an userrel member, I was willing to involve > other teams. We also need to agree to which body should appeals be sent. >=20 I would not support giving userrel that authority or userrel+devrel that authority. Now, I oppose this absolutely. But in general I don't thing any group(s) in gentoo should have such sweeping authority to make such major decisions secretely in private. If we want to impose such a ban on someone, we really should have the courage and resolve to work in public. I really hate "Star Chamber" like actions, and especially in a volunteer organization like Gentoo which prides itself in being open. > | a. The person could post to no gentoo mailing list; > | b. The person could not post to gentoo bugzilla; >=20 > check >=20 > | c. The person could not participate in #gentoo- IRC > | channels (although this runs into conflict with individual > | channel policy); >=20 > I think the proposal was more along #gentoo-dev, #gentoo and a few other > channels. This point was to prevent people from abusing irc channels and > in the case of #gentoo-dev to prevent other devs from giving +v on > moderated channels to people that keep abusing them. >=20 > | d. The person could not contribute to gentoo (hence my corner > | case of a security fix) except perhaps through a proxy; >=20 > See the above reasoning for my proposal >=20 > | e. (Perhaps any upstream projects in which the person banned > | would be notified of the ban??? --- I'm not sure). >=20 > My comment about this has always been that in extreme cases and if we > have a close partnership with upstream, we might want to share with them > our decision and let them judge for themselves if the actions that made > such person be banned on Gentoo are relevant to them or not. >=20 Why? It's hardly our concern who participates upstream. > | 5. I am told that nothing is forever, and that if whatever problems > | triggered such a ban were corrected, the ban might be lifted. I note, > | however, that since the banned person could not participate in Gentoo > | things, as a practical matter we'd never know if anything was corrected > | or not. (Except through 3rd parties.) >=20 > The point here is that such a decision is not terminal. If people feel > more comfortable about it, don't call it permanent bans, but call it a > ban until further notice. What's the practical difference? And why not make it something sensible and definite? The authority to lift an indefinite ban most likely rests with whoever imposed it in the first place, and that doesn't provide for much. >=20 > | 6. Presumably, all of this would be done in secret and whoever is bein= g > | hit by such a ban would have no opportunity to respond before the ban's > | imposition. I suppose there would be a right to appeal to council, > | assuming council took no part in deciding on the ban. >=20 > I assume what you mean here is that there would be no attempt of > mediation with said person. As my proposal states this is an *extreme* > decision meant only for *long-time* and *repeated* offenders. When we > get there, there's no possibility for mediation - that's something that > would have been tried a long time before we get there. See above. And as i said, I've never seen anyone who fits such a profile, so perhaps we're spending a lot of time here defining how we treat the empty set. >=20 > | 7. [Argument] I view this as a pretty major change in how Gentoo > | operates. So someone needs to clarify my inferences in paragraph 4, an= d > | then we should think very carefully about it before allowing for any > | such practice. >=20 > I've replied above. >=20 > | 8. [Argument] I note that we are likely to institute some form of > | possible moderation for the gentoo-dev mailing list (presumably based o= n > | Code of Conduct violations), and if we do that, it effectively satisfie= s > | the intent of any absolute ban, but is not nearly so traumatic to the > | system. I note that this is a minority view among those who have > | discussed this. >=20 > Ferris, I do hope the moderation will prevent so many abuses on the mls, > but it alone won't change people's mindsets and actions. Although posts > can be moderated, it doesn't mean that people will stop trying to send > abusive mails and that a few might even get to the lists. Also, it > doesn't address irc, bugzilla and other mediums abuse. >=20 If we have your hypothetical poisonous person running around loose somewhere and put him (or her) into a must-be-moderated list for gentoo-dev, the problem there should disappear because posts will be shunted to the moderators. #gentoo-dev is a more general concern than just a few specific people and falls generally under Code of Conduct for immediate correction. Bugzilla looks like a bigger problem than it is, because when it explodes it can be spectacular. But it is not limited to one or two people, either (even I have lost control on bugzilla, and I generally appear pretty calm and rational, I think). > | Donnie, > | I don't know if that clarifies anything or just makes things more > | confusing. It's the best I can come up with. > | > | Regards, > | Ferris >=20 > - -- > Regards, >=20 > Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org > Gentoo- forums / Userrel / SPARC / KDE > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >=20 > iEYEARECAAYFAkh19z8ACgkQcAWygvVEyAJYbACgnAIEcXC1xyR3ZffRkCtLqyVJ > /w0AnA3u+58ui3/Ih/aLvjXoL2bZwn/v > =3DM4kk > -----END PGP SIGNATURE----- Jorge, you know, if you and I were both forced to come up with a list of five poisonous people to consider for application of such a ban, I suspect their intersection might be empty. What then? It is my view that both userrel and devrel may enforce the Code of Conduct, but also Code of Conduct should be limited to quick response to immediate situations. I think devrel and userrel are the wrong bodies to be rooting around in the past if that's what you are proposing. Neither of us is set up to do that. We act on current behavior, and if discipline is warranted, then we can take to past behavior for guidance if we wish. I don't think anyone in Gentoo currently has the charter to look at the community and say "X has been causing trouble long enough --- let's just boot X." Nor do I think we want anyone to have such authority --- surely we're more tolerant and flexible than that. I've gone on too long once again. Others, please respond. Regards, Ferris --=20 Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees) --=-+MLbNvioxsjCr4FfSg+D Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkh2FNAACgkQQa6M3+I///dr8wCfUZzevbRYyNAzYMhNVxSq2gw6 DIIAoNOjImkrohSte8KFyazyTfTPW9aI =b0F0 -----END PGP SIGNATURE----- --=-+MLbNvioxsjCr4FfSg+D-- -- gentoo-council@lists.gentoo.org mailing list