On Tue, Jan 12, 2016 at 9:16 AM, Regina Obe <l...@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.trav...@gmail.com] > *Sent:* Tuesday, January 12, 2016 3:05 AM > *To:* Regina Obe <l...@pcorp.us> > *Cc:* Buford Tannen <buf...@biffco.net>; Joshua D. Drake < > j...@commandprompt.com>; Brian Dunavant <br...@omniti.com>; Scott Mead < > sco...@openscg.com>; Adrian Klaver <adrian.kla...@aklaver.com>; Gavin > Flower <gavinflo...@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 <l...@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. > > 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