Re: Code of Conduct: Is it time?

On Tue, Jan 12, 2016 at 9:16 AM, Regina Obe <lr(at)pcorp(dot)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(dot)travers(at)gmail(dot)com]
> *Sent:* Tuesday, January 12, 2016 3:05 AM
> *To:* Regina Obe <lr(at)pcorp(dot)us>
> *Cc:* Buford Tannen <buford(at)biffco(dot)net>; Joshua D. Drake <
> jd(at)commandprompt(dot)com>; Brian Dunavant <brian(at)omniti(dot)com>; Scott Mead <
> scottm(at)openscg(dot)com>; Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>; Gavin
> Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>; PostgreSQL General <
> pgsql-general(at)postgresql(dot)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(at)pcorp(dot)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(at)postgresql(dot)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.
>
> http://www.efficito.com/learn_more
>

--
Best Wishes,
Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more