Norton Imperial Labs

Table of Contents

About

For a while, we tried starting a hackerspace in San Francisco as an alternative to Noisebridge and Double Union. Building a community from the ground up, hoping to find a way to solve the problems that lead to me leaving HeatSync Labs and ultimately Arizona, the problems that caused Noisebridge to have a huge number of ex-patriots and enemies. We're the first hackerspace to adopt a Community Working Group pattern1, which I was really proud of and one of the first to use Discourse instead of a mailing list.

ICEBOX Project Tree   ICEBOX NIL

Tasks

Bylaws

  • DONE Form CWG
    • DONE Draft Policies provision for the CWG

    • DONE Draft Code of Conduct

    • DONE Send tom and hypatia an email to meet up this weekend

    • DONE Find CWG members

Space

Infrastructure/Ops

Notes   NOTE

Community Working Group

Proposal: Form Community Working Group to ensure community integrity ==================================================================

This document is a work in progress and is a list of test cases, not representative of a legal doc covering these ideas.

Abstract


In past interactions with hackerspaces, I've come to realize that a typical board/membership relationship does not scale well to properly handle drama and conflict within a community as it grows. While a typical board is usually solely empowered to address interpersonal conflict within a hackerspace, they rarely have the amount of bandwidth to handle these, and they are rarely trained in conflict management and mediation. The other side of the spectrum, airing grievances to the general discussion list is oftentimes an unsafe idea, for example in cases of harassment or issues beyond petty resource contention. I believe that a middle ground can be struck, however.

A construct which has been employed successfully within open source communities I have contributed to in the past has been the idea of a dedicated Community Working Group, tasked with the single goal of ensuring their communities are safe spaces by enforcing their community's Code of Conduct. These groups recieve mediation and conflict management training and are not weighed down with the work of both keeping a community pointed in the right direction while also addressing those who are unable to reorient themselves properly and be excellent.

The formation of a CWG does not imply that the board is inept or unable to deal with the issues of a community but is meant to empower both the board and the community to build the best possible space with the best resources and training that we have to offer. In addition, it points to our space as an example of a safe space for marginalized groups by telling trolls that their behavior will be unacceptable and easily handled.

For background, please read over both [KDE]2's and [Fedora]3's implementation of the CWG and Code of Conduct

S1 Code of Conduct


The driving force behind the Community Working Group is the Code of Conduct, a document which describes what constitutes a "good member" of our community. A concise and human-readible document along the lines the existing hackerspace mantra of "Don't be a dick" may well be enough of a Code of Conduct, while a longer document such as the KDE and Fedora documents may come across as a more legitimate call to action for a community when a time to act does come to fruition. My personal opinion is that the KDE CoC proves to be a good middle ground, where five concise rules form its basis.

S2 Community Working Group


The CWG enforce the Code of Conduct, in short, through mediation and conflict resolution. The CWG is to be formed of at least three and no more than seven active membership (FIXME: when we have defined roles, we should add that here).

S2-1 Formation of CWG


The CWG membership is to be appointed by the Board, with a ratification given by greater than 51% of the active membership (as defined above). Appointment of the CWG is to take place halfway in to the current board administration. The appointment period will be equal to that of the board's appointment period, such that a new CWG will be formed halfway through each board period.

S2-2 Reformation of CWG


Members of the CWG can step down at any time through an email to the board and CWG main communication channels. New members will be appointed by the board and ratified to serve through to the end of the CWG's appointment period.

S2-3 Available Infrastructure


The CWG will have a private mailing list provided by the space as a place where members can bring issues to the CWG, and where CWG issues can be discussed and debated in privacy. As with all infrastructure provided by the space, the trust of the infrastructure team is assumed.

Upon appointment, each member of the CWG will receive mediation training, paid for (if necessary) from the space's general fund.

As needed, the CWG may petition the board for other infrastructure or do-ocracy it themselves.

S2-4 Bringing Issue to the CWG


Member conflicts and violation of the CoC can be presented to the CWG via an e-mail to the CWG private mailing list. At this point, the CWG will investigate and enter a mediation period with the people involved in the conflict. All communication with the CWG and individual CWG members are to be held in confidence of all parties involved.

S2-5 CWG Recommendations


After the CWG has engaged in mediation and attempted conflict resolution, they may opt to give a set of recommendations to the board if they believe the the issue is otherwise intractable. There will be a clause in the by-laws entreating the Board to act on these recomendations per S2-6 below.

A base set of reasonable actions should be set as the community default by the first formed CWG and Board. For example (cribbed from [KDE's stormy day proposal]4), this could involve, for example, stripping a given member of access to the (meat|net)space for two weeks, and a probationary period after that. Members who follow through on the CWG's recommendations should be considered in good standing once they've completed the recommendations.

S2-6 Ensuring the Integrity of the CWG and Board


To ensure that the board does not usurp the recommendations and opinions of the CWG, the bylaws should contain a nuclear trigger, wherein should the board fail to follow the recommendations of the CWG, both the CWG and Board will be dissolved and the membership will elect a new board, who will in turn appoint a new CWG. The membership breakdown of the new board and CWG do not have to be mutually exclusive of the previous board and CWG, however, this gives the wider community the ability to easy remove those in power who wish to retain a possibly harmful status quo. An easy visual of this is as follows:

  • CWG presents findings and recommended actions coming from a conflict mediation period.
  • The board votes on enacting the findings.
  • Should they decide against that, the CWG and board will inform the general membership that their groups have been dissolved per the by-laws.
    • General nomination and election of the board takes place per bylaws
    • Appointment of the CWG per S2-1 of this proposal.

Board and CWG periods at this point are not reset, the new board will serve out the rest of the old board's term, and the new CWG will serve out the rest of the old CWG's term.

In the case of a conflict of interest between any members of the CWG and those involved in a given conflict, the CWG member should recuse themselves from discussion and mediation, allowing the other members to handle the situation.

Additionally, the membership may request that the CWG prepare a report on a given conflict to ensure that the community integrity is maintained and that the CWG has acted in due-diligience to resolve the issue at hand. These audits should be free of confidential information, and only inform the wider membership of the number of times the CWG engaged in mediation regarding a given conflict, the length of investigation and inquiry, and the final recommendations the CWG delivered to the board. These reports should be presented similar to Appendix B of the KDE CWG charter.

Conclusion


In short, adopting the model of KDE's community working group will ensure that we have a safe space for people of all backgrounds, skills and interests to hack on their passions, and we will have a working group trained to handle the situations which will inevitably arise when people disagree on who is being inexcellent and who is just a poisonous person within our community. The adoption of a CWG who has the teeth to handle these issues will serve as an indicator that our space is a welcoming and open space for those who want a safe space to hack while simultaneously telling poisonous people that their behavior will not be tolerated.

This proposal still needs to be fleshed out a bit, we need to find groups willing to train moderators for free/cheap, we need to codify this in to our by-laws as necessary (ie, the so-called nuclear option), and probably more.

Why MediaWiki Sucks   NOTE

Random internal NIL tenants   NOTE

  • If we need locked member storage, we're doing something wrong
  • If someone is afraid of being stalked by cameras in the space, we're doing something wrong
  • If someone doesn't want to or isn't able to contribute to a particular discussion due to political reasons, we're doing something wrong
  • If someone isn't able to contribute to a particular discussion due to technological reasons, we're doing something wrong

Meeting Minutes

Recurring

CANCELLED Prep the meeting agenda in Git   CANCELLED

ICEBOX SFNIL Weekly Meeting

Code

See Also

Footnotes:

Author: Ryan Rix

Created: 2015-10-25 Sun 18:56

Validate XHTML 1.0