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>