This makes it rather hard to enforce then. If the community can’t ask someone to leave if they’re being abusive, then I think we wouldn’t be doing enough protect victims. What would you propose?
I suppose that could be rephrased to say “will be kicked of channels the mods control like gitter or GH” or asked to leave SD events if they show up. It is horizontal enough that someone could host an SD hackathon, and allow them to attend.
Yes yes. I was just getting bullets down for simplicity.
Then would you suggest that we add a note that mods can and should delegate responsibility during IRL events so that there’s a point person who can handle things during events?
Yes. Without a central authority enforcement is impossible. Which is also why horizontal communities are interesting
Members of the community, including the point of contact, can certainly ask someone to leave, if and when all other attempts to preserve a civilized conversation and a safe environment failed. And it is possible the person will refuse because there is no central authority. But since horizontal communities do not exist in Free Software, it is quite difficult to guess how this will go down. I propose we take our chances and try our best to be patient, open and inventive when and if that case presents itself.
Alternatively, I think organizers of events should be able to subscribe formally to this CoC, which would mean they are tasked with in-person enforcement and debriefing with a standing group such as a CoC committee (what you call “mods” in your summary).
Regarding @dachary’s point, while it’s true that enforcement can be tricky in a decentralized community, the notion of “subscribing” to a CoC could scale to multiple uses. For example, the operator(s) of this forum could subscribe to the CoC, which would mean that they are tasked with enforcement actions in this context. FPF could be tasked with enforcement actions in the FPF-operated SecureDrop GitHub repository. And so on.
The relationship between folks implementing enforcement actions (orgs/individuals subscribing to the CoC who operate spaces used by the SecureDrop community) vis-a-vis a standing CoC committee would need to be clarified, but I think that’s doable. Basically, the standing committee would deal with any non-emergency situation and sharpen policies and processes over time.
I guess what I’m trying to prevent is parts of the SecureDrop community choosing to not have or not enforce the CoC. If we’re decentralized, we (those of us talking right now) have no way to tell others they must use our CoC, but they might still host SecureDrop events. How do we work around that? Would this forum be a reference point for who has or has not subscribed to the CoC thus making us a de facto central authority on the matter?
Or maybe there’s no clean answer right now and the best we can do is finish up this CoC and push for adoption.
I think the “SecureDrop Community” is developing a robust identity through these forums, the GitLab and Weblate instances, the Liberapay account, and so on. If individuals set up new social infrastructure in support of the community and bring it to our attention, we can request that they also subscribe to the CoC. If they don’t, we can choose not to use said infrastructure.
FPF does have the ability to enforce the trademark if needed to prevent misleading or malicious uses of the term “SecureDrop”, but I think we should only resort to that sort of top-down enforcement if absolutely necessary.
Indeed. CoC are mostly discussed in the context of centralized organizations and enforcement is a byproduct of centralization.
With a decentralized community, enforcement is the sum of what individual members decide to do, either unilaterally or by reaching out for consensus before acting. It already happens and will continue to evolve. As @eloquence mentions, the community develops an identity over time. It has inertia, you can see patterns emerging, etc. It is organic and imperfect but I believe it will be more robust and sustainable than the centralized model.
If that was perceived as a possibility, it would mean there is an ultimate centralized control operated by FPF. And the SecureDrop Community would therefore no longer be decentralized. We should instead operate under the assumption that FPF won’t be able to operate any kind of unilateral control over the community and find creative ways to make it healthy and sustainable at the same time.
Fair enough. This sounds like a large philosophical debate and not something that can be codified into the SD CoC in a meaningful way, so for now we can “ignore” this.
I have blown away the existing edits I made and am going to start again by adding pieces that are more manageable for debate.
First PR is the preamble taken from the bits Emmanuel wrote in the original PR. If this doesn’t receive any feedback in the 3 days, I’m going to consider it good enough to merge.
Of course we can always reopen the debate, but I want to set a deadline for initial comments so we can make sure pieces at least slowly make it in to the CoC.
@heartsucker Thanks for driving this forward! The preamble you posted is an excellent start. We have much more work to do, and the discussion above provides several strong examples to inform next steps. Let’s continue to poke for frequent review, e.g. reminding others in Gitter about proposed changes, so we can maintain motion on this front.
A note on horizontal organizing and enforcement: enforcement does not need to involve centralization. A horizontally organized community comes to consensus on what behaviors are and are not acceptable, the community agrees that people with problematic behaviors should be expelled (not all behaviors of course result in this action, a gentle course correction are likely sufficient for minor issues) and how this will happen. This can all be done via consensus (it just involves some very long meetings ).
If the community can’t ask someone to leave if they’re being abusive, then I think we wouldn’t be doing enough protect victims.
Agreed
Members of the community, including the point of contact, can certainly ask someone to leave, if and when all other attempts to preserve a civilized conversation and a safe environment failed. And it is possible the person will refuse because there is no central authority.
For example, in this situation, if as a community we decided that someone’s behavior was so problematic that they should leave, then we would politely ask them to leave, and then kick/ban them from all community spaces if they do not do that. If it sounds harsh to anyone, I would remind you that keeping toxic and very problematic people in one’s community is far, far worse.
A horizontally organized community comes to consensus on what behaviors are and are not acceptable, the community agrees that people with problematic behaviors should be expelled (not all behaviors of course result in this action, a gentle course correction are likely sufficient for minor issues) and how this will happen.
First, I want to clarify that just because you are horizontally organized does not absolve the greater community from their responsibility from enforcing the CoC. In fact, I would argue that a horizontally organized community has a greater responsibility to enforce a CoC than a hierarchical organization. If a community says we all wish to be horizontal then we all have a responsibility to make sure everyone in that community feels welcome. If the community can not do this, then “horizontalism” just re-creates a situation where a people who is truly toxic is allowed to continue bad behavior without consequences.
Regarding the content of the Code of Conduct, although my preference still is that we reuse the OpenStack Code of Conduct, I’m happy with whatever is agreeable to people actively working on that and I’m grateful that @heartsucker is driving this.
As long as it is short enough so people can actually read it and simple enough so people can actually understand what it stands for, I think it will serve its purpose.
We cannot forsee all use cases, nor can we predict how to push a toxic person out but I’m sure we will find ways to do that collectively as @bmeson so eloquently puts it or by various other means as suggested by @redshiftzero, including lenghty discussions. My hope is that toxic people will keep away from our community because it is abundantly clear they will not prosper.
I have opened another PR for the CoC’s summary. Like last time, if no one comments for 3 days, I’m going to consider this good to merge.
Also, for ease, I’m going to just paste the text here.
This is just the summary. Specific good/bad behavior will be added in later sections.
Summary
The SecureDrop community should be a place where people feel safe and welcome. They should enjoy participating in discussions and contributing. To these ends, members of the community should:
Be friendly and patient
Be welcoming, considerate, and respectful
Be careful in the words they choose
Listen to each other, and communicate openly and honestly
Members of the community should not:
Intimidate, harass, or insult each other
Follow the letter of this Code of Conduct while disregarding its spirit
Members of the community should not hesitate to contact the Community Council if they feel someone has violated this Code of Conduct, or if they have questions or concerns.
+1 @redshiftzero. In my opinion, the very most important aspect of a CoC is the ability to ban toxic people from the community.
Tor Project used to be an incredibly toxic, unwelcome, and, for many women, dangerous community to participate in. A group of whistleblowers put a massive amount of work into banning Jake and his apologists from the community. It resulted in a complete restructuring of the organization, the resignation of the whole board, the forming of a membership policy, a Community Council that meets every week and members vote them in, and finally a Code of Conduct and Statement of Values. Years later, the community is still dealing with aftermath of Jake (not to mention his victims still get online abuse for speaking out against him), but it’s in a much stronger place now, and it’s no longer dangerous for some people. I think the reason this was (and still is) such a painful process for Tor is because they didn’t have a mechanism to ban Jake.
Tor is also a horizontal community, and they solved the problem by creating a membership policy. Once you have membership, the community can vote or come to consensus on revoking someone’s membership. I’m sure there are other ways to achieve the same result that don’t involve formal membership.
I’m hoping that a strong CoC will make sure that, if abusive people become a part of the SecureDrop community, we’ll have a path forward to deal with them without having to go through what Tor went through.
Enforcing the Code of Conduct is necessary, for all the reasons explained in this thread. And I kept thinking about how we could effectively do that although there is no central authority. I originally suggested that we wait for an actual problem to happen to figure that out. But I’ve been convinced this is not enough and may even be interpreted as an open invitation for abuse. However I still find that including detailed measures (such as banishment) in the CoC itself is problematic because it can be worked around or be inappropriate in some cases.
How about we include a more general promise such as “If at least two CoC point of contact find that a person violates the CoC, they will do what is in their power to resolve the problem”. Examples of such actions can then be added in comments of the CoC . For instance: a person is banned from communication channels or their photo is circulated so they are not allowed in conference rooms, etc. But we do not need to include these examples in the CoC itself.
The worst that can happen is if the person who is in violation also has control over resources that would not allow the CoC point of contact to resolve the problem. For instance if the organizer of an event is the person in violation, they may refuse to step down. In this case the CoC point of contact will have a hard time but will not be powerless. They can publicly state that the SecureDrop Community boycotts the event etc. It would not be reasonable to expect the CoC point of contact is always in a position to resolve all matters with perfect efficiency. But it is reasonable to expect the CoC point of contact will always work to resolve all matters, to the best of their abilities.
I think that level of detail is also unnecessary. I think something general like “the community council decides…” is enough. Maybe we need consensus. Maybe we don’t.
With a horizontal community, I think the only thing we can do is hope that everyone follows the recommendations for sanctions from the CC. Sunlight is the best disinfectant, so if we are public and transparent about decisions, the community will know what events/spaces/people are in support of sanctions and which are not. I a problematic person is allowed at events, it will be made clear who let them there and, and members can self regulate spaces that are following vs. ignoring the CC’s recommendations.
I really don’t see a way around this problem without a central authority, which the community rightly seems to be rejecting.
Also, since @micahflee brought up Tor, I’ve been talking with one of the folks who was working on the CoC there and it seems like what we are proposing is mostly in line with what they do. Given that they were central to one of the biggest abuse/CoC stories in this community in recent years, I’m inclined to say their solutions to address that might carry more weight than communities that haven’t yet faced such circumstances (with the caveat being that I genuinely believe Tor cares about fixing this whereas other groups not so much).
If we have our CC made up of people from the major parts of SD (so let’s say this forum + FPF + UX folks (yes there’s overlap)), I think the CoC will apply to most SD-related spaces for the medium term future. As new groups pop up, we can talk to them about joining the CC or ask them to use the CoC in their spaces.
I’ve taken a stab at the next section, which spells out the items listed in the summary in more detail. I’d appreciate your comments and hope we can keep this moving forward.
I’ve also filed an issue to suggest that we convert the code to markdown (we can do so once it is complete), for easier readability in contexts where markdown is parsed.
I (and