Re: Code of Conduct: Is it time? - Mailing list pgsql-general

From Chris Travers
Subject Re: Code of Conduct: Is it time?
Date
Msg-id CAKt_Zfs3AX5NmnQj9JgUjqfDxoV-pidS0NMsCZMKHvqYBMAQFw@mail.gmail.com
Whole thread Raw
In response to Re: Code of Conduct: Is it time?  ("Regina Obe" <lr@pcorp.us>)
Responses Re: Code of Conduct: Is it time?
Re: Code of Conduct: Is it time?
List pgsql-general


On Tue, Jan 12, 2016 at 9:16 AM, Regina Obe <lr@pcorp.us> wrote:

Chris,

 

The first part up to (I is fine), but part II and below reads more like a Core Contributor riot act you force all the main contributor's to read before you bless them with water and give them keys to commit stuff to your code base.


I am not sold on the specifics of what is covered.  But it is worth noting that responsibility can include a lot of other stuff too, not just keys for committing.  Thing about side projects and the like.  That's why I included it.   It could easily be replaced by something else (perhaps addressing what you are discussing below).

 

Like our committer guidelines -- https://trac.osgeo.org/postgis/wiki/DevWikiComitGuidelines

 

For a Coc – I think it should be light, but make it clear that we do not tolerate strangers coming into our group and demanding us to accept their code, cause we want to be welcoming and show we have at least 15% of code contributions from women.


One of the dangers of a CoC is that there are many potential issues which may or may not become real problems.  I think if we try to be clear on all of them, then we risk creating codes instead of a general expectation of what we do expect.

So my question would be how do you turn this around and frame it as a positive value and direction? 

I assume respecting the commons is insufficient.  Maybe a brief note about the fact that this is critical software and we have to maintain very high standards of code?

 

Thanks,

Regina

 

From: Chris Travers [mailto:chris.travers@gmail.com]
Sent: Tuesday, January 12, 2016 3:05 AM
To: Regina Obe <lr@pcorp.us>
Cc: Buford Tannen <buford@biffco.net>; Joshua D. Drake <jd@commandprompt.com>; Brian Dunavant <brian@omniti.com>; Scott Mead <scottm@openscg.com>; Adrian Klaver <adrian.klaver@aklaver.com>; Gavin Flower <GavinFlower@archidevsys.co.nz>; PostgreSQL General <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Code of Conduct: Is it time?

 

A couple thoughts rather late to the discussion from a more international perspective.

I remember a lecture I saw by a comparative law professor (the lecture was about why many Danes are unhappy with the EU pressures on their tradition of law and the general lack of subsidiarity in the EU) who described the difference between the Danish and the American system as "Make love not codes."  The pun here is that "love" is the plural form of the word for law in Danish.  Scandinavian laws tend to be short and rely on human judgment by judges rather than precedent and complexity like the American system or the equivalents in the civil law/Continental systems.  Without bringing up those political issues, I think the approach to decentralization is a good one for many projects.

I think this might give us a happy middle ground.  Something very basic, very brief which sets forth principles of the community but doesn't amount to real rule-making and respects the general decentralized nature of the project.

We have a highly decentralized community and an approach needs to reflect that.  I think therefore it is important  to keep things brief and vague on details but specific in shared principles.

I would also be concerned that someone who is overly worried about not having a code of conduct might be interested in lawyering about it.  Another concern may be "is there a place for me in the project?" and I think that can be answered differently.

So with these thoughts, how about something more like:

I:  Be Respectful and Collaborative

We are a global project and expect that people from a wide variety of backgrounds and viewpoints will work together.  Personal attacks are not appreciated, and the same goes for attacks on the basis of nationality, culture, or other factors of inter- and intra-cultural identity.

At the same time, understand that people often cannot see across different perspectives and may unintentionally say things that cause offense.  It is also a matter of respect and collaboration not to make these into issues.

 

II:  Be Responsible

If you have taken on responsibility in a community project and are unable to continue, please step down gracefully and help facilitate others taking your place.  This includes being around to facilitate knowledge transfer and much more.

 

III:  Respect the Commons

We are all here to build an outstanding open source project or set of such projects.    Act in a way which furthers the commons generally, as a custodian of what we have inherited from the efforts of others, and borrowed from the future.

 

In the event of serious problems, the core committee or those they designate, or the maintainers of other affiliated projects (in their domains) may be called upon to mediate or even address issues (particularly in the case of serious and repeated problems).  However, the community is expected to operate in a way which prevents this from becoming necessary by adhering to the principles above even in the process of addressing disputes..

 

On Mon, Jan 11, 2016 at 11:13 PM, Regina Obe <lr@pcorp.us> wrote:


Regina Obe wrote:
>
> If we do write a CoC, can we give it a different acronym.

> Notwithstanding the most regrettable childhood trauma, this request is exactly the kind of ridiculousness that the Political Correctness nonsense associated with CoCs that we should be worried about in the aftermath of proposed adoption.

> Complaining that the acronym "CoC" is anything remotely like the thing the work "cock" means is, well, cockamamie

> It's like someone becoming upset over the work "niggardly" as a racist epithet. In fact that word and the one you are thinking of are completely unrelated: entirely different etymology. Nothing in common except, on the one hand, as you imagine the acronym might be pronounced, and on the other because there are six similar letters.

Exactly.  That's why I added that section:

-------------------------------------------------------------------------------------------------------------------------------------------

USE OF TRIGGER TERMS

We have long standing terms like Master/Slave that may trigger some past trauma for some people.
While we do consider people's feelings, we weigh that against the effort of changing long understood terminology and the psychological trauma
such changes would cause for the large majority of people who are not as sensitive to the usage.
As such we entertain change requests for naming of new features more than we do of renaming old features.
-------------------------------------------------------------------------------------------------------------------------------------------------

First of all you have no proof whether I was raped or not, so you don't know if I'm just playing the "Poor woman was raped, give her a break" card or if my sad luck story is genuine.
In the end it's irrelevant, because as Josh apologetically explained to me  - Coc is standard in our vernacular so would cause more damage to others if we change it.

I have to learn to cope with my suffering when someone says Coc and it's not your problem that I was raped and I have traumatic memories everytime
I hear someone say  "We have a Coc. I think that should make you feel safer."

Josh did the right thing.  If we had this Coc -- Josh could just point at this section and say

"I feel your pain, but according to our Code of Conduct, we can't change it."

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.




--
Best Wishes,
Chris Travers

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

pgsql-general by date:

Previous
From: "Regina Obe"
Date:
Subject: Re: Code of Conduct: Is it time?
Next
From: Andy Chambers
Date:
Subject: Re: WIP: CoC V3