Re: WIP: CoC V5 - Mailing list pgsql-general

From Chris Travers
Subject Re: WIP: CoC V5
Date
Msg-id CAKt_ZfskrAD05kur+aDcPSQD8kuwfhm=e_4LKyfHnSf4UWHCSA@mail.gmail.com
Whole thread Raw
In response to Re: WIP: CoC V5  ("Regina Obe" <lr@pcorp.us>)
Responses Re: WIP: CoC V5  (Geoff Winkless <pgsqladmin@geoff.dj>)
Re: WIP: CoC V5  ("Regina Obe" <lr@pcorp.us>)
List pgsql-general


On Wed, Jan 13, 2016 at 2:05 PM, Regina Obe <lr@pcorp.us> wrote:

> On 13 January 2016 at 03:10, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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?

> IME attacks (even if they are purely technical) on one's code can be as hurtful and equally as likely to result in alienation as personal attacks. I'm not sure how you would word it but just concentrating on personal attacks leaves open the sort of bullying that has been seen in other projects.

> Perhaps you could add something about valuing contributions from and making allowances for those with less expertise.

> I know that's sort-of implied by the "any person who is willing to contribute" phrase but I would say that being explicit about it is more likely to encourage non-contributors to contribute than what's been arrived at so far.

> Geoff

I agree it's hard to even talk about just technical without hurting someone's feelings, but I really don't think there is much we can do about that. Except linking to a separate document about how to get newbie help.
I think that kind of thing would be better handled by mentoring sessions (like a big developer taking you under their wings) than trying to deal with that sensitivity in a Coc.
In fact people would take advantage of the situation if you say things like  "less expertise",
because then they'd expect preferential treatment because they don't know C and be constantly badgering everybody for help.

One thing to think about here is the idea of framing the process.  One reason it might be a good idea to have a "respect the commons" clause is that it becomes a good way to think about the interaction of review and technical discussion.  I.e. both sides want to improve the software.  The focus is on the software, not on the other person.

People *can* take offense when you say their code is not good enough, particularly when it is true, because for better or worse we do often identify with what we produce.  But I would hope that if the focus is on improvement of the software the this becomes at least a bit less of a problem..

Thanks,
Regina




--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



--
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor lock-in.

pgsql-general by date:

Previous
From: Sylvain MARECHAL
Date:
Subject: [BDR] Best practice to automatically abort a DDL operation when one node is down
Next
From: Geoff Winkless
Date:
Subject: Re: WIP: CoC V5