os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Introduce a new Code of Conduct.

Browse source 
Update the Committer's Guide

  - section 21 covers much of the same areas as the new Code of
    Conduct, but the CoC is authoritative.  Update wording where
    there is some disagreement.

  - Add a new section on Privacy and Confidentiality which was felt to
    be too committer specific to go into the general Code of Conduct.

With hat:	core-secretary
Reviewed by:	gjb, core
Approved by:	core
This commit is contained in:
Matthew Seaman 2015-07-14 17:56:30 +00:00
parent 5f94814b76
commit 319e698e06
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=46976
3 changed files with 304 additions and 35 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

183
en_US.ISO8859-1/articles/committers-guide/article.xml
View file

@ -3140,6 +3140,15 @@ Relnotes: yes</programlisting>
<sect1 xml:id="rules">
<title>The &os; Committers' Big List of Rules</title>
<para>Everyone involved with the &os; project is expected to
abide by the <emphasis>Code of Conduct</emphasis> available from
<link xlink:href="&url.base;/internal/code-of-conduct.html"
>http://www.FreeBSD.org/internal/code-of-conduct.html</link>.
As committers, you form the public face of the project, and how
you behave has a vital impact on the public perception of it.
This guide expands on the parts of the <emphasis>Code of
Conduct</emphasis> specific to committers.</para>
<orderedlist>
<listitem>
<para>Respect other committers.</para>
@ -3182,8 +3191,7 @@ Relnotes: yes</programlisting>
<listitem>
<para>Do not fight in public with other committers; it looks
bad. If you must <quote>strongly disagree</quote> about
something, do so only in private.</para>
bad.</para>
</listitem>
<listitem>
@ -3250,7 +3258,7 @@ Relnotes: yes</programlisting>
<sect2>
<title>Details</title>
<orderedlist>
<listitem xml:id="respect">
<para>Respect other committers.</para>
@ -3324,19 +3332,20 @@ Relnotes: yes</programlisting>
<para>The repository is not where changes should be
initially submitted for correctness or argued over, that
should happen first in the mailing lists and the commit
should only happen once something resembling consensus has
been reached. This does not mean that you have to ask
permission before correcting every obvious syntax error or
manual page misspelling, simply that you should try to
develop a feel for when a proposed change is not quite
such a no-brainer and requires some feedback first.
People really do not mind sweeping changes if the result
is something clearly better than what they had before,
they just do not like being <emphasis>surprized</emphasis>
by those changes. The very best way of making sure that
you are on the right track is to have your code reviewed
by one or more other committers.</para>
should happen first in the mailing lists or by use of the
Phabricator service and the commit should only happen once
something resembling consensus has been reached. This
does not mean that you have to ask permission before
correcting every obvious syntax error or manual page
misspelling, simply that you should try to develop a feel
for when a proposed change is not quite such a no-brainer
and requires some feedback first. People really do not
mind sweeping changes if the result is something clearly
better than what they had before, they just do not like
being <emphasis>surprized</emphasis> by those changes.
The very best way of making sure that you are on the right
track is to have your code reviewed by one or more other
committers.</para>
<para>When in doubt, ask for review!</para>
</listitem>
@ -3431,8 +3440,7 @@ Relnotes: yes</programlisting>
<listitem>
<para>Do not fight in public with other committers; it looks
bad. If you must <quote>strongly disagree</quote> about
something, do so only in private.</para>
bad.</para>
<para>This project has a public image to uphold and that
image is very important to all of us, especially if we are
@ -3443,23 +3451,24 @@ Relnotes: yes</programlisting>
is to minimize the effects of this until everyone has
cooled back down. That means that you should not air your
angry words in public and you should not forward private
correspondence to public mailing lists or aliases. What
people say one-to-one is often much less sugar-coated than
what they would say in public, and such communications
therefore have no place there - they only serve to inflame
an already bad situation. If the person sending you a
flame-o-gram at least had the grace to send it privately,
then have the grace to keep it private yourself. If you
feel you are being unfairly treated by another developer,
and it is causing you anguish, bring the matter up with
core rather than taking it public. Core will do its best
to play peace makers and get things back to sanity. In
cases where the dispute involves a change to the codebase
and the participants do not appear to be reaching an
amicable agreement, core may appoint a mutually-agreeable
third party to resolve the dispute. All parties involved
must then agree to be bound by the decision reached by
this third party.</para>
correspondence or other private communications to public
mailing lists, mail aliases, instant messaging channels or
social media sites. What people say one-to-one is often
much less sugar-coated than what they would say in public,
and such communications therefore have no place there -
they only serve to inflame an already bad situation. If
the person sending you a flame-o-gram at least had the
grace to send it privately, then have the grace to keep it
private yourself. If you feel you are being unfairly
treated by another developer, and it is causing you
anguish, bring the matter up with core rather than taking
it public. Core will do its best to play peace makers and
get things back to sanity. In cases where the dispute
involves a change to the codebase and the participants do
not appear to be reaching an amicable agreement, core may
appoint a mutually-agreeable third party to resolve the
dispute. All parties involved must then agree to be bound
by the decision reached by this third party.</para>
</listitem>
<listitem>
@ -3646,6 +3655,110 @@ Relnotes: yes</programlisting>
</listitem>
</orderedlist>
</sect2>
<sect2>
<title>Privacy and Confidentiality</title>
<orderedlist>
<listitem>
<para>Most &os; business is done in public.</para>
<para>&os; is an <emphasis>open</emphasis> project. Which
means that not only can anyone use the source code, but
that most of the development process is open to public
scrutiny.</para>
</listitem>
<listitem>
<para>Certain sensitive matters must remain private or
held under embargo.</para>
<para>There unfortunately cannot be complete transparency.
As a &os; developer you will have a certain degree of
privileged access to information. Consequently you are
expected to respect certain requirements for
confidentiality. Sometimes the need for confidentiality
comes from external collaborators or has a specific time
limit. Mostly though, it is a matter of not releasing
private communications.</para>
</listitem>
<listitem>
<para>The Security Officer has sole control over the
release of security advisories.</para>
<para>Where there are security problems that affect many
different operating systems, &os; frequently depends on
early access in order to be able to prepare advisories for
coordinated release. Unless &os; developers can be
trusted to maintain security, such early access will not
be made available. The Security Officer is responsible
for controlling pre-release access to information about
vulnerabilities, and for timing the release of all
advisories. He may request help under condition of
confidentiality from any developer with relevant knowledge
in order to prepare security fixes.</para>
</listitem>
<listitem>
<para>Communications with Core are kept confidential for as
long as necessary.</para>
<para>Communications to core will initially be treated as
confidential. Eventually however, most of Core's business
will be summarized into the monthly or quarterly core
reports. Care will be taken to avoid publicising any
sensitive details. Records of some particularly sensitive
subjects may not be reported on at all and will be
retained only in Core's private archives.</para>
</listitem>
<listitem>
<para>Non-disclosure Agreements may be required for access
to certain commercially sensitive data.</para>
<para>Access to certain commercially sensitive data may
only be available under a Non-Disclosure Agreement. The
FreeBSD Foundation legal staff must be consulted before
any binding agreements are entered into.</para>
</listitem>
<listitem>
<para>Private communications should not be made
public without permission.</para>
<para>Beyond the specific requirements above there is a
general expectation not to publish private communications
between developers without the consent of all parties
involved. Ask permission before forwarding a message onto
a public mailing list, or posing it to a forum or website
that can be accessed by other than the original
correspondents.</para>
</listitem>
<listitem>
<para>Communications on project-only or restricted access
channels should be treated as private.</para>
<para>Similarly to personal communications, certain
internal communications channels, including &os; Committer
only mailing lists and restricted access IRC channels
should be considered as private communications. You need
permission in order to publish material from these
sources.</para>
</listitem>
<listitem>
<para>Core may approve publication.</para>
<para>Where it is impractical to obtain permission due to
the number of correspondents or where permission to
publish is unreasonably withheld, Core may approve release
of such private matters that merit more general
publication.</para>
</listitem>
</orderedlist>
</sect2>
</sect1>
<sect1 xml:id="archs">

1
en_US.ISO8859-1/htdocs/internal/Makefile
View file

@ -10,6 +10,7 @@
DOCS= about.xml
DOCS+= bylaws.xml
DOCS+= clusteradm.xml
DOCS+= code-of-conduct.xml
DOCS+= core-vote.xml
DOCS+= data.xml
DOCS+= developer.xml

155
en_US.ISO8859-1/htdocs/internal/code-of-conduct.xml Normal file
View file

@ -0,0 +1,155 @@
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//FreeBSD//DTD XHTML 1.0 Transitional-Based Extension//EN"
"http://www.FreeBSD.org/XML/share/xml/xhtml10-freebsd.dtd" [
<!ENTITY title "FreeBSD Code of Conduct">
]>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>&title;</title>
<cvs:keyword xmlns:cvs="http://www.FreeBSD.org/XML/CVS">$FreeBSD$</cvs:keyword>
</head>
<body class="navinclude.docs">
<blockquote> 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.</blockquote>
<h2>Introduction</h2>
<p>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 members of the &os;
community.</p>
<p>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.</p>
<h2>Interpersonal Interaction</h2>
<ul>
<li>Keep it civil.</li>
<li>Be tolerant.</li>
<li>Remember that you are in public and that your actions
determine the public perception of the project.</li>
<li>Do not make it personal. Do not take it personally.</li>
</ul>
<p>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.</p>
<p>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.</p>
<p>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 focussed on the topic at hand. Heated
arguments have a way of dragging in bystanders and mutating
until the original point is lost.</p>
<p>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.</p>
<h2>What Will Not Be Tolerated</h2>
<p>The following will not be tolerated, and can result in
expulsion from the community</p>
<ul>
<li>Discrimination based on gender, race, nationality,
sexuality, religion, age or physical disability.</li>
<li>Bullying or systematic harrassment.</li>
<li>Incitement to or condoning of any of these.</li>
</ul>
<p>&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.</p>
<p>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.</p>
<p>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.</p>
<p>Core may remove any and all access to &os; resources or
privileges for whatever period it deems fit, up to and including
a permanent ban where such transgression has been
demonstrated.</p>
<h2>In Case of Conflict</h2>
<ul>
<li>Backout contentious changes first, then argue your
case.</li>
<li>Ask for review.</li>
<li>Seek approval from maintainers.</li>
<li>When no mutually satisfactory resolution can be achieved,
defer to security-officer, doceng, portmgr or core</li>
</ul>
<p>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.</p>
<p>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.</p>
<p>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 update 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.</p>
<p>If you cannot agree, who should you turn to for arbitration?
Core itself is directly responsible for the base system, but has
devolved 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 <a
href="../administration.html">specific teams</a>. These teams
are the first line of resort should disputes prove insoluble and
require mediation. Failing that, a decision by core will be
final.</p>
</body>
</html>