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. 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. Thanks, Regina From: Chris Travers [mailto:chris.travers@xxxxxxxxx] 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@xxxxxxxx> wrote:
Best Wishes, Chris Travers Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in. |
