FPF code of conduct

Hi everyone! I’d love to get involved with the Code of Conduct for the broader community. I’d like to add a copy of the code of conduct from Freedom of the Press Foundation here too. See the PR for raw text: https://github.com/freedomofpress/securedrop/pull/3253

Code of Conduct - Freedom of the Press Foundation

Like the the broader technical and activism communities as a whole, the Freedom of the Press Foundation (FPF) team is made up of a mixture of staff and volunteers from all over the world, working on every aspect of our mission—including operations, software development, mentorship, and building connections with great people and organizations.

To work together effectively in a large, diverse and open community, we have a few ground rules that we expect everyone to adhere to, be it FPF staff and board members, volunteers and event attendees; mentors, veterans, novices, or those seeking help and guidance.

This isn’t an exhaustive list of things that you cannot do. Rather, take it in the spirit in which it’s intended—a guide to make it easier to enrich all of us and the communities in which we participate.

This code of conduct applies to all spaces and events managed by the Freedom of the Press Foundation. This includes physical offices, GitHub repositories, online chat systems, the Support Forum, FPF hosted or sponsored events, and any other forums created by the Foundation which our team uses for communication. In addition, we take violations of this code outside these spaces into account when determining a person’s ability to participate within them.

If you believe someone is violating the code of conduct, we ask that you report it by talking to Emmanuel, or emailing emmanuel@freedom.press. If, for whatever reason, you are uncomfortable reporting the issue to Emmanuel, you may contact FPF’s Executive Director (trevor@freedom.press).

We are committed to taking fair, timely and appropriate corrective action against any violations of this code.

  • Be friendly and patient.
  • Be welcoming. We strive to be a workplace that welcomes and supports people of all backgrounds and identities. This includes, but is not limited to members of any race, ethnicity, culture, national origin, color, immigration status, social and economic class, educational level, sex, sexual orientation, gender identity and expression, age, size, family status, political belief, religion, and mental and physical ability.

  • Be kind and considerate. Your work will be used by other people, and you in turn will depend on the work of others. Any decision you take will affect users and colleagues, and you should take those consequences into account when making decisions. Remember that we work with people as part of an international community, so you might not be communicating in someone else’s primary language.

  • Be respectful. Not all of us will agree all the time, but disagreement is no excuse for poor behavior or poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It’s important to remember that a workplace where people feel uncomfortable or threatened is not a productive one. Freedom of the Press Foundation staff should be respectful when dealing with other staff as well as with people outside the Foundation, such as clients, outside contributors, and the SecureDrop community. Avoid making assumptions, e.g., about people’s gender identity, preferred pronoun, willingness to be photographed, etc.—when in doubt, ask at the right moment.

  • Harassment, public or private, is unacceptable and won’t be tolerated. This includes but is not limited to:

    • Intimidation
    • Stalking
    • Unwelcome following
    • Enlisting the help of others, whether in person or online, in order to target an attendee
    • Taking photographs, video, or audio recordings or recordings without consent
    • Obscene or intimidating gestures
    • Shouting
    • Sustained disruption of talks and events
    • Disruption of meetings
    • Inappropriate physical contact
    • Unwelcome sexual attention
    • Posting (or threatening to post) other people’s personally identifying information (“doxing”)
  • No matter who you are, if you feel you have been or are being harassed or made uncomfortable by another person in relation to your work on FPF projects, please report it immediately. We are aware that harassment and sexual violence are systemic and pervasive social issues that demand continued awareness and attention, and that a code of conduct is only a small component of that. We are committed to taking proactive action to make our organizational spaces safe and comfortable for everyone.

  • Be careful in the words that you choose. We are a community of professionals, and we conduct ourselves professionally. Be kind to others. Exclusionary behavior is absolutely unacceptable. This includes, but is not limited to:

    • Discriminatory jokes and language.
    • Posting sexually explicit or violent material.
    • Personal insults, especially those using racist or sexist terms.
    • Unwelcome sexual attention.
    • Advocating for, or encouraging, any of the above behavior.
  • When we disagree, try to understand why. Disagreements — both social and technical — happen all the time, even at Freedom of the Press Foundation. It is important that we resolve disagreements and differing views constructively. Remember that we’re different. The strength of FPF comes from its varied team, people from a wide range of backgrounds. Different people have different perspectives on issues. Being unable to understand why someone holds a viewpoint doesn’t mean that they’re wrong. Don’t forget that it is human to err and blaming each other doesn’t get us anywhere. Instead, focus on helping to resolve issues and learning from mistakes.

  • Name things appropriately. Avoid giving your user accounts, servers, repositories, etc. names that are overtly sexual or that might otherwise detract from a friendly, safe and welcoming environment for all.

Sanctions

We will deal with violations of this code of conduct on a case by case basis, depending on the severity of the behavior and any prior violations. Sanctions may range from a simple warning not to engage in a particular kind of behavior (e.g., in response to a single mildly inappropriate comment), to separation from FPF (termination in the case of employment, removal from all FPF technical and social spaces in the case of volunteers) and other consequences in the most severe cases.

Original text courtesy of the Django project, which in turn was inspired by the Speak Up! Code of Conduct. License: Creative Commons Attribution (CC-BY).

1 Like

Thanks for this work @edenemmanuel, it is much needed and welcome!

I feel privileged to be an FPF team member and a volunteer at the same time. This is the kind of trust that are rarely found in an organization. And I strongly believe FPF will benefit from a clear Code of Conduct such as the one you propose. I have two improvements to suggest:

  • The term FPF team volunteer should be defined. For instance something like: An FPF volunteer is an individual who is not paid staff but identifies themselves publicly as a representative of FPF. For instance, whenever I use the loic@freedom.press vanity email that was kindly offered to me, I communicate in the name of FPF and I am therefore bound by the Code of Conduct. I implicitly agree that either Emmanuel or Trevor enforce the CoC against me if necessary.
  • The Code of Conduct should be published at the organizational level, either at Freedom of the Press Foundation · GitHub if possible or https://freedom.press because it is not focused on SecureDrop and does not concern SecureDrop volunteers who do not identify themselves as Freedom of the Press Foundation representatives.

I suggest we decouple the SecureDrop code of conduct from Freedom of the Press Foundation (FPF) - similarly I suggest we avoid the “FPF team volunteer” term as it can lead to confusion. Many people work on SecureDrop, some of whom are from FPF and some of whom are from the community. Right now we have a lot of SecureDrop contributors and maintainers that are paid by FPF, but it’s not necessarily the case that it will always be that way, e.g. if another organization starts investing heavily in SecureDrop development.

We have two excellent starting points here for the code of conduct (one written by @edenemmanuel et al. at FPF and one written by @dachary et al. based on the OpenStack CoC). The FPF one I think is appropriate as is for other FPF projects where there is not significant community involvement. That said, for SecureDrop what I’d ideally like to see is a single Code of Conduct (CoC) that applies to all contributors to the SecureDrop project - whether they are from FPF or the community. This way the expectations are clear for everyone that works on the project. Perhaps we can merge these two CoCs together and make sure that all the points we all think are important are addressed in a single document?

In terms of the escalation process for SecureDrop, I think that responsibility should be shared by the people that work on SecureDrop (whether or not they work for FPF) who are willing to serve the entire community in that role. What do we think?

I moved the discussion to a separate thread to avoid mixing the two together.

When there is significant community involvement (say SecureDrop), writing the CoC is done by the community. And ruling is also done by people chosen by the community.

It however makes perfect sense that FPF would write its own code of conduct for all matters where it is the ultimate authority. This code of conduct is ultimately finalized and published by FPF. It is useful to seek input from the community, because some members of the community are also subject to FPF authority when they represent FPF publicly (that’s what an FPF team volunteer is, but we can chose another name to designate the same).

Hi @dachary,

The submitted PR was intended to be a draft for a CoC that would apply to volunteers and staff working in FPF-operated spaces, including the GitHub repo. However, it makes sense that the enforcement mechanisms for a SecureDrop code must be less FPF-centric and include broad community involvement in decision-making. And it also makes sense to me that we would work together to reconcile the drafts so that we don’t have a weird split between, e.g., securedrop.club vs. GitHub or whatever.

Let’s take the time to get it right, and look carefully at multiple drafts, as well as other projects’ codes. I’m confident that we can reach a consensus towards a SecureDrop CoC that can apply equally in places like this forum, the GitHub repo, or at an FPF-hosted event.

There are special-case situations: as you say, when someone is acting in an official capacity for organization $Foo, organization $Foo has an additional legal and ethical responsibility to enforce its behavioral code vis-a-vis that person. When organization $Bar is hosting an event, it has an additional legal and ethical responsibility to enforce a code of conduct during the course of that event, regardless of who the attendees are.

But, I think we can write the code for SecureDrop in such a way that it is largely organization-neutral (with perhaps a section where the role of more than one organization can be clearly stated). FPF may create “ports” of the SecureDrop code that will be used for other repositories (e.g., “Secure the News”), where the enforcement is more clearly situated with FPF.

Does that broadly sound reasonable? I look forward to talking more, and perhaps in addition to the forum conversation, we can have a CoC Jitsi chat soon with interested participants.

Warmly,
Erik

This makes sense. When FPF is the ultimate authority (GitHub repo, Gitter chan, etc.) it also has authority to establish a code of conduct in these spaces. When participating in FPF operated spaces I am bound by this CoC. Although input from the community is not strictly necessary, it is a nice gesture.

Now that you have clarified the scope of the CoC it is no longer weird. Since the community has a different decision making process, organizes events (such as this week hackfest), has resources that are not under the FPF umbrella (such as this forum), it also makes sense that it has its own CoC.

I guess part of the confusion came from the fact that the CoC PR was open shortly after the CoC discussion started in the forum. But it’s all good now :slight_smile:

Hey @dachary -

Thank you for the follow-up, and for helping to preserve the forward momentum! :slight_smile: I think we have basically two options:

  1. Distinguish social/technical spaces between FPF-operated vs. community-operated and let the two CoC efforts proceed separately;
  2. Try to come up with consolidated language for a “SecureDrop CoC” that does take the role of organizations/organizationally operated social/technical spaces into account.

My preference (and I think @redshiftzero’s as well) would be the second option, even if takes a little longer. I think it would be more user-friendly to have a single SecureDrop CoC. Do you think that’s achievable?

Here’s some example wording that I think such a CoC could include to clarify the differences in enforcement (somewhat inspired by the Tor code):

Scope

SecureDrop is developed by a global community. Freedom of the Press Foundation (FPF) plays a leading role in its development. Its employees are subject to additional policies and procedures. In the course of working on SecureDrop, you may work in social and technical spaces operated by Freedom of the Press Foundation (e.g., the FPF GitHub repository).

In these social and technical spaces, wherever reasonably possible, FPF will defer to the Community Council for enforcement of this code relative to volunteers working on SecureDrop in their personal capacity. In the case of emergencies occurring in FPF-operated social or technical spaces, FPF may act as an immediate point of contact and may implement sanctions if urgently required, but will debrief with the Community Council at a later point.

Other organizations working in the context of SecureDrop are encouraged to adopt a similar process.

This is totally made up language that hasn’t been vetted by anyone, so take it with a huge block of salt. But I wanted to give you a better idea of how I think the current gap might be bridged. This language would not exist in the version of the CoC in other FPF repos (like “Secure the News”), until/unless we see the development of self-sustaining communities there as well.

Although everyone has a preference and an opinion about the content of a CoC, our community is small enough that we can agree on something that satisfies everyone. This is what Contributor Covenant is about and it seems to work well. I’m not suggesting this specific CoC is better. I’m just pointing this as an example of text multiple organizations agree on.

Enforcement of the CoC is a different matter and depends on the organization responsible for the space in which the CoC applies. The point of contact and procedure must be separate from the CoC document itself. Like Hanami for instance. When FPF organizes a hackaton, it will enforce the CoC via FPF staff point of contact and be held responsible for what happens there. When the SecureDrop Community organizes a hackaton and no FPF employee is involved, FPF does not sponsor the event in any way, there must be no ambiguity that FPF is not responsible and FPF staff must not be the point of contact.

Because the SecureDrop code is duplicated in many places, under a Free Software license, the CoC text and point of contact must not be mixed in the code and I suggest we keep discussing this specific point in the PR.

With that in mind, it sounds like we can clear the confusion and come up with a common code of conduct with different enforcement rules, published at the organizational level. Does that sound reasonable?

When the SecureDrop Community organizes a hackaton and no FPF employee is involved, FPF does not sponsor the event in any way, there must be no ambiguity that FPF is not responsible and FPF staff must not be the point of contact.

Somewhat disagree.

If someone is using the SD name or FPF name to host an event, then they must enforce the CoC. If someone contacts the FPF and says “a community event wasn’t enforcing the CoC,” then the FPF needs to contact the organizer and find out why not. If the organizer can’t sufficiently enforce it or doesn’t want to, the FPF will ask that they don’t use the trademark for their events.

Similarly, if someone forks the SD repo and the issues/PR section of their repo turns into an abusive trash fire, the FPF can use the CoC against the maintainer because the CoC says that we don’t stand by when abuse is happening.

Adding it to the repo is fine because the above enforcement would need to happen regardless if it was in the repo or not.

SecureDrop is a Free Software codebase and a CoC does not belong there. If SecureDrop is Free Software then anyone can remove the CoC because they do not want it. Or it is forbidden to modify or remove the CoC from the SecureDrop codebase and it no longer is Free Software.

FPF is not a Free Software codebase, it is an organization and it can apply a CoC in areas that are under its responsibility and enforce it when people behave contrary to the CoC.

I think it would be sensible for FPF and the SecureDrop Community to have the same Code of Conduct. But it would not work to have it in the SecureDrop repository, because a Code of Conduct depends on the context and a codebase exists in many contexts. Instead I propose that we do the following:

  • FPF publishes the text of the Code of Conduct on https://securedrop.org or https://freedom.press, together with FPF staff contacts in case something contrary to the CoC happens in spaces for which FPF is ultimately responsible
  • The SecureDrop Community publishes the same text of the Code of Conduct on https://securedrop.club, together with community contacts in case something contrary to the CoC happens in spaces which are controlled or organized by people who publicly claim to belong to the SecureDrop Community

How does that sound?

@dachary and I chatted about this today, and we think it is the best way forward.

1 Like