The bottom line is that the only requisite for contributors is professionalism. People should keep non-work related issues to themselves inside the workplace, as well as they should be respectful to each other no matter what.
However, if someone is professional and has never posted off-topic opinions or discriminated someone in the workplace (or within the boundaries of the project, github, mailing lists, forums, etc), the project mantainers have no business snooping through their personal social accounts to see if they are against gay marriage. Also, 'offensive' is always subjective. On a more moderate example, supporting Edward Snowden might be offensive to someone who lost a child in a terrorist attack and that thinks the government has the right to protect the people by using any means necessary. 2016-01-19 16:17 GMT-02:00 Arvids Godjuks <arvids.godj...@gmail.com>: > 2016-01-19 20:03 GMT+02:00 Arvids Godjuks <arvids.godj...@gmail.com>: > > > Hello to everyone. > > > > The Draft states: > > > > "This Code of Conduct applies both within project spaces and in public > > spaces when an individual is representing the project or its community." > > > > TL;DR: Just no. > > > > Long version: > > > > What is the definition of "representing project or it's community". If I > > make a single commit that get's accepted to the project, and then I say > > something 3 years down the line about the project (in this case PHP), do > I > > still represent the project or it's community? Or I have added to > > conversations on this mailing list for years now, does that mean i'm a > > contributor now and I'm responsible for anything I say about the project > or > > it's community going forward? > > And what is PHP community? It's not like PHP community is a tight group - > > it's huge, with tens of millions of people at least all over the world. > > > > This is especially a worry for me, because I run a PHP conference, and > > people come to speak to it. I do not want to deal with people dictating > me > > "I want you to pull this person because his views on blah are bla bla bla > > and that is unacceptable". I do not care about the persons views on any > > subject, unless: > > a). It breakes the laws of my country (hate speech, harassment, gender > > discrimination and all that stuff that is actually covered by laws). > > b). The person goes into issues, that are not the topic of the > conference. > > c). Behaves in a way, that is not acceptable in the society (personal > > insults, unacceptable language, and so on). > > And what if I actually agree with that person in my own views? And why > > someone thinks he has the right to dictate what views are acceptable and > > witch are not? (i'm not talking about issues, that are universally > > unacceptable to talk about). > > > > Regarding c) - you should remember, that in different parts of the world > > the social norms vary - from slightly to moderate between western > cultures, > > to quite a lot for asian/latin american/african/etc. . Every country is > > different, especially those, that are quite far apart. That means that > > people will be doing things, that are totally acceptable and are the norm > > in their country, when they are preforming at the local conference, but > > will probably trigger a storm somewhere else, and that may result in > things > > going horribly wrong. > > > > So, as far as my personal opinion goes, CoC has to apply only to project > > spaces in full, and for the public spaces it has to have a clear > > definition, when CoC applies. I really do not want to see situation like > > they happened in other projects, when a person can be booted off the > > project just because he does not support some trending new thing in > social > > areas (pick any social issue in recent 20 years), but is absolutely a > model > > member of the project. This is a tech project, not a social gathering to > > impose social trends and rallying support for social issues. > > > > * Any personal opinions on any subject not directly related to the > project > > itself should be out of the scope of CoC. This has to be written in from > > the start, otherwise people will find a way to exploit it to generate > > controversy and drama on the subjects that are not related to the PHP > > project. > > * CoC should clearly state that it is designed only to handle the conduct > > in project channels and official representation of the project. The > > representation part should be defined. > > * Any requests coming in on the issues, that are not directly related to > > the PHP project itself, should be outright rejected. In case of abuse > > (trying to re-open the issues) the access should be restricted if that's > > technically possible. > > > > Otherwise, as history shows, the rules are abused sooner or later. And > the > > amount of controversy we have around PHP every minor and major release, > > that's a given. > > > > Above written is a rough thought list on the subject. Proposed CoC is too > > generic and allows for a lot of loopholes. We should really take out > time, > > read up on the issues that did happen on other projects (and there are a > > lot of those), and not making a mistake of adopting a general CoC. > Personal > > life's have nothing to do with the PHP project. Personal thoughts > expressed > > outside of the project are just that - personal. And here in Europe, we > > have quite strict laws about personal stuff too, so even bringing up > issues > > like "that person thinks that ... that he said to me in a personal > > conversation" are subject to laws, that prohibit this explicitly. > > > > Thank your for your time, > > Arvids. > > > > One more thing: the CoC should really not allow for things to happen like > in this story: > > http://blog.randi.io/2015/12/31/the-developer-formerly-known-as-freebsdgirl/ > - is it true or not, and is there something else to it - isn't the point. > This is just an example of what CoC should not allow to happen. Ever. >
