From: | Kevin Grittner <kgrittn(at)gmail(dot)com> |
---|---|
To: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Brian Dunavant <brian(at)omniti(dot)com>, "Psql_General (E-mail)" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: WIP: CoC V5 |
Date: | 2016-01-13 15:34:35 |
Message-ID: | CACjxUsOT+QwZMSMr49jPeUQ7crmN76XqQoe0ceX4bK9K3kEGRw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Jan 12, 2016 at 10:04 PM, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
> On 01/12/2016 07:10 PM, Tom Lane wrote:
>> Kevin Grittner <kgrittn(at)gmail(dot)com> writes:
>>> * To maintain a safe, respectful, productive and collaborative
>>> environment all participants must ensure that their language and
>>> actions are free of personal attacks and disparaging remarks of any
>>> kind.
>>
>> The "disparaging remarks" part of this could easily be taken to forbid
>> technical criticism of any sort, eg "this patch is bad because X,Y, and
>> Z", even when X,Y, and Z are perfectly neutral technical points. "Of any
>> kind" doesn't improve that either. I'm on board with the "personal
>> attacks" part. Maybe "disparaging personal remarks" would be better?
>
> Hrm, I see your point but the definition of disparaging is:
>
> expressing the opinion that something is of little worth; derogatory.
Below is a modified version of what I posted, attempting to improve
it based on further thoughts of my own as well as suggestions from
Tom, JD, and Bill. I see a lot to like in the variation proposed
by Chris, but wasn't sure quite how to meld that with this. I've
left off the enforcement part for now.
I still feel it is more productive to discuss a proposed document
than proposed language for some "motion to adopt". (I'm not sure
where such a motion would be made and adopted.)
== PostgreSQL Community Code of Conduct (CoC) ==
This document is intended to provide community guidelines for
creating and enforcing a safe, respectful, productive, and
collaborative place for any person who is willing to contribute in
a safe, respectful, productive and collaborative way. It applies
to all "collaborative space", which is defined as community
communications channels (such as mailing lists, IRC, submitted
patches, commit comments, etc.) and to public events (such as
meetings and conferences) which are associated with the PostgreSQL
community. Private communications which result from words or
actions in the collaborative space should also conform to the
standards stated here.
* Participants must ensure that their language and actions are free
of personal attacks and disparaging personal remarks. Critical
remarks regarding patches and/or technical work are necessary to
ensure a quality product; however, critical remarks directed at
individuals are not constructive and therefore not acceptable.
* When interpreting the words and actions of others, participants
should always assume good intentions. Consider that due to
language and cultural differences, something may be intended in a
benign or helpful way, even if some participants initially see a
possible interpretation which is otherwise.
* Participants must avoid sustained disruption of the collaborative
space, or any pattern of behavior which could reasonably be
considered harassment.
There is a distinction between words and actions taken within the
community and words and actions outside community communication
channels and events, but there is a gray area when using public
forums or social media where a person identifies as a member of
this community. Members of the community, especially those with a
high profile within the community, should be mindful of this and
avoid saying or doing anything in such venues which might create an
unwelcoming or hostile attitude toward the community.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | lodopidolo | 2016-01-13 15:47:47 | Call postgres PL/Python stored function from another PL/Python block. |
Previous Message | Tom Lane | 2016-01-13 15:02:38 | Re: Why PG uses nested-loop join when no indexes are available? |