create project code of conduct #2163
see newer draft here, ignore below.
longer draft based on OSI CoC:
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
Be civil and considerate
Assume good faith
Respect time and attention
Disclose potential conflicts
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.
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:
shorter draft based on GNOME CoC:
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.
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.
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.
I added a few other CoCs to the list:
I think these go in a better direction. I have used the Contributor CoC as a template this time, and incorporated your feedback Joanna:
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.
Examples of behavior that contributes to creating a positive environment include:
Examples of unacceptable behavior by participants include:
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.
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.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at
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.
for the email address I would say create a new email address
Thank you for working on this, Michael! I have some comments and suggestions on this latest draft.
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.
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'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.
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.
I think the right solution is just to have it end "or other similar characteristic" as is in the Rust CoC. added that.
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":
I think it would be a mistake to try to force people to do any of these things (except maybe the second one).
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?:
It's still the same thing I quoted above:
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.
Yes, much better.
okay what would we like for the contact email address? I proposed:
I would like a CoC up for the GSoC application.
Sure, we can add such email address. Done.
Perhaps it would be a good idea to include something to the effect of:
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.
- Add introduction explaining the purpose of the document, what it is intended to be, and what it is not intended to be (Closes QubesOS/qubes-issues#4377) - Make heading capitalization consistent - Use reference-style links in accordance with our Documentation Guidelines Original Code of Conduct issue: QubesOS/qubes-issues#2163 CC: @mfc, @rootkovska, @marmarek