[KI-LC] Community Banning Thoughts

Brett McDowell email at brettmcdowell.com
Thu Dec 3 06:01:11 EST 2009


Joe raises a new question of scope... are we only talking about a process for protecting our mailing lists from abuses, or are we also talking about potentially even protecting our Work Groups/Discussion Groups from same, i.e. a process that theoretically could result in the removal of a person from WG/DG membership, conference calls, etc.?  I thought we were only talking about a mailing list policy (which is much easier to deal with).

If we are talking about mailing lists only, I have a suggestion that seems to align with Joe's recommendations.  But first, I want to point out that we already have an email list policy and I suggest we add to that vs. create something entirely new.  The Email policy we have is online here:

http://kantarainitiative.org/confluence/display/GI/Joining+Groups+and+Discussion+Lists+Policy

Some proposed next steps:

1) We publish our values in the Maillist Policy.  We should edit and tweak what we already have to get to the right context but we have some nice starting points.

From they bylaws we have a good start as follows:

The Organization has as its primary focus to foster identity community harmonization, interoperability, innovation and broad adoption [..] In furtherance of these efforts, the Organization and its Members shall seek to solicit the participation of all interested parties on a fair, equitable and open basis.

From our Goals (http://kantarainitiative.org/confluence/display/GI/Mission) we have even more content to work in:

* Accelerate marketplace adoption through clear messages, defined processes, and open community collaboration that brings vendors, deployers, individuals, and organizations together

* Bring together technical, business, legal, and policy experience to achieve holistic & trusted identity management solutions

* Establish an open and democratic governance model with no financial barrier to participation

* Implement an operational structure with nimble processes, procedures, and oversight, and a viable financial model

* Commit to open standards and encourage interoperable implementations from both the COTS product and open source development communities

* Foster positive dialogue across all relevant organizations to assure coordination, harmonization, and re-use of all applicable open content (specs, policy, etc.)

* Establish programs with strong branding for technical and operational output to promote interoperability, compliance and/or conformance

2) We describe in very simple terms what our conflict resolution process is.  I suggest the following boundary conditions:

- the first step is that someone has to complain to the list manager

- that the complaint be made public before escalation (I'm not sure if we want to provide anonymity to the accuser, thoughts?)

- the decision to take action should not be left in the hands of an individual.  I'd be fine with this being in the hands of the LC but noting that a list manager does have the authority to take immediate and temporary action per their own judgement if needed prior to the next opportunity for the LC to meet and discuss the matter.

- the ultimate outcome is "moderation" not "banning".  We can moderate individuals without subjecting the entire list to moderation.

- I suggest that a decision to "moderate" someone always be for a limited period of time that is specified up-front

3) Whatever we add to the policy be approved by both LC and BoT

That's all I've got thus far.



Brett McDowell  |  http://info.brettmcdowell.com  |  http://KantaraInitiative.org

On Dec 2, 2009, at 8:20 PM, Joe Andrieu wrote:

> On the call today, I was asked to summarize some thoughts about rules & 
> procedures for maintaining community coherence by banning particular 
> individuals from meetings and/or online conversations (emails, forums, 
> wikis, etc.)
> 
> As background, it is my understanding that this is timely because of 
> issues that came up recently with the OpenID Foundation regarding 
> inappropriate comments and the subsequent banning of the individual who 
> made those comments.
> 
> Also, I understand some have proposed looking at the microformats 
> mechanisms for moderating community participation. I have had my own 
> run-ins with the microformats approach, having been banned temporarily, 
> ironically, for trying to raise questions about the banning process (in 
> regards to the banning of another community member). So, I find the 
> microformats process problematic.
> 
> Here are some principles I would like to suggest as a foundation for our 
> own policy--including how we go about creating it.
> 
> First, process over content. Define a process for addressing 
> inappropriate or unwelcome behavior, rather than attempting to define 
> what is or is not appropriate. Every community defines its own norms, 
> and norms change over time.  Rather than attempting to define the 
> behavior, let's define the process we will use when a community finds a 
> member acting in a way that is inappropriate in the eyes of the 
> community as a whole.
> 
> Second, proactive rather than proscriptive. To the extent that we do 
> need to specify a boundary for acceptable and unacceptable behavior, so 
> so by stating the behavior we are looking for, rather than behavior that 
> is inappropriate. It is essentially impossible to list all possible bad 
> behavior--any such list would be incomplete. In contrast, it is possible 
> to proactively state our community behavior goals in a clear, concise 
> way. Then, we can manage exceptions to those goals when they arise.
> 
> Third, distributed rather than centralized application. Allow each 
> workgroup to be the primary determinate of what is acceptable behavior 
> and what isn't for their activities. Each work group is a 
> microcommunity; while the Kantara community at large embodies a set of 
> shared norms, the individual work groups have the closest perspective in 
> any given incident, both to the context of the behavior and the history 
> of the individual(s) engaged. Should the banned party feel the process 
> was unfair at the work group level, there should be an appeal mechanism 
> to the full Kantara Leadership Council. Focus on a standard process 
> creates benefit from a community-tested means for each work group to 
> resolve its issues. So, standardize the process, but distribute its 
> operation.
> 
> Fourth, transparent, documented, and accountable. Banning from comunity 
> activity is the harshest form of correction we have available to us 
> (prior to resorting to legal or criminal systems). As such, it should be 
> used judiciously and in a manner open to scrutiny by the rest of the 
> community. Secret panels, backroom hearings, and anonymous voting 
> undermine the ability for a representative leadership to maintain 
> credibility with members.  All proceedings related to banning should be 
> public and available in a static form (permalinked documentation) in 
> what is effectively the Kantara public record, including the authorship 
> of complaints, witnesses, participants in the debate, defenses, 
> rebuttals, and the final votes leading to acquital or censure.
> 
> Fifth, separation of intervention from working processes. Arguments and 
> debates over banning and related behavior can quickly swamp the 
> productive channels of collaboration. Since Kantara exists for the 
> purposes of developing working solutions for Identity and /not/ as a 
> bureaucratic or judicial end in itself, the banning and associated 
> review & appeal processes should be cleanly separated from the regular 
> working meetings of the work groups.  We should provide a mechanism 
> where offending behavior can be called out, the individual notified of 
> their disruption, and a judgment call made by the moderator/host of the 
> activity effected if the behavior is so disruptive as to need immediate 
> intervention, e.g., calling security to get the raving beligerant drunk 
> out of the work group's session. Then, all subsequent processes related 
> to that intervention should be off topic for the work group proper, 
> instead channeled to an appropriate, quasi-public forum for resolving 
> the issue in due process.
> 
> Sixth, correction and not punishment. The goal of a community like 
> Kantara when banning an individual is to protect the community, not to 
> punish the individual. Vengeance isn't the appropriate role for a 
> collaborative organization. Intervention in the case of inappropriate 
> behavior should be judged by, and implemented for, its effectiveness in 
> ensuring a healthy, productive environment for quality work.
> 
> My guess is that this will eventually require an update to the operating 
> procedures allowing for the banning of individuals from particular 
> contexts (meetings, calls, mailing lists, entire work groups, etc.), 
> since currently any IPR signatory can participate in any work group. 
> And since we are talking about restricting the ability of an individual 
> to participate--in effect restricting their liberty--I feel strongly 
> that we should think through our goals and first seek consensus on the 
> desired outcome (with buy in from both the LC and BoT) before we start 
> hashing through proposed language other than strawman illustrations.
> 
> That's my $.02 on the topic. Hopefully we can craft something that 
> incorporates most if not all of these principles.
> 
> I look forward to feedback and commentary; I see this as a starting 
> point for figuring out how we want to deal with correctable problems.
> 
> Cheers,
> 
> -j
> 
> 
> -- 
> Joe Andrieu
> joe at switchbook.com
> +1 (805) 705-8651
> http://www.switchbook.com
> _______________________________________________
> LC mailing list
> LC at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/lc



More information about the LC mailing list