Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 Jul 2015 17:56:31 +0000 (UTC)
From:      Matthew Seaman <matthew@FreeBSD.org>
To:        doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org
Subject:   svn commit: r46976 - in head/en_US.ISO8859-1: articles/committers-guide htdocs/internal
Message-ID:  <201507141756.t6EHuVV2040298@repo.freebsd.org>

next in thread | raw e-mail | index | archive | help
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>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201507141756.t6EHuVV2040298>