Drafting FreedomBox Code of Conduct

This thread is for discussing the creation of a FreedomBox Code of Conduct.

A comment in preface: Throughout this process, we’ll be setting standards which will be foundational for our community. I therefore encourage everyone in the core team to participate in this thread.

I’m following up on our discussion from our most recent progress call. One of the items on our to-do list is creating a Code of Conduct. On the call, we agreed to base it on Debian’s, and to try to learn from Mozilla’s governance guidelines.

As discussed on the progress call, we can start the CoC drafting process by importing Debian’s CoC and modifying it. Below, you will find two sections: (1) Debian’s CoC and (2) my proposed changes to it.

1. Here is the Debian CoC:

Debian Code of Conduct

  1. Be respectful
    In a project the size of Debian, inevitably there will be people with whom you may disagree, or find it difficult to cooperate. Accept that, but even so, remain respectful. Disagreement is no excuse for poor behaviour or personal attacks, and a community in which people feel threatened is not a healthy community.
  2. Assume good faith
    Debian Contributors have many ways of reaching our common goal of a free operating system which may differ from your ways. Assume that other people are working towards this goal.
    Note that many of our Contributors are not native English speakers or may have different cultural backgrounds.
  3. Be collaborative
    Debian is a large and complex project; there is always more to learn within Debian. It’s good to ask for help when you need it. Similarly, offers for help should be seen in the context of our shared goal of improving Debian.
    When you make something for the benefit of the project, be willing to explain to others how it works, so that they can build on your work to make it even better.
  4. Try to be concise
    Keep in mind that what you write once will be read by hundreds of persons. Writing a short email means people can understand the conversation as efficiently as possible. When a long explanation is necessary, consider adding a summary.
    Try to bring new arguments to a conversation so that each mail adds something unique to the thread, keeping in mind that the rest of the thread still contains the other messages with arguments that have already been made.
    Try to stay on topic, especially in discussions that are already fairly large.
  5. Be open
    Most ways of communication used within Debian allow for public and private communication. As per paragraph three of the social contract, you should preferably use public methods of communication for Debian-related messages, unless posting something sensitive.
    This applies to messages for help or Debian-related support, too; not only is a public support request much more likely to result in an answer to your question, it also makes sure that any inadvertent mistakes made by people answering your question will be more easily detected and corrected.
  6. In case of problems
    While this code of conduct should be adhered to by participants, we recognize that sometimes people may have a bad day, or be unaware of some of the guidelines in this code of conduct. When that happens, you may reply to them and point out this code of conduct. Such messages may be in public or in private, whatever is most appropriate. However, regardless of whether the message is public or not, it should still adhere to the relevant parts of this code of conduct; in particular, it should not be abusive or disrespectful. Assume good faith; it is more likely that participants are unaware of their bad behaviour than that they intentionally try to degrade the quality of the discussion.
    Serious or persistent offenders will be temporarily or permanently banned from communicating through Debian’s systems. Complaints should be made (in private) to the administrators of the Debian communication forum in question. To find contact information for these administrators, please see the page on Debian’s organizational structure.

2. My proposed changes:

a. CHANGE all instances of “Debian” or “Debian’s” to “FreedomBox” or “FreedomBox’s”

b. ADD to item 1 in the Debian CoC the following text which is adapted from Mozilla’s checklist:

“Members of our community must treat others with equal respect, regardless of background, family status, gender, gender-identity or expression, marital status, sex, sexual orientation, language, age, ability, race/ethnicity, national origin, socioeconomic status, religion, or geographic location.

Community members may indicate their preferred gender pronouns on an opt-in basis in any way they wish, including email signatures, at the ends of forum posts, in their forum profile, or after their name in parenthesis in the notes for progress calls. Members are expected to respect the preferred gender pronouns of other members.”

c. CHANGE item 6 to the following (this is written with Mozilla’s checklist in mind):

"This code of conduct should be adhered to by participants. When violations happen, you have three avenues for enforcement. (1) You may reach out to the person who violated the code of conduct and point out it out to them. Such messages may be in public or in private, whatever you decide is most appropriate. However, regardless of whether the message is public or not, it should still adhere to the relevant parts of this code of conduct; in particular, it should not be abusive or disrespectful. (2) You may report the violation to the core team and, if desired, ask for assistance mediating a resolution. (3) You may report the violation to a staff member at the FreedomBox Foundation and, if desired, ask for assistance mediating a resolution. Ultimately, all reports will be responded to in a matter appropriate to the specific circumstances of the violation, and the reporter, reported, and all others impacted will be updated.

If you chose to report a violation to either a core team member or a FreedomBox Foundation staff member, reports should be made in private. To find contact information for these parties, please see FreedomBox’s page on its organizational structure. (NOTE: this doesn’t exist yet and will be a topic of discussion in a different forum thread)"

c. CHANGE item 5 to the following (written with Mozilla’s checklist in mind):

“Most ways of communication used within FreedomBox allow for public and private communication. When it would contribute to the community’s technical knowledge base, you should preferably use public methods of communication for FreedomBox-related discussions. This applies to messages for help or FreedomBox-related support, too; not only is a public support request much more likely to result in an answer to your question, it also makes sure that any inadvertent mistakes made by people answering your question will be more easily detected and corrected.

We strive to avoid jargon and other non-inclusive language that can alienate or make people feel excluded. Our community strives to encourage and recognize quiet voices. Though our community mostly communicates in English, we recognize that English may not be the first language of all contributors. Where possible, we provide notes of meetings and conference calls. We encourage and support localization of our documentation using the “documentation” and “localization” labels on Gitlab; we encourage and support the localization of our software user interface using the Weblate translation platform.

d. ADD to item 3:

“The FreedomBox community values the contributions made by non-coders. We provide non-technical tasks for first-time contributors to participate in our project using the “beginner” issue label in Gitlab.”

Next steps:

  1. What do people think about my proposed changes?
  2. What changes would you propose we make to Debian’s CoC? What do you want to see in the CoC?

Tagging @jvalleroy @mray @njoseph @sunil

2 Likes

I’d like to point out that Debian has the following in addition to the CoC.

Source: https://www.debian.org/vote/2014/vote_002

“The FreedomBox community values the contributions made by non-coders. We provide non-technical tasks for first-time contributors to participate in our project using the “beginner” issue label in our Gitlab.”

Our beginner label provides both technical and non-technical tasks. Also, our issue tracking system might not always be on GitLab. This can be reworded to the following.

The FreedomBox community values non-code contributions. We provide tasks for first-time contributors using the “beginner” label in our issue tracking system.

I went through all the other proposed changes as well. They seem good to me.

For item #6, we should think about the cases where offense is taken but not intended. By skipping the first sentence from Debian’s CoC, I think we are missing this case entirely.

While this code of conduct should be adhered to by participants, we recognize that sometimes people may have a bad day, or be unaware of some of the guidelines in this code of conduct.

1 Like

I would just like to add to the 6th item about handling problems and moderation.

This for me is the most serious barrier of entry into FOSS and we have seen umpteen examples of newbies and people from other backgrounds being discouraged and subjected to snarky comments and that too on public forums for the simplest of reasons.

I would like to suggest the adoption of the Rust moderation guidelines in the moderation section of https://www.rust-lang.org/policies/code-of-conduct
Also https://berlincodeofconduct.org/ is a nice reference for moderation rules.

Plus I think having a well defined moderation group is quite important.

I looked at those resources, and I think they are good references for us to keep in mind. Though we can definitely keep them in mind (and we may already be bound by them since we are Debian contributors), I don’t think we should adopt any guidelines like those just yet. In my opinion, they are a bit too detailed for our community and may provide too much guidance. Since our contributor community is still relatively small, I think it is okay if we start by adopting a simple CoC.

I like that rewording and agree.

That’s a good point. I also support adding that text from the Debian CoC back into our CoC.

I took a look at Rust’s code of conduct, and I think that we have already incorporated much of its content in our draft CoC in one way or another. But you mention that you want us to incorporate something into item 6 about moderation. I assume you mean moderation of the forum? I ask because there aren’t really “moderators” in other settings–just leaders who take turns leading discussions.

Ultimately, I’m asking this: do you think we need a specific forum moderation policy that goes beyond what is already in the draft CoC? Should we preemptively state what kind of comments will be removed by moderators, and what kind of behavior will result in action by moderators? I’m interested in what others think about this question.

I think there is value in clarifying our content moderation policy, but I would support something simple and easy to understand, like this: “If anyone who uses our forum, or any other digital space we use to communicate, repeatedly violates, or violates in at least one egregious way, this code of conduct, then moderators may exercise the right to delete the offending post(s) and/or ban or suspend the offending account.”

Your two changes reflect exactly my concerns. There is only one minor issue in my eyes, that addition sounds like non-code contributions are for beginners. We may want to separate “non-code contributor” and “beginner” a bit more.

2 Likes

I agree with the proposed CoC as derived from Debian’s CoC and also the changes @haidar has proposed. My minor concerns were reflected already by @njoseph.

We encourage and support localization of our documentation using the “documentation” and “localization” labels on Gitlab; we encourage and support the localization of our software user interface using the Weblate translation platform.

To make the statement withstand the passing of time, I suggest instead “We encourage and support localization of our documentation using a community edited Wiki; we encourage and support the localization of our software user interface using both web-based and traditional translation tools.”

We may want to separate “non-code contributor” and “beginner” a bit more.

I think a simple spatial separation will be good. Just don’t keep the two sentences next to each other.

1 Like

Spacial separation would work, additionally maybe change

“We provide…”

to

“We also provide…”

Good idea, I will integrate that change into the next draft of the code of conduct.

Yes, that is a good approach. I can integrate that into the next draft of the code of conduct.

Thanks everyone for the feedback.

If we refer to issue labels on “Gitlab”, someone may assume we mean gitlab.com. Perhaps better to refer to “Salsa”, or just eliminate mention of where the issue labels are.

2 Likes

Agreed, I think we can just replace Gitlab with the generic term “issue-tracking platform”.

Now that everyone has had a chance to review this thread and submit feedback, I have written a second draft of the FreedomBox CoC (pasted below). This second draft integrates all of the proposals we agreed to in this thread. If I missed something, please let me know.

Please also consider this second draft just as revisable as the first draft. If you have more feedback, you are welcome to submit here or on a progress call.

FreedomBox Code of Conduct, Draft 2

1. Be respectful

In a project the size of FreedomBox, inevitably there will be people with whom you may disagree, or find it difficult to cooperate. Accept that, but even so, remain respectful. Disagreement is no excuse for poor behaviour or personal attacks, and a community in which people feel threatened is not a healthy community.

Members of our community must treat others with equal respect, regardless of background, family status, gender, gender-identity or expression, marital status, sex, sexual orientation, language, age, ability, race/ethnicity, national origin, socioeconomic status, religion, or geographic location.

Community members may indicate their preferred gender pronouns on an opt-in basis in any way they wish, including email signatures, at the ends of forum posts, in their forum profile, or after their name in parenthesis in the notes for progress calls. Members are expected to respect the preferred gender pronouns of other members.

2. Assume good faith

FreedomBox Contributors have many ways of reaching our common goal of a free operating system which may differ from your ways. Assume that other people are working towards this goal.

Note that many of our Contributors are not native English speakers or may have different cultural backgrounds.

3. Be collaborative

FreedomBox is a large and complex project; there is always more to learn within FreedomBox. It’s good to ask for help when you need it. Similarly, offers for help should be seen in the context of our shared goal of improving FreedomBox.

When you make something for the benefit of the project, be willing to explain to others how it works, so that they can build on your work to make it even better.

The FreedomBox community values non-code contributions. Separately, we also provide tasks for first-time contributors using the “beginner” label in our issue tracking system.

4. Try to be concise

Keep in mind that what you write once will be read by hundreds of persons. Writing a short email means people can understand the conversation as efficiently as possible. When a long explanation is necessary, consider adding a summary.

Try to bring new arguments to a conversation so that each mail adds something unique to the thread, keeping in mind that the rest of the thread still contains the other messages with arguments that have already been made.

Try to stay on topic, especially in discussions that are already fairly large.

5. Be open

Most ways of communication used within FreedomBox allow for public and private communication. When it would contribute to the community’s technical knowledge base, you should preferably use public methods of communication for FreedomBox-related discussions. This applies to messages for help or FreedomBox-related support, too; not only is a public support request much more likely to result in an answer to your question, it also makes sure that any inadvertent mistakes made by people answering your question will be more easily detected and corrected.

We strive to avoid jargon and other non-inclusive language that can alienate or make people feel excluded. Our community strives to encourage and recognize quiet voices. Though our community mostly communicates in English, we recognize that English may not be the first language of all contributors. Where possible, we provide notes of meetings and conference calls. We encourage and support localization of our documentation using a community edited Wiki; we encourage and support the localization of our software user interface using both web-based and traditional translation tools.

6. In case of problems

While this code of conduct should be adhered to by participants, we recognize that sometimes people may have a bad day, or be unaware of some of the guidelines in this code of conduct. When violations happen, you have three avenues for enforcement. (1) You may reach out to the person who violated the code of conduct and point out it out to them. Such messages may be in public or in private, whatever you decide is most appropriate. However, regardless of whether the message is public or not, it should still adhere to the relevant parts of this code of conduct; in particular, it should not be abusive or disrespectful. (2) You may report the violation to the core team and, if desired, ask for assistance mediating a resolution. (3) You may report the violation to a staff member at the FreedomBox Foundation and, if desired, ask for assistance mediating a resolution. Ultimately, all reports will be responded to in a matter appropriate to the specific circumstances of the violation, and the reporter, reported, and all others impacted will be updated.

If you chose to report a violation to either a core team member or a FreedomBox Foundation staff member, reports should be made in private. To find contact information for these parties, please see FreedomBox’s page on its organizational structure. (NOTE: this doesn’t exist yet and will be a topic of discussion in a different forum thread)

Notes:

  1. This code of conduct was adapted from Debian’s Code of Conduct: Debian Code of Conduct

  2. This code of conduct took ideas from Mozilla’s “Open Source Inclusion Basic Checklist for Projects”: inclusion/evaluation_tools/governance-basic.md at master · mozilla/inclusion · GitHub

2 Likes

Looks good to me, we can adopt it verbatim.

@haidar Are we ready to publish this as official code of conduct?

I believe so. One final item I wanted to discuss is item 6, which explains what to do in case of problems. Two particular questions I want to raise this weekend on our progress call:

  1. Item 6 says that people can report CoC violations to the core team. I want to ask folks on the core team if they want to take on this responsibility. I’m beginning to think that we may not want to put that extra labor on the core team. I want to avoid a situation in which a core team member is suddenly expected to mediate a conflict when they ultimately don’t want to.
  2. @njoseph proposed a “Community Manager” role on a different thread, and I am now thinking that we could mention this role in item 6 as one of the people you can report violations to.

It is hard to imagine how this role would turn out right now. Shall we make this change after the roll is filled? It is always good to have a small set of people play this role instead of a single person.

In light of our discussion on the progress call on August 10, I have updated the code of conduct. Note that I also made various stylistic revisions (e.g. capitalzing some words, rephrasing some sentences) throughout the code of conduct. None of these stylistic revisions were intended to change the substance or meaning that we agreed upon; instead, there were intended to add clarity and professionalism. You can compare this draft with the two previous drafts in this thread.

Here it is: the final draft of the code of conduct. I have pasted it using the same format one would use for Lektor; excuse the various blemishes that result. I will also create a corresponding merge request in gitlab.


_model: coc

title: Code of Conduct

body:

FreedomBox Code of Conduct

Version 1.0 ratified on August 10th, 2019

The FreedomBox community has adopted this code of conduct for its community members and participants to the various modes of communication within the FreedomBox project.

  1. Be Respectful

    In a project the size of FreedomBox, inevitably there will be people with whom you may disagree, or find it difficult to cooperate. Accept that, but even so, remain respectful. Disagreement is no excuse for poor behavior or personal attacks, and a community in which people feel threatened is not a healthy community.

    Members of our community must treat others with equal concern and respect, regardless of background, family status, marital status, gender identity or expression, sex, sexual orientation, language, age, ability, race, ethnicity, national origin, socioeconomic status, religion, or geographic location.

    Community members may indicate their preferred gender pronouns on an opt-in basis in any way they wish, including email signatures, at the end of forum posts, in their forum profile, or alongside their name in parenthesis in any document in which names appear (e.g. the shared notes for progress calls). Community members are expected to respect the preferred gender pronouns of other members.

  2. Assume Good Faith

    FreedomBox contributors have many ways of pursuing our common goal of creating a free server operating system which may differ from your ways. Assume that other people are working towards this goal.

    Note that many of our Contributors are not native English speakers or may have different cultural backgrounds. Assume good faith when misunderstandings arise.

  3. Be Collaborative

    FreedomBox is a large and complex project; there is always more to learn within FreedomBox. It’s good to ask for help when you need it. Similarly, offers for help should be seen in the context of our shared goal of improving FreedomBox.

    When you make something for the benefit of the project, be willing to explain to others how it works, so that they can build on your work to make it even better.

    The FreedomBox community values non-code contributions, including design contributions.

    The FreedomBox community also values newcomers and provides tasks for first-time contributors using the “beginner” label in our issue tracking system.

  4. Try To Be Concise

    Keep in mind that what you write may be read by hundreds of people. Writing a short email or forum post means people can follow the conversation as efficiently as possible. When a long explanation is necessary, consider adding a summary.

    Try to bring new arguments to a conversation so that each contribution adds something unique to the thread, keeping in mind that the rest of the thread still contains the other messages with arguments that have already been made.

    Try to stay on topic, especially in discussions that are already fairly large.

  5. Be Open

    Most means of communication used by the FreedomBox community allow for public and private methods of communication. When it would contribute to the community’s knowledge base, you should preferably use public methods of communication for FreedomBox-related discussions. This applies to messages for help or FreedomBox-related support, too; not only is a public support request much more likely to result in an answer to your question, it also makes sure that any inadvertent mistakes made by people answering your question will be more easily detected and corrected.

    Our community strives to avoid jargon and other non-inclusive language that can alienate or make people feel excluded. Our community also strives to encourage and recognize quiet voices. Though our community mostly communicates in English, we recognize that English may not be the first language of all contributors. Where possible, we provide notes of meetings and conference calls. We encourage and support localization of our documentation using a community edited Wiki. We encourage and support the localization of our software user interface using both web-based and traditional translation tools.

  6. In Case of Problems

    While this code of conduct should be adhered to by participants, we recognize that sometimes people may have a bad day, or be unaware of some of the guidelines in this code of conduct. When violations happen, you have three avenues for enforcement. (1) You may reach out to the person who violated the code of conduct and point out it out to them. Such messages may be in public or in private, whatever you decide is most appropriate. However, regardless of whether the message is public or not, it should still adhere to the relevant parts of this code of conduct; in particular, it should not be abusive or disrespectful. (2) You may report the violation to a community member who is listed in the “Contacts” section below and, if desired, ask for assistance mediating a resolution. (3) You may report the violation to a staff member at the FreedomBox Foundation and, if desired, ask for assistance mediating a resolution. Ultimately, all reports will be responded to in a matter appropriate to the specific circumstances of the violation, and the reporter, reported, and all others impacted will be updated.

    If you choose to report a violation to either a community member or a FreedomBox Foundation staff member, reports should be made in private. To find contact information for these parties, please see “Contacts” section below.

Contacts

The following individuals, listed in alphabetical order, have volunteered to be contacted in case of problems. Please feel free to reach out to any or all of them:

  • Danny Haidar (FreedomBox Foundation staff member): haidar [at] freedomboxfoundation.org
  • James Valleroy (FreedomBox community member): jvalleroy [at] mailbox.org
  • Sunil Mohan Adapa (FreedomBox community member): sunil [at] medhas.org

Notes:

  1. This code of conduct was adapted from Debian’s Code of Conduct: https://www.debian.org/code_of_conduct

  2. This code of conduct took benefits from the guidance provided by Mozilla’s “Open Source Inclusion Basic Checklist for Projects”: https://github.com/mozilla/diversity/blob/master/evaluation_tools/governance-basic.md

1 Like

I can’t create merge requests in gitlab right now, perhaps due to the reported partial downtime of https://salsa.debian.org.

Once salsa is accepting merge requests again, I can upload the file to gitlab.

In the meantime, folks are welcome to comment on this final draft and suggest any last minute changes.