create project code of conduct

[mfc]

this code of conduct would include project mailing lists, etc.

It would be mentioned or linked to on:

• the participation page: https://www.qubes-os.org/doc/contributing/
• mailing list page: https://www.qubes-os.org/mailing-lists/

existing codes of conduct for inspiration:

• Debian: https://www.debian.org/code_of_conduct
• OSI: https://opensource.org/codeofconduct
• Mozilla: https://www.mozilla.org/en-US/about/governance/policies/participation/
• GNOME: https://wiki.gnome.org/action/show/Foundation/CodeOfConduct
• Ubuntu: http://www.ubuntu.com/about/about-ubuntu/conduct
• NodeJS: https://github.com/nodejs/node/blob/master/CODE_OF_CONDUCT.md
• Contributor CoC: http://contributor-covenant.org/version/1/4/
• Rust CoC (and Moderator policy): https://www.rust-lang.org/en-US/conduct.html

there are also resources for events (as well as mailing lists / communities)

• --> Code of Conduct builder: http://www.codeofconduct.tools
• CItizen Lab Summer Institute: https://citizenlab.org/summerinstitute/codeofconduct.html
• xvzf: http://xvzf.io/

Feel free to draft below.

[mfc]

see newer draft here, ignore below.

longer draft based on OSI CoC:

Introduction

The Qubes OS mailing lists and other projects environments aim to facilitate constructive discussion of issues related to Qubes OS project mission of a "reasonably secure OS". We can achieve this, in part, by behaving well towards each other, so that the broadest diversity of participants - both amateur and professional, new and experienced - feel that the lists are welcoming and useful.

This code of conduct helps maintain that environment by capturing the conduct we aspire to when we participate in discussions at Qubes OS.

We Strive To:

Be friendly and patient

1. We are volunteers, and so a sense of fun is part of why we do what we do. Be positive and engaging, rather than snarky.
2. If someone asks for help it is because they need it. Politely suggest specific documentation or more appropriate venues where appropriate. Avoid aggressive or vague responses.

Be civil and considerate

1. Disagreement is no excuse for poor conduct or personal attacks. A community where people feel uncomfortable is not a productive one.
2. If you would not feel comfortable saying something to a co-worker or acquaintance, it is probably not appropriate on an Qubes OS list either.

Assume good faith

1. Remember that the issues tackled by Qubes OS are often very complex and difficult to assess. If you disagree, please do so politely, by disputing logical errors and factual premises rather than by attacking individuals.
2. If something seems outrageous, check that you did not misinterpret it. Ask for clarification, rather than assuming the worst.

Respect time and attention

1. List members are often busy people. As a result, we value concision and clarity. Emails that are brief and to the point take more time to write, but are repaid many times over when other members of the list make the same effort.
2. Conversations should remain focused and on-topic. If you must change the topic, start a new thread by changing the topic line of your emails. Also, avoid flooding the list with long threads by reading the entire thread first, instead of responding quickly to many emails in a short period of time.
3. New members are welcome, but should be careful to respect the time and energy of long-time list members by doing research in FAQs and with search engines before asking questions.

Disclose potential conflicts

1. List discussions often involve interested parties. We expect participants to be aware when they are conflicted due to employment or other projects they are involved in, and disclose those interests to other project members.
2. When in doubt, over-disclose. Perceived conflicts of interest are important to address, so that the lists’ decisions are credible even when unpopular, difficult or favorable to the interests of one group over another.

Interpretation

This code is not exhaustive or complete. It is not a rulebook; it serves to distill our common understanding of a collaborative, shared environment and goals. We expect it to be followed in spirit as much as in the letter.

Enforcement

Most members of the Qubes OS community always comply with this code, not because of the existence of the code, but because they have long experience participating in open source communities where the conduct described above is normal and expected. However, failure to observe the code may be grounds for reprimand, probation, or removal from the lists.

If you have concerns about someone’s conduct:

• Direct contact: it is always appropriate to email a list member, mention that you think their behavior was out of line, and (if necessary) point them to this document.
• On-list: discussing conduct on-list, either as part of another message or as a standalone thread, is always acceptable. Note, though, that approaching the person directly can be better, as it tends to make them less defensive, and it respects the time of other list members, so you probably want to try direct contact first.
• Moderators: You can reach the list moderators (Andrew David Wong and Marek Marczykowski) through the addresses they use for on-list communication.

---

shorter draft based on GNOME CoC:

Introduction

The Qubes OS project creates a reasonably secure OS. We achieve this by behaving well towards each other.

Therefore this document suggests what we consider ideal behaviour, so you know what to expect when getting involved in the Qubes OS project. This is who we are and what we want to be. There is no official enforcement of these principles, and this should not be interpreted like a legal document.

Advice

• Be respectful and considerate
  • Disagreement is no excuse for poor behaviour or personal attacks. Remember that a community where people feel uncomfortable is not a productive one.
• Be patient and generous
  • If someone asks for help it is because they need it. Do politely suggest specific documentation or more appropriate venues where appropriate, but avoid aggressive or vague responses such as "RTFM".
• Assume people mean well
  • Remember that decisions are often a difficult choice between competing priorities. If you disagree, please do so politely.
  • If something seems outrageous, check that you did not misinterpret it. Ask for clarification, but do not assume the worst.
• Try to be concise
  • Avoid repeating what has been said already. Making a conversation larger makes it difficult to follow, and people often feel personally attacked if they receive multiple messages telling them the same thing.~~~

[rootkovska]

I definitely don't like the first draft: it's way too long, and also goes too far in some suggestions, such e.g. to be 'friendly', instead of just being respectful, or asking people to disclose potential conflicts, something often not possible in reality due to NDAs, or other constrains (and we don't want to ask people to do things they will likely not be able to conform with).

The second proposal sounds much better, however I don't think we should include "Assume people mean well" point. Qubes is a security project, and the whole point of having a security defense is because there are (arguably many) people out there who do not mean well to others. Arguably there are (or will be) people who would not mean well for our project.

I'd also merge the single point mentioned under "Be patient and generous" (a virtue I consider somehow optional compared to the two other we ask for, namely: be respectful and concise) with the "Be respectful and considerate" section. Perhaps also changing: "If someone asks for help it is because they need it." by adding: "(...) because they likely need it", again we need to assume people will come with a mission to intentionally harm the project, not because they would need help.

[andrewdavidwong]

I suggest we explicitly include the concerns @rootkovska raises in the CoC. Otherwise, people who read it are unlikely to detect the absence of things like, "Assume people mean well." Or, even if they do notice the absence of such "friendliness directives," they may interpret that absence as an expression of a general lack of friendliness on behalf of the project or its team, rather than a carefully considered defensive posture.

[rootkovska]

I suggest we also add an explicit requirement that people do not abuse stereotypical social models for illustration of e.g. non-technical or absent-minded users (e.g. our mothers, sisters, etc.), see:
#2132 (comment)

[mfc]

I added a few other CoCs to the list:

• NodeJS: https://github.com/nodejs/node/blob/master/CODE_OF_CONDUCT.md
• Contributor CoC: http://contributor-covenant.org/version/1/4/
• Rust CoC (and Moderator policy): https://www.rust-lang.org/en-US/conduct.html

I think these go in a better direction. I have used the Contributor CoC as a template this time, and incorporated your feedback Joanna:

---

Our Pledge

The Qubes OS project creates a reasonably secure OS. In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to make participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, sexual identity and orientation, or other characteristic.

Our Standards

Examples of behavior that contributes to creating a positive environment include:

• Using welcoming and inclusive language
• Being respectful of differing viewpoints and experiences
• Gracefully accepting constructive criticism
• Focusing on what is best for the community
• Showing empathy towards other community members

Examples of unacceptable behavior by participants include:

• The use of sexualized language or imagery and unwelcome sexual attention or advances
• Trolling, insulting/derogatory comments, and personal or political attacks
• Reinforcing stereotypical models for illustration of non-technical users (e.g. our mothers/grandmothers, etc.)
• Public or private harassment, as defined by the Citizen Code of Conduct
• Publishing others' private information, such as a physical or electronic address, without explicit permission
• Other conduct which could reasonably be considered inappropriate in a professional setting

Our Responsibilities

Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. This action can include removing, editing, or rejecting comments, commits, code, wiki edits, issues, and other contributions, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.

Scope

This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.

Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at mods@qubes-os.org. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.

Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.

Attribution

This Code of Conduct is adapted from the Contributor Covenant, version 1.4 and the Rust Code of Conduct.

---

for the email address I would say create a new email address mods@qubes-os.org and have it alias to Andrew, Marek, myself, and Joanna (if you want to be part of it). Or we could use an existing alias address.

[andrewdavidwong]

Thank you for working on this, Michael! I have some comments and suggestions on this latest draft.

The Qubes OS project creates a reasonably secure OS. We achieve this by behaving well towards each other.

Nitpick: Strictly speaking, that's not true. We achieve it through various forms of work. We could do that very same work even while being mean to each other, but for various reasons, we're committed not to doing so.

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to make participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.

Listing things like this is always problematic because it gives the appearance of an exhaustive list, but you can never give an exhaustive list of examples that fully capture the principle you're attempting to express. It's better just to state the principle, then maybe give some representative examples (and explicitly state that they don't constitute an exhaustive list).

Examples of behavior that contributes to creating a positive environment include: [...] Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct

I'm not sure exactly what this means, but surely we don't want to say that people's conduct must contribute to creating a positive environment. If someone's conduct is merely neutral with respect to these standards, we shouldn't interfere with it.

[mfc]

The Qubes OS project creates a reasonably secure OS. We achieve this by behaving well towards each other.

Nitpick: Strictly speaking, that's not true. We achieve it through various forms of work. We could do that very same work even while being mean to each other, but for various reasons, we're committed not to doing so.

sure, whatever language we want to put there for why we have a CoC in the first place. I just removed that line since it's a bit redundant anyway.

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to make participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.

Listing things like this is always problematic because it gives the appearance of an exhaustive list, but you can never give an exhaustive list of examples that fully capture the principle you're attempting to express. It's better just to state the principle, then maybe give some representative examples (and explicitly state that they don't constitute an exhaustive list).

I think the right solution is just to have it end "or other similar characteristic" as is in the Rust CoC. added that.

Examples of behavior that contributes to creating a positive environment include: [...] Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct

I'm not sure exactly what this means, but surely we don't want to say that people's conduct must contribute to creating a positive environment. If someone's conduct is merely neutral with respect to these standards, we shouldn't interfere with it.

I don't think that's what that is saying. you seem to be defining "neutral" to the CoC as not bad behavior, in which case none of things listed would apply. This is saying in the context of bad behavior, here are some things that the project maintainers can do to enforce the CoC.

[andrewdavidwong]

Examples of behavior that contributes to creating a positive environment include: [...] Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct

I'm not sure exactly what this means, but surely we don't want to say that people's conduct must contribute to creating a positive environment. If someone's conduct is merely neutral with respect to these standards, we shouldn't interfere with it.

I don't think that's what that is saying. you seem to be defining "neutral" to the CoC as not bad behavior, in which case none of things listed would apply. This is saying in the context of bad behavior, here are some things that the project maintainers can do to enforce the CoC.

No, there's a whole section of "examples of behavior that contributes to creating a positive environment":

Using welcoming and inclusive language
Being respectful of differing viewpoints and experiences
Gracefully accepting constructive criticism
Focusing on what is best for the community
Showing empathy towards other community members

I think it would be a mistake to try to force people to do any of these things (except maybe the second one).

[mfc]

Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.

again, I'm not sure where you are reading into it that project maintainers must force people to have good behavior.

if we modify the section to the following would that help?:

Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. This action can include removing, editing, or rejecting comments, commits, code, wiki edits, issues, and other contributions, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.

[andrewdavidwong]

again, I'm not sure where you are reading into it that project maintainers must force people to have good behavior.

It's still the same thing I quoted above:

Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct

Again, I'm not sure exactly what this means. If it doesn't mean that we're going to force anyone to exhibit good behavior, great! But it could easily be read that way.

if we modify the section to the following would that help?: [...]

Yes, much better.

[mfc]

okay what would we like for the contact email address? I proposed:

for the email address I would say create a new email address mods@qubes-os.org and have it alias to Andrew, Marek, myself, and Joanna (if you want to be part of it). Or we could use an existing alias address.

I would like a CoC up for the GSoC application.

[andrewdavidwong]

okay what would we like for the contact email address? I proposed: [...]

That sounds good to me. @rootkovska, @marmarek, any objections?

[marmarek]

Sure, we can add such email address. Done.
But for the CoC itself, I haven't seen @rootkovska feedback for the last version. As for my opinion, I like the last 3 sections of it. Not sure about "Our Standards" section defined by examples. But it do include all the important parts, so it's I think it may be ok.

[jpouellet]

Perhaps it would be a good idea to include something to the effect of:

Expect all contributions to be reviewed with some amount of healthy adversarial skepticism, regardless of your perceived standing in the community. This is a security project, and allowing ourselves to get complacent while reviewing code simply because it comes from a well-known party would not be in the best interest of the project. Please try not to get offended if you perceive your contributions as being met with distrust -- we are most definitely thankful and appreciative of your efforts, but must also remain vigilant in order to ensure continued quality and safeguard against potential sabotage.

Personally, if my proposed changes were to be considered with less skepticism or reviewed less thoroughly simply because they come from me, I would be somewhat concerned. I may have been contributing positively towards the goals of the project so far, but I might actually just be waiting for the right moment to sneak in a critical bug. I can honestly say that I do not ever intend to do so, but of course you have no reason to believe me when I say so either.

[mfc]

sounds good, in which section do you see this living?

[jpouellet]

I don't know. Maybe its own section at the end? QubesOS/qubesos.github.io#80

[andrewdavidwong]

@jpouellet: Merged, thanks!

[mfc]

let's get this mentioned on the mailing lists page and then close it:

QubesOS/qubesos.github.io#88