No, it doesn't sound that reasonable to me, actually. There's a code of conduct which has been developed the way Code4Lib develops things: ie the work's been done by people who're interested in doing the work. What's special about anti-harassment that it alone should bear the burden of bureacracy?

Is there really anything so controversial about "If you harass people, and organisers ask you to stop, and you don't stop, then organisers may kick you out of whatever the context is"?  This is just not that ambiguous. And honestly I'm not terribly comfortable when the conversation starts to get all waffly about whether or not we should expect people to commit to something that is basic human decency and a vital part of the social contract. Why would we be more worried even in the abstract about an obdurate harasser than about the comfort of the people zie's harassing?

You may not like the word "uncomfortable" (though you're happy enough to use "uneasy") but why *shouldn't* we have as a priority to ensure the comfort of members in our community? There's a vast difference between being uncomfortable because you're not familiar with Python and being uncomfortable because someone's harassing you and I think everyone here is clever enough not to conflate the two.

--And how did we get from "The code of conduct is sufficient so let's not overthink things!" to "Wait, we need to implement procedures to vote on the code of conduct!" anyway??


-----Original Message-----
From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Shaun Ellis
Sent: Friday, 25 January 2013 10:38 AM
To: [log in to unmask]
Subject: Re: [CODE4LIB] Group Decision Making (was Zoia)

> I am uneasy about coming up with a policy for banning people (from
> what?) and voting on it, before it's demonstrated that it's even 
> needed. Can't we just tackle these issues as they come up, in context, 
> rather than in the abstract?

I share your unease.  But deciding to situations in context without a set of guidelines is simply another kind of policy.  I'm actually more uneasy about ambiguity over what is acceptable, and no agreed upon way to handle it.

I don't think the current policy is ready to "go to vote" as it seems there is still some debate over what it should cover and exactly what type of behavior it is meant to prevent.

I suggest there is a set time period to submit objections as GitHub issues and resolve them before we vote.  Whatever issues can't get resolved end up in a branch/fork.  In the end, we vote on each of the forks, or "no policy at all".

Does that sound reasonable?

Shaun Ellis
User Interace Developer, Digital Initiatives Princeton University Library

P Please consider the environment before you print this email.
"The contents of this e-mail (including any attachments) may be confidential and/or subject to copyright. Any unauthorised use, 
distribution, or copying of the contents is expressly prohibited.  If you have received this e-mail in error, please advise the sender 
by return e-mail or telephone and then delete this e-mail together with all attachments from your system."