Skip site navigation (1) Skip section navigation (2)

FreeBSD Code of Conduct


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 individual's 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.

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 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 here, where they are out of context.

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

  • Discrimination based on gender, race, nationality, sexuality, religion, age or physical disability.
  • Bullying or systematic harassment.
  • Incitement to or condoning of any of these.

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.

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.