The &os; Committers' Big List of Rules

From owner-svn-doc-head@freebsd.org Tue Jul 14 17:56:32 2015 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32DE79A102A; Tue, 14 Jul 2015 17:56:32 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2177EB9B; Tue, 14 Jul 2015 17:56:32 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.70]) by repo.freebsd.org (8.14.9/8.14.9) with ESMTP id t6EHuWqQ040302; Tue, 14 Jul 2015 17:56:32 GMT (envelope-from matthew@FreeBSD.org) Received: (from matthew@localhost) by repo.freebsd.org (8.14.9/8.14.9/Submit) id t6EHuVV2040298; Tue, 14 Jul 2015 17:56:31 GMT (envelope-from matthew@FreeBSD.org) Message-Id: <201507141756.t6EHuVV2040298@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: matthew set sender to matthew@FreeBSD.org using -f From: Matthew Seaman Date: Tue, 14 Jul 2015 17:56:31 +0000 (UTC) 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 X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 17:56:32 -0000 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 The &os; Committers' Big List of Rules + Everyone involved with the &os; project is expected to + abide by the Code of Conduct available from + http://www.FreeBSD.org/internal/code-of-conduct.html. + 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 Code of + Conduct specific to committers. + Respect other committers. @@ -3182,8 +3191,7 @@ Relnotes: yes Do not fight in public with other committers; it looks - bad. If you must strongly disagree about - something, do so only in private. + bad. @@ -3250,7 +3258,7 @@ Relnotes: yes Details - + Respect other committers. @@ -3324,19 +3332,20 @@ Relnotes: yes 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 surprized - 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. + 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 surprized 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. When in doubt, ask for review! @@ -3431,8 +3440,7 @@ Relnotes: yes Do not fight in public with other committers; it looks - bad. If you must strongly disagree about - something, do so only in private. + bad. 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 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. + 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. @@ -3646,6 +3655,110 @@ Relnotes: yes + + + Privacy and Confidentiality + + + + Most &os; business is done in public. + + &os; is an open project. Which + means that not only can anyone use the source code, but + that most of the development process is open to public + scrutiny. + + + + Certain sensitive matters must remain private or + held under embargo. + + 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. + + + + The Security Officer has sole control over the + release of security advisories. + + 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. + + + + Communications with Core are kept confidential for as + long as necessary. + + 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. + + + + Non-disclosure Agreements may be required for access + to certain commercially sensitive data. + + 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. + + + + Private communications should not be made + public without permission. + + 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. + + + + Communications on project-only or restricted access + channels should be treated as private. + + 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. + + + + Core may approve publication. + + 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. + + + 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 @@ + + +]> + + + + &title; + + $FreeBSD$ + + + + +

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.

+ +

Introduction

+ +

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.

+ +

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.

+ +

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 when they are out of context + here.

+ +

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 focussed 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 harrassment.
Incitement to or condoning of any of these.

+ +

&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.

+ +

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.

+ +

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.

+ +

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.

+ +

In Case of Conflict

+ +

Backout contentious 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 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.

+ +

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 specific teams. These teams + are the first line of resort should disputes prove insoluble and + require mediation. Failing that, a decision by core will be + final.

+ +