User:Tecknow/Code of Conduct Development
Pitfalls in code of conduct development
Structural pitfalls
The temptation to assume it is a contract
It's understandable that many people, especially in a makerspace, would imagine that a code of conduct (CoC) is like a shrink-wrap license or other contract, and therefore assume everyone in the space must agree to the CoC in some way. Licenses and contracts are everywhere. Websites and commercial software have user agreements; open source software and the creative commons are communities and movements held together by licenses; even many of the physical things that we buy often try to insist that they're governed by contracts and not as sales, because they contain software or for other reasons. When you combine this with the reciprocal desires to give people fair warning about what expectations are and the desire to avoid surprises, it's easy to see the temptation to view the CoC as a contract.
Contracts are not the whole of the law
The force of a code of conduct for a private space or event does not come from contract law. It's backed up by the authority to revoke someone's right to be in the space, to declare someone a trespasser if needed. Its power therefore comes from property law. It doesn't really bind the visitors and ordinary members who come into the space. It explains how the power of the owner or leaseholder, which already exists, will be used. It protects the organization from accusations of using their power recklessly.
This distinction is important. The onus is always on the people with the power to use it judiciously. Their responsibility to the community is not nullified or even necessarily diminished if someone says they weren't warned or found their way into the space without accepting the CoC.
The CoC should be as accessible as possible and then followed regardless. People are not required to agree to a code of conduct when they visit restaurants, stores, and other businesses yet those businesses can still control their space. The same is true here.
Disclaimer
I'm not a lawyer, I'm definitely not your lawyer, and the above explanation is not legal advice. I'm confident of the above explanation because I've lived through its application so many times. But a narrow experience doesn't provide general expertise. Many things are, or derive their power from, contracts, such as the membership agreement at PS1.
A personal disclosure
I will always, always, take a dim view of attempts to cast a code of conduct as a contract requiring agreement. I have spent a great deal of time in convention spaces and people who are determined to behave badly, such as by exposing convention-goers to hate speech or symbols, very often try to argue that since they didn't buy a badge they're not actually attending the convention so the CoC doesn't apply and the convention cannot ask them to stop or remove them. Thankfully this essentially never works. But treating a CoC like a contract that requires everyone's agreement to have force validates their efforts to find loopholes that will allow them to continue doing harm.
The temptation to make it comprehensive
One document for everyone
Many codes of conduct are quite short. This is understandable, because it's foundational. It applies to a wide group of people, and if it is meant for them to follow it, they should be able to easily read and remember it. However, many conventions, events, and even other types of hackerspaces have advantages in accomplishing this that don't apply to community hackerspaces like PS:1.
Even a game day held at a friendly local game store can rely on employees and event organizers to read and follow additional documentation. These stricter, more detailed expectations help apply the CoC to everyone according to the event's goals and values without increasing expectations on ordinary attendees. Similarly, a convention CoC applies to everyone but there are increasing levels of training, documentation, and expectations for volunteers, staff, department heads, and so on.
Even hackerspaces attached to libraries and universities have some of these advantages. In addition to ordinary employees as described above, libraries have librarians who receive extensive training in the values of their profession and how to apply them, often in the face of resistance. Universities have student handbooks that can contain all the specificity and nuance that a space's CoC can only allude to and rely on.
At community hackerspaces like PS:1 the barrier to volunteering can be virtually nonexistent. This has many advantages, but it means that it isn't always clear when and how to introduce additional documentation and training, and raise expectations. It's entirely reasonable and probably necessary to hold people with more power in a community to higher standards in enacting the community's values. But the flat structure of community makerspaces can make this harder to accomplish. The temptation is to use the CoC to create a single document that's just as complete for event organizers as it is for the most casual member. This isn't actually reasonable, and leads to the next temptation, to make it a single comprehensive document.
One document for everything
A space's CoC is probably one of the most, or perhaps the single most, universally applicable documents the organization has. And, in part because of the relatively flat structure described above, there are fairly few other documents that we expect community members to know and follow. There are the safety waiver, the membership agreement, and the bylaws. This creates a strong temptation to try and make the most applicable documents as comprehensive as possible.
There are other documents, such as the training materials for certification on various tools, and operating procedures on the wiki. However, we don't expect ordinary members to read and remember training materials for tools they don't plan to use, or details about the organization's IT infrastructure.
Good guidelines for applying the CoC need to be adaptable to new situations, and they need to maintain some institutional memory so that decisions can be made, disagreements can reach a recorded conclusion, and mistakes that have been made in the past can be avoided in the future.
Places to put the details
The CoC
Because it is the most widely applicable, it may be very tempting to put all the necessary detail in the CoC itself. This is not a good idea. The CoC is meant to express the values of the space and make people who can follow it feel welcome and safe. If it's too long, it won't do that and can feel like it is meant to hide traps in the fine print instead. People will be less likely to read and remember it, and they certainly won't reread it every time it is updated if it changes often and is already very long.
The safety waiver
This is also tempting because we expect most people, even non-member visitors to sign it. But it is almost certainly a mistake to burden a short, clear document about safety and liability with other things, let alone the detail that would be required for this. Added details make it harder to apply for its specific, narrow, and important purpose. Also, as with some of the other options, it might be necessary to ask people to re-read and re-sign it constantly. It's not responsive to change, and the necessary institutional memory would only be a distraction in this case.
The membership agreement
The membership agreement is widely - though not universally - applicable and explicitly signed by members. But it can't serve a welcoming purpose for visitors, and it has the same problems with needing to be re-read and re-signed frequently as the safety waiver would have.
The bylaws
This may seem like the natural place for all the necessary detail. The bylaws can be as long as they need to be, and they govern the organization without the expectation that every member internalize everything about them. They don't require every member to individually sign off on them. But this is not a good idea. The bylaws necessarily govern things like organizational structure and how money will be spent. For this and other reasons, they are often difficult to change. Commingling governance and operational concerns is probably not a good idea, and the documents that lay out a structure or policy usually don't directly contain the history of how they were made no matter how important that information is.
Changing the bylaws requires a (possibly supermajority) vote of the membership. It's not a process intended to be responsive to change, and the structure of the bylaws is hostile to the inclusion of too much institutional memory.
False goals
There are many things that it is reasonable to want, but not reasonable to seek. Following are some sections on false goals, why they might be attractive and why they aren't achievable or would conflict with important and obtainable objectives for the CoC.
The temptation to build a system that can only do good
Many people in the community are builders and designers, some of us are highly trained. We want to create the best design for the organization that we can, and especially if we've lived through the decline or subversion of organizations before - and many of us have - we want to prevent the same problems from reoccurring. It's an easy slide from wanting to prevent past mistakes to wanting to prevent every mistake, and from there to the temptation to design the perfect rules. A perfect organization would continue to advance its mission and serve its values even if operated by people who want to do harm, or oppose those values.
It is important to realize that such a perfect organization cannot exist. Know this with the same certainty that you know perpetual motion cannot exist. I rarely take a position so strong, and I say this with great care. Imagine that such a perfect organization did exist. It can only be used to advance its goals and values, no matter how the people operating it feel about them. Anyone who opposes the organization would just quit. And if there weren't enough people aligned with the organization to keep it operating, it would cease to exist.
So, even under the most advantageous of hypothetical assumptions there is a maximum number of positions in an organization that can be filled with people opposed to the organization before it falls apart. We can, should, and must work to make sure that the organization is robust. One person or a small group of people shouldn't be able to disrupt or destroy the organization for everyone else. But the system can never be perfect. Organizations, like any other machine, always have limitations and trade-offs.
We must not allow the perfect to prevent the good. We must not allow the impossibility of doing everything to prevent us from doing anything. We must design the best rules we can, but no better.
The temptation to eliminate judgement
It's very tempting to try and design mechanistic rules where it's always clear if a rule has been broken, and anything that can be done without clearly breaking a rule is acceptable. This too is not actually possible. To do this we'd need to be able to accurately and precisely describe not only the set of all possible behaviors, but exact boundaries within it. Any attempt at such a ruleset quickly runs into the coastline paradox (The perimeter of arbitrarily complex shapes may not be exact), the curse of dimensionality (The more complex something is the more it is defined by corner cases), and other problems. Any rule that's exact enough to eliminate judgement is necessarily going to be incomplete and allow the spirit of the rule to be violated. Any rule that's flexible enough to apply to unexpected situations will require judgement.
Additionally complicating this is that human behavior is dynamic. People change their behavior in response to the rules. This tends to draw people towards ambiguity and corner cases even when they're acting without malice. It's possible to write fairly complete sets of rules for machines with limited memory and environmental feedback. That simply doesn't describe humans.
Attempting to take disagreement out of conflict
The desire for perfectly unambiguous rules often comes from a desire to avoid ambiguity in conflict. People might want to know in advance that their behavior is definitely acceptable and they can't be faulted for it. And when we must resolve conflicts we might wish for rules so exact that anyone who broke them would be forced to acknowledge that they did. Unfortunately there's no way to force someone to share another person's interpretation of the rules or of events. People do sometimes acknowledge that they did wrong, but in those cases they don't need to argue about the exactness of the rules or about what happened. The fact that dispute resolution sometimes doesn't require arguing about the rules gives us the false hope that we can invent a system where it's never required. Unfortunately this cannot work.
The temptation to view it as a recipe
If we can't create rules where we are confident that nothing bad will happen, can we at least create rules where we're sure that something good will eventually happen? Can we use the CoC to make sure that we only get good members? Can we create rules that if followed will make good members into better members?
This can seem reasonable at first because the community almost certainly should communicate what makes a good member. We want to give people the opportunity to improve themselves and invest more in the community if that is what they want. Why shouldn't we use one of the most widely-applicable documents to communicate how to do those things? And if we're going to do that, why can't it just be part of the CoC?
Unfortunately this falls apart for a few different reasons. The most straightforward reason is that good enough is good enough. Casual members are welcome and not everyone is expected to invest heavily in the community or to increase their own commitments. Since the CoC applies to everyone, it can't both welcome casual members and set the expectation that everyone should improve.
Another reason that this will not work is that there are many different ways to be a good, even great member. Not all of which are immediately apparent or easy to measure. A good set of good members necessarily contains people with different skills and approaches because it's more capable than a group of good members that is homogeneous. Conversely even the greatest members are probably only casually involved in some important aspects of the community. The costs of setting the bar too high for the community would be catastrophic losses in commitment, culture, knowledge, and skill.
The temptation to view it as a teaching tool
The space has an interest in learning and teaching. Although this interest is focused on technical knowledge and skills, collaboration and all the associated social skills are necessary for many, many projects. I already said that the community should make it clear what makes a good member so that people can improve if they want to. If we can't guarantee that nothing bad can happen, and we can't guarantee that something good will definitely happen, but we still have to say what we want, can we at least use the CoC to teach people to behave better?
This is related to the impulse to use the CoC to require people to be good or better members, but tends to come into the foreground when there has been a problem. The previous point is about encouraging people to be the best version of themselves for the space, but this one is about using the CoC as a part of rehabilitation.
When someone is pushing the boundaries of the CoC, or has broken it, it's perfectly reasonable to want their behavior to improve. Even if they're interested in changing it will be necessary to communicate what better behavior looks like. This can be difficult to do, tedious to monitor, and require trust between the people giving and taking correction. It's understandable that we want to offload some of this work onto the CoC.
There are two major practical reasons this will not work, and a serious risk in looking at the CoC this way.
The purpose of the CoC is to make people feel welcome and safe, not to rehabilitate violators. Focusing on training people into following the CoC risks ignoring any ways that their behavior undermines the purpose of the CoC for other people. At its worst, viewing the CoC as someone's learning goals can lead to giving them almost unlimited chances to improve no matter how many times they don't measure up. People do improve and repair is often possible. Knowing that someone who has done harm is committed to not doing it again can strengthen a community tremendously. But focusing on helping people improve to the point of losing sight of the community overall will not help.
The simpler practical consideration is that the CoC is not a good place for documentation about disciplinary, mediation, and repair procedures. Even our expectations for what makes a good member probably don't belong in the CoC itself. It needs to be focused to be effective. The other practical concern is that bad behaviors and ways of improving them are both effectively unlimited. As described in the section on trying to eliminate the need for judgement, pre-planning too much increases the organization's vulnerability rather than reducing it.
What do we want the CoC to accomplish
An organization's right to control its own space is very powerful. With a few important exceptions such as barring certain types of discrimination in public accommodations, an organization can be as arbitrary and capricious in the use of its power as it would like. A welcoming organization does not want people to be afraid of that arbitrary power, or resort to using that power simply because it's not forbidden. One of the first things that a code of conduct for a private space or event does is offer people some assurances about when power will and won't be used.
These sorts of assurances are especially necessary in unfamiliar spaces. We feel comfortable navigating our friends' spaces because we know and trust them. We feel confident entering a restaurant or a shop because we understand the norms of commerce and the sorts of interactions that a business wants to have. Hackerspaces are not as familiar to most people, and even if they are familiar they are certainly more open-ended than a shop.
The CoC needs to make people feel welcome and safe. They need to have a basic understanding of the purpose of the organization and space. They need to feel confident that they can meet its expectations. And they need to have some trust that behavior that would interfere with their participation won't be tolerated.
