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 1KGueV-00014o-3o for garchives@archives.gentoo.org; Thu, 10 Jul 2008 11:49:35 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2959CE05FB; Thu, 10 Jul 2008 11:49:34 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id D4998E05FB for ; Thu, 10 Jul 2008 11:49:33 +0000 (UTC) Received: from [172.28.2.137] (bl7-17-174.dsl.telepac.pt [85.240.17.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 5000066FF4 for ; Thu, 10 Jul 2008 11:49:32 +0000 (UTC) Message-ID: <4875F740.8050206@gentoo.org> Date: Thu, 10 Jul 2008 11:49:20 +0000 From: "Jorge Manuel B. S. Vicetto" User-Agent: Thunderbird 2.0.0.14 (X11/20080504) 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 To: gentoo-council Subject: Re: [gentoo-council] User Relations authority References: <20080710054946.GB8666@comet> In-Reply-To: <20080710054946.GB8666@comet> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: de7a747a-3231-42b7-a40e-ed1fb7ae4773 X-Archives-Hash: edb3a90e237f38525e6b6c3c8e9bf22e -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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? 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. | 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. | 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 week | 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. 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. | 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. Then let me present my old proposal about this issue. The two relevant posts at the time were: http://article.gmane.org/gmane.linux.gentoo.devel/46846 http://article.gmane.org/gmane.linux.gentoo.devel/46897 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." 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? Let others present different proposals. | 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: 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. | a. The person could post to no gentoo mailing list; | b. The person could not post to gentoo bugzilla; check | c. The person could not participate in #gentoo- IRC | channels (although this runs into conflict with individual | channel policy); 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. | d. The person could not contribute to gentoo (hence my corner | case of a security fix) except perhaps through a proxy; See the above reasoning for my proposal | e. (Perhaps any upstream projects in which the person banned | would be notified of the ban??? --- I'm not sure). 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. | 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.) 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. | 6. Presumably, all of this would be done in secret and whoever is being | 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. 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. | 7. [Argument] I view this as a pretty major change in how Gentoo | operates. So someone needs to clarify my inferences in paragraph 4, and | then we should think very carefully about it before allowing for any | such practice. I've replied above. | 8. [Argument] I note that we are likely to institute some form of | possible moderation for the gentoo-dev mailing list (presumably based on | Code of Conduct violations), and if we do that, it effectively satisfies | 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. 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. | 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 - -- Regards, 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 iEYEARECAAYFAkh19z8ACgkQcAWygvVEyAJYbACgnAIEcXC1xyR3ZffRkCtLqyVJ /w0AnA3u+58ui3/Ih/aLvjXoL2bZwn/v =M4kk -----END PGP SIGNATURE----- -- gentoo-council@lists.gentoo.org mailing list