svn commit: r46976 - in head/en_US.ISO8859-1: articles/committers-guide htdocs/internal
Matthew Seaman
matthew at FreeBSD.org
Tue Jul 14 17:56:32 UTC 2015
Author: matthew (ports committer)
Date: Tue Jul 14 17:56:30 2015
New Revision: 46976
URL: https://svnweb.freebsd.org/changeset/doc/46976
Log:
Introduce a new Code of Conduct.
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
Added:
head/en_US.ISO8859-1/htdocs/internal/code-of-conduct.xml (contents, props changed)
Modified:
head/en_US.ISO8859-1/articles/committers-guide/article.xml
head/en_US.ISO8859-1/htdocs/internal/Makefile
Modified: head/en_US.ISO8859-1/articles/committers-guide/article.xml
==============================================================================
--- head/en_US.ISO8859-1/articles/committers-guide/article.xml Tue Jul 14 17:15:40 2015 (r46975)
+++ head/en_US.ISO8859-1/articles/committers-guide/article.xml Tue Jul 14 17:56:30 2015 (r46976)
@@ -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">
Modified: head/en_US.ISO8859-1/htdocs/internal/Makefile
==============================================================================
--- head/en_US.ISO8859-1/htdocs/internal/Makefile Tue Jul 14 17:15:40 2015 (r46975)
+++ head/en_US.ISO8859-1/htdocs/internal/Makefile Tue Jul 14 17:56:30 2015 (r46976)
@@ -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
Added: head/en_US.ISO8859-1/htdocs/internal/code-of-conduct.xml
==============================================================================
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/en_US.ISO8859-1/htdocs/internal/code-of-conduct.xml Tue Jul 14 17:56:30 2015 (r46976)
@@ -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>
More information about the svn-doc-head
mailing list