You are on page 1of 1

FreeBSD Code of Conduct

Those in the FreeBSD community should have a right to be free from


hate speech, harassment, and abuse, but not a right not to be offended.

1. Introduction
We expect everyone involved with the FreeBSD project to follow this
Code of Conduct. This not only includes developers and contributors
to FreeBSD but also anyone posting to FreeBSD mailing lists or using
the FreeBSD Forums or chatting on FreeBSD specific IRC channels,
or otherwise interacting with the FreeBSD community.
Each individuals behavior 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 FreeBSD community
members, and what is absolutely required.

2. Interpersonal Interaction
Keep it civil.
Be tolerant.
Remember that you are in public and that your actions
determine the public perception of the project.
Do not make it personal. Do not take it personally.
Always strive to present a civil and courteous demeanor 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.

3. What Will Not Be Tolerated


The following will not be tolerated, and can result in expulsion from
the community:
Discrimination based on gender, race, nationality, sexuality,
religion, age or physical disability.
Bullying or systematic harassment.
Incitement to or condoning of any of these.

FreeBSD is a meritocracy. There can be no place within the FreeBSD


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 FreeBSD Community for behavior
intended to intimidate or persecute other members of the community.
No one should have any cause to fear involvement with the FreeBSD
project.
We will not tolerate any member of the community, either publicly or
privately giving aid or encouragement to any third party to behave in
such a way towards any members of the FreeBSD community.
Core will remove any and all access to FreeBSD resources or privileges
for whatever period it deems fit, up to and including a permanent ban
where it rules that a transgression has happened.

4. In Case of Conflict
If contested, back out your changes first, then argue your case.
Ask for review.
Seek approval from maintainers.
When no mutually satisfactory resolution can be achieved,
defer to security-officer, doceng, portmgr, or core.
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 FreeBSD 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.
https://www.freebsd.org/administration.html

This is an American English version of the FreeBSD Code of Conduct retrieved on 15 July 2015.
For the official Code of Conduct, see https://www.freebsd.org/internal/code-of-conduct.html on the World Wide Web.

You might also like