Index: head/en_US.ISO8859-1/htdocs/internal/code-of-conduct.xml =================================================================== --- head/en_US.ISO8859-1/htdocs/internal/code-of-conduct.xml (revision 46986) +++ head/en_US.ISO8859-1/htdocs/internal/code-of-conduct.xml (revision 46987) @@ -1,154 +1,154 @@ ]> &title; $FreeBSD$
Those in the &os; community should have a right to be free from hate speech, harassment and abuse, but not a right not to be offended.

Introduction

We expect everyone involved with the &os; project to follow this Code of Conduct. This not only includes developers and contributors to &os; but also anyone posting to &os; mailing lists or using the &os; Forums or chatting on &os; specific IRC channels, or otherwise interacting with the &os; community.

Each individual's behaviour is primarily a matter for their personal conscience. Even so, there are limits whose breach will not be tolerated. This page explains what is normally expected of &os; community members, and what is absolutely required.

Interpersonal Interaction

Always strive to present a civil and courteous demeanour in your dealings with other project members; moreso when dealing with third parties from outside the project. Avoid foul or abusive language: remember that cultural standards differ, and that what may seem to you to be a very mild statement can be deeply shocking to another. Avoid contentious topics (unless directly technically relevant). These things all have their places, but not when they are out of context here.

Try not to take offense where no offense was intended. Not everyone speaks or writes English fluently. Not everyone can express themselves clearly. Give people the benefit of the doubt. Even if the intent was to provoke, do not rise to it.

Conflict is inevitable, but unseemly conduct is not. If you must disagree forcefully, do so within the appropriate technical discussion group and in a manner that will be acceptable to your audience. Stay focused on the topic at hand. Heated arguments have a way of dragging in bystanders and mutating until the original point is lost.

Stick to the facts. Anyone may disagree with you: this does not give you a license to descend into personal insults. If your arguments cannot stand up in their own right, then either admit defeat gracefully or formulate better arguments.

What Will Not Be Tolerated

The following will not be tolerated, and can result in expulsion from the community

&os; is a meritocracy. There can be no place within the &os; Community for discriminatory speech or action. We do not believe anyone should be treated any differently based on who they are, where they are from, where their ancestors were from, what they look like, what gender they identify as, who they choose to sleep with, how old they are, their physical capabilities or what sort of religious beliefs they may hold. What matters is the contribution they are able to make to the project, and only that.

There is no place within the &os; Community for behaviour intended to intimidate or persecute other members of the community. No one should have any cause to fear involvement with the &os; project.

We will not tolerate any member of the community, either publically or privately giving aid or encouragement to any third party to behave in such a way towards any members of the &os; community.

Core will remove any and all access to &os; resources or privileges for whatever period it deems fit, up to and including a permanent ban where it rules that a transgression has happened.

In Case of Conflict

If there are a sustained set of objections to a change you have made, be graceful and revert what you have done. Objections are hardly likely to be raised for trivial reasons, and commits can always be re-applied. The potential loss of reputation for the project from shipping bad code is permanent.

Seeking review beforehand is the best way to avoid misunderstanding. It is not just good practice for improving code quality: it facilitates putting opposing technical arguments clearly and reasonably.

It is strongly encouraged that you consult maintainers before making changes in their particular areas, although in many areas some teams have given blanket approval for certain types of change. For instance, various types of sweeping updates to the ports are permitted without reference to individual port maintainers. It is the duty of committers and maintainers to keep up-to-date with such standards and practices, and abide by them. Getting maintainer approval for any change, even if not strictly required, is never a bad thing, and certainly courteous.

If you cannot agree, who should you turn to for arbitration? Core itself is directly responsible for the base system, but has delegated control over ports, documentation, release engineering and security related functions to sub-committees. Operational control of &os; cluster servers, user accounts, e-mail, various web-based and other services have been similarly devolved to specific teams. These teams are the first line of resort when disputes cannot be resolved and require mediation. Failing that, a decision by core will be final.