path: root/ff/49e91fdad3a1750c4d2bc0e54ba7adef880d02

Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DBF3526C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 15 Oct 2015 00:02:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com
	[209.85.212.171])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B23D5110
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 15 Oct 2015 00:02:22 +0000 (UTC)
Received: by wieq12 with SMTP id q12so106962601wie.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 14 Oct 2015 17:02:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=iAeJ+CVMO4vqXzd+rVX9t6ZqVpF8DWRPzu/EOPa7j1M=;
	b=0YlVEr2q80D4vj6fA4tc93PneNtcaiXDmYOs1tc9b4NeRlbSrNE+2bfV/XjPJPymJ4
	Vf9v4x9likVW1ulNQH+PbtCa5lgyQ3d9mjqGeqbOrrZEkzyMwBfa+9ahTM+575FfFTa/
	y45g4N0+fuKvURSi3xyVVtzMPTsUmLqw/OHa5I8x6lLfZQey7kiKLVAWdreobHeW792T
	M3VUnKxmy9LcdZvUhZuobdF/Pr50k9fSE7JUVhkBxIHA+9NZFCJmbhlWnGiEWlpn7Pml
	lcc18/p0xlGuRHoLmpjvuAMc8F7np3xkJMttWywSFBeL6jcHVFAOKE0083LxGzv3kZ03
	FhYg==
MIME-Version: 1.0
X-Received: by 10.180.37.113 with SMTP id x17mr29355054wij.33.1444867341370;
	Wed, 14 Oct 2015 17:02:21 -0700 (PDT)
Received: by 10.28.158.9 with HTTP; Wed, 14 Oct 2015 17:02:21 -0700 (PDT)
Date: Wed, 14 Oct 2015 20:02:21 -0400
Message-ID: <CADm_WcYnq5sk=wdhqx5UysyS=fu7kRUrixOJC=QfoY5np1ATmA@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=e89a8f502ef8a14bad0522196485
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: [bitcoin-dev] Proposed list moderation policy and conduct
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Oct 2015 00:02:25 -0000

--e89a8f502ef8a14bad0522196485
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Introduction
-------------------
This mailing list, bitcoin-dev, aim to facilitate constructive discussion
of issues related to technical development of the bitcoin protocol and the
Bitcoin Core reference implementation.  We can achieve this, in part, by
behaving well towards each other, so that the broadest diversity of
participants - both amateur and professional, new and experienced - feel
that the lists are welcoming and useful.

This proposed policy helps maintain that environment by capturing the
conduct we aspire to when we participate in discussions on bitcoin-dev.

We Strive To:
-------------

*Be friendly and patient*

1. Many of us are volunteers, and so a sense of fun is part of why we do
what we do. Be positive and engaging, rather than snarky.
2. If someone asks for help it is because they need it. Politely suggest
specific documentation or more appropriate venues where appropriate. Avoid
aggressive or vague responses.

*Be civil and considerate*

1. Disagreement is no excuse for poor conduct or personal attacks. A
community where people feel uncomfortable is not a productive one.
2. If you would not feel comfortable saying something to a co-worker or
acquaintance, it is probably not appropriate on this list either.

*Assume good faith*

1. Remember that protocol & engineering questions are often very complex
and difficult to assess. If you disagree, please do so politely, by
disputing logical errors and factual premises rather than by attacking
individuals.
2. If something seems outrageous, check that you did not misinterpret it.
Ask for clarification, rather than assuming the worst.
3. For more, read https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith

*Respect time and attention*

1. List members are often busy people. As a result, we value concision and
clarity. Emails that are brief and to the point take more time to write,
but are repaid many times over when other members of the list make the same
effort.
2. Conversations should remain focused and on-topic. If you must change the
topic, start a new thread by changing the topic line of your emails. Also,
avoid flooding the list with long threads by reading the entire thread
first, instead of responding quickly to many emails in a short period of
time.
3. New members are welcome, but should be careful to respect the time and
energy of long-time list members by doing research in FAQs and with search
engines before asking questions.
4. Off-topic threads will be directed to other venues.

*Disclose potential conflicts*

1. List discussions often involve interested parties. We expect
participants to be aware when they are conflicted due to employment or
other projects they are involved in, and disclose those interests to other
project members.
2. When in doubt, over-disclose. Perceived conflicts of interest are
important to address, so that the lists=E2=80=99 decisions are credible eve=
n when
unpopular, difficult or favorable to the interests of one group over
another.



Interpretation
--------------

This policy is not exhaustive or complete. It is not a rulebook; it serves
to distill our common understanding of a collaborative, shared environment
and goals. We expect it to be followed in spirit as much as in the letter.

Enforcement
-----------

Most members of the bitcoin-dev community already comply with this policy,
not because of the existence of the policy, but because they have long
experience participating in open source communities where the conduct
described above is normal and expected. However, failure to observe the
code may be grounds for reprimand, probation, or removal from the lists.

If you have concerns about someone=E2=80=99s conduct:

* *Direct contact*: it is always appropriate to email a list member,
mention that you think their behavior was out of line, and (if necessary)
point them to this document.

* *On-list*: discussing conduct on-list, either as part of another message
or as a standalone thread, is always acceptable. Note, though, that
approaching the person directly can be better, as it tends to make them
less defensive, and it respects the time of other list members, so you
probably want to try direct contact first.

* *Moderators*: You can reach the list moderators through the addresses
they use for on-list communication.


Moderators
----------
The selection of moderators is intended to be a mix from various projects
and roles, and expressly intended to avoid cases where the set of
(moderators) equals the set of (bitcoin core committers) or similar.

TBD
Jeff Garzik
[btcdrak?  Johnathan?   Others were listed in the IRC meeting, but the
bitcoinstats site is down right here]



Further Context
---------------

Other resources, while not formally part of this code of conduct, can
provide useful context and guidance for good behavior.

1. Chapter 6 of Producing OSS, by OSI board member Karl Fogel, describes
common best practices for mailing list participation,
particularly [=E2=80=9CYou Are What You Write=E2=80=9D](
http://producingoss.com/en/communications.html#you-are-what-you-write) and
[=E2=80=9CAvoiding Common
Pitfalls"](http://producingoss.com/en/common-pitfalls.html).
2. [RFC 1855](https://www.ietf.org/rfc/rfc1855.txt), particularly section
2.1.1 (=E2=80=9CUser Guidelines for mail=E2=80=9D), also provides useful
guidelines for sending good emails.
3. [The Ubuntu Code of Conduct](
http://www.ubuntu.com/project/about-ubuntu/conduct) provides useful
guidance for group leaders.

This policy was inspired by [the GNOME Code of Conduct](
https://live.gnome.org/CodeOfConduct/), [the Mozilla Community Participatio=
n
Guidelines](https://www.mozilla.org/about/policies/participation.html),
[the Ubuntu Code of Conduct](
http://www.ubuntu.com/project/about-ubuntu/conduct), and other codes listed
at [the OpenHatch list of project codes of conduct](
https://openhatch.org/wiki/Project_codes_of_conduct).

--e89a8f502ef8a14bad0522196485
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>Introduction<br>-------------------<br>This mailing li=
st, bitcoin-dev, aim to facilitate constructive discussion of issues relate=
d to technical development of the bitcoin protocol and the Bitcoin Core ref=
erence implementation.=C2=A0 We can achieve this, in part, by behaving well=
 towards each other, so that the broadest diversity of participants - both =
amateur and professional, new and experienced - feel that the lists are wel=
coming and useful.<br><br>This proposed policy helps maintain that environm=
ent by capturing the conduct we aspire to when we participate in discussion=
s on bitcoin-dev.<br><br>We Strive To:<br>-------------<br><br>*Be friendly=
 and patient*<br><br>1. Many of us are volunteers, and so a sense of fun is=
 part of why we do what we do. Be positive and engaging, rather than snarky=
.<br>2. If someone asks for help it is because they need it. Politely sugge=
st specific documentation or more appropriate venues where appropriate. Avo=
id aggressive or vague responses.<div><br>*Be civil and considerate*<br><br=
>1. Disagreement is no excuse for poor conduct or personal attacks. A commu=
nity where people feel uncomfortable is not a productive one.<br>2. If you =
would not feel comfortable saying something to a co-worker or acquaintance,=
 it is probably not appropriate on this list either.<br><br>*Assume good fa=
ith*<br><br>1. Remember that protocol &amp; engineering questions are often=
 very complex and difficult to assess. If you disagree, please do so polite=
ly, by disputing logical errors and factual premises rather than by attacki=
ng individuals.<br>2. If something seems outrageous, check that you did not=
 misinterpret it. Ask for clarification, rather than assuming the worst.</d=
iv><div>3. For more, read <a href=3D"https://en.wikipedia.org/wiki/Wikipedi=
a:Assume_good_faith">https://en.wikipedia.org/wiki/Wikipedia:Assume_good_fa=
ith</a><br><br>*Respect time and attention*<br><br>1. List members are ofte=
n busy people. As a result, we value concision and clarity. Emails that are=
 brief and to the point take more time to write, but are repaid many times =
over when other members of the list make the same effort.<br>2. Conversatio=
ns should remain focused and on-topic. If you must change the topic, start =
a new thread by changing the topic line of your emails. Also, avoid floodin=
g the list with long threads by reading the entire thread first, instead of=
 responding quickly to many emails in a short period of time.<br>3. New mem=
bers are welcome, but should be careful to respect the time and energy of l=
ong-time list members by doing research in FAQs and with search engines bef=
ore asking questions.</div><div>4. Off-topic threads will be directed to ot=
her venues.<br><br>*Disclose potential conflicts*<br><br>1. List discussion=
s often involve interested parties. We expect participants to be aware when=
 they are conflicted due to employment or other projects they are involved =
in, and disclose those interests to other project members.<br>2. When in do=
ubt, over-disclose. Perceived conflicts of interest are important to addres=
s, so that the lists=E2=80=99 decisions are credible even when unpopular, d=
ifficult or favorable to the interests of one group over another.<br><br><b=
r><br>Interpretation<br>--------------<br><br>This policy is not exhaustive=
 or complete. It is not a rulebook; it serves to distill our common underst=
anding of a collaborative, shared environment and goals. We expect it to be=
 followed in spirit as much as in the letter.<br><br>Enforcement<br>-------=
----<br><br>Most members of the bitcoin-dev community already comply with t=
his policy, not because of the existence of the policy, but because they ha=
ve long experience participating in open source communities where the condu=
ct described above is normal and expected. However, failure to observe the =
code may be grounds for reprimand, probation, or removal from the lists.<br=
><br>If you have concerns about someone=E2=80=99s conduct:<br><br>* *Direct=
 contact*: it is always appropriate to email a list member, mention that yo=
u think their behavior was out of line, and (if necessary) point them to th=
is document.<br><br>* *On-list*: discussing conduct on-list, either as part=
 of another message or as a standalone thread, is always acceptable. Note, =
though, that approaching the person directly can be better, as it tends to =
make them less defensive, and it respects the time of other list members, s=
o you probably want to try direct contact first.<br><br>* *Moderators*: You=
 can reach the list moderators through the addresses they use for on-list c=
ommunication.<br><br><br>Moderators</div><div>----------</div><div>The sele=
ction of moderators is intended to be a mix from various projects and roles=
, and expressly intended to avoid cases where the set of (moderators) equal=
s the set of (bitcoin core committers) or similar.</div><div><br></div><div=
>TBD</div><div>Jeff Garzik</div><div>[btcdrak?=C2=A0 Johnathan? =C2=A0 Othe=
rs were listed in the IRC meeting, but the bitcoinstats site is down right =
here]</div><div><br></div><div><br></div><div><br>Further Context<br>------=
---------<br><br>Other resources, while not formally part of this code of c=
onduct, can provide useful context and guidance for good behavior.<br><br>1=
. Chapter 6 of Producing OSS, by OSI board member Karl Fogel, describes com=
mon best practices for mailing list participation,<br>particularly [=E2=80=
=9CYou Are What You Write=E2=80=9D](<a href=3D"http://producingoss.com/en/c=
ommunications.html#you-are-what-you-write">http://producingoss.com/en/commu=
nications.html#you-are-what-you-write</a>) and [=E2=80=9CAvoiding Common<br=
>Pitfalls&quot;](<a href=3D"http://producingoss.com/en/common-pitfalls.html=
">http://producingoss.com/en/common-pitfalls.html</a>).<br>2. [RFC 1855](<a=
 href=3D"https://www.ietf.org/rfc/rfc1855.txt">https://www.ietf.org/rfc/rfc=
1855.txt</a>), particularly section 2.1.1 (=E2=80=9CUser Guidelines for mai=
l=E2=80=9D), also provides useful<br>guidelines for sending good emails.<br=
>3. [The Ubuntu Code of Conduct](<a href=3D"http://www.ubuntu.com/project/a=
bout-ubuntu/conduct">http://www.ubuntu.com/project/about-ubuntu/conduct</a>=
) provides useful guidance for group leaders.<br><br>This policy was inspir=
ed by [the GNOME Code of Conduct](<a href=3D"https://live.gnome.org/CodeOfC=
onduct/">https://live.gnome.org/CodeOfConduct/</a>), [the Mozilla Community=
 Participation<br>Guidelines](<a href=3D"https://www.mozilla.org/about/poli=
cies/participation.html">https://www.mozilla.org/about/policies/participati=
on.html</a>), [the Ubuntu Code of Conduct](<a href=3D"http://www.ubuntu.com=
/project/about-ubuntu/conduct">http://www.ubuntu.com/project/about-ubuntu/c=
onduct</a>), and other codes listed at [the OpenHatch list of project codes=
 of conduct](<a href=3D"https://openhatch.org/wiki/Project_codes_of_conduct=
">https://openhatch.org/wiki/Project_codes_of_conduct</a>).</div></div>

--e89a8f502ef8a14bad0522196485--