On Sun, 10 Jan 2016 07:36:23 -0800
"Joshua D. Drake" <jd@commandprompt.com> wrote:
> Hey,
>
> For the record, my thoughts on a CoC are something like:
>
> 1. Be excellent to each other
> 2. If you don't know what that means, leave
> 3. If someone isn't being excellent please contact: XYZ
>
> With XYZ being a committee that determines the ABCs.
In general, I agree; but there are problems with 1 and 2.
The definition of "being excellent" varies from individual
to individual; but more importantly, from culture to culture.
As a result, pretty much everyone would have to leave as a
result of #2, because very few people know what "being
excellent" means to everyone involved.
As a result, I would feel REALLY bad for XYZ, who would be
put in the unenviable place of trying to mitigate disputes
with no guidance whatsoever.
So, the purpose of a CoC is twofold:
A) Define what "being excellent" means to this particular
community.
B) Provide a process for how to resolve things when "being
excellent" doesn't happen.
Without #1, nobody will want to do #2, as it's basically a
job that can never be done correctly.
But defining #1 is the really difficult part, because no matter
how you define it, there will be some people who disagree with
said definition.
The fact that Postgres has not needed a CoC up till now is a
testiment to the quality of the people in the community. However,
if Postgres continues to be more popular, the number of people
involved is going to increase. Simply as a factor of statistics,
the project will be forced to deal with some unsavory people at
some point. Having a CoC is laying the foundation to ensure that
dealing with those people involves the least pain possible. It
will always involve _some_ pain, but less is better.
I've done the job of #3 with other groups, and 99% of the time
there was nothing to do. The one incident I had to handle was
terrible, but at least I had some guidance on how to deal with
it.
--
Bill Moran
