Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:90759 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 58421 invoked from network); 21 Jan 2016 00:07:52 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Jan 2016 00:07:52 -0000 X-Host-Fingerprint: 90.212.141.145 unknown Received: from [90.212.141.145] ([90.212.141.145:6696] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 43/8B-22511-75120A65 for ; Wed, 20 Jan 2016 19:07:52 -0500 Message-ID: <43.8B.22511.75120A65@pb1.pair.com> To: internals@lists.php.net References: Date: Thu, 21 Jan 2016 00:07:47 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 90.212.141.145 Subject: Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct From: ajf@ajf.me (Andrea Faulds) Hi Zeev, Zeev Suraski wrote: > I want to point three key concerns that are unrelated to the contents of the updated RFC before addressing the RFC itself (in short). Note that I'm not blaming or otherwise holding you in any negative light in any way, but rather, stating my opinion on the context of the RFC. > > First, on process. > I continue to hold that this proposal does not belong under the umbrella of the RFC process, given that the RFC process was never meant to deal with such cases. It was meant to deal with technical and administrative items. I have no idea whether or not this can win 2/3 of the votes, but regardless, it should pass a much higher bar for acceptance as an essential from-scratch 'constitution' for the PHP project. Having a controversial constitution from the get go is unacceptable IMHO. I wouldn't say the idea of a code of conduct is really a constitution per se (it's not setting down the foundation and goals of the PHP project, merely rules for misconduct), it's more like an administrative document. That being said, you may have a point with it not being what RFCs were really intended for. But we don't really have an alternative process for this currently established, so an RFC is the best we can do. > Second, on drama. > I think that the situation where someone withdraws an RFC and another person all-too-expectedly takes over needs to stop. It's one thing to turn to someone else and have them lead from now. It's an entirely different thing to withdraw and have someone else take over. I think that if someone withdraws an RFC (as opposed to amending it or adding additional co-authors) - it should have the same ramifications as a failed vote. Withdrawing an RFC should not be a dramatic instrument. Yes, I realize the Voting RFC doesn't state that. I'm stating my opinion. We work in the open and follow the spirit of open-source. Anyone can copy and modify any other RFC if they so please. If we don't allow people to resurrect other RFCs, then it gives the original author more control than perhaps they should have. Consider that during the Scalar Type Declarations dicussions, you revived an earlier version of my RFC, because you wanted to keep that approach alive. Likewise, when I left due to personal issues, Anthony revived my RFC in a new form. Sara was also going to revive my RFC if I remember rightly. Were we all wrong? RFC revival is essentially like forking, and that's always allowed in open-source. > Third, on undue pressure. > Certain people have either implied or outright said that not having a CoC will make them reconsider actively contributing to PHP. This is undue pressure IMHO, avoiding the use of bigger words. It might leave others feeling pressured, but it's not their fault if those contributors feel unsafe without a code of conduct. Nor is the flip-side true: a certain person said they fear getting in trouble for their political views if the CoC passes, and if they wanted to leave as a result, so be it. Nobody is under any obligation to contribute to PHP, they can freely choose not to contribute if they wish, and that is their right. I think it would be worse if you were not allowed to make such statements. It's better that people be aware of consequences than be surprised later. > I also want to quickly address the essence of the updated RFC in short, and in particular, it's stated goal: > >> I strongly believe that a Code of Conduct is required. The amount of toxic >> behaviour on this list is in my opinion unacceptable. It drives people away, it >> certainly did. It is also one of the reasons I am not nearly as active as I used to >> be. > > Much of what I wrote in my message to Anthony, that can be titled "What could possibly go wrong?", still holds with the updated draft (the message is available here: www.mail-archive.com/internals@lists.php.net/msg82913.html). > > There's one very notable exception - there is no ambiguity in any way about what you're trying to address - which is fix 'toxic internals'. Notably, this is a substantial shift (and arguably a 180 degrees turn) from what Anthony said this RFC is supposed to address: > >>> "There are two prime reasons people may avoid internals (at least related to this discussion). >>> 1. Don't want to deal with the aggressive tone of the list 2. Don't want to expose themselves to targeted aggression/negativity >>> The first is not in scope of this RFC. We may or we may not want to take steps in the future to "fix" that, but that's not in scope here." > > For me, it validates that my worries about the widespread confusion were indeed completely justified. But much worse, it means that with the author's stated goal of this RFC addressing the 'Toxic Internals' issue, the risks associated with this RFC are no longer theoretical. They're real, and we'd be slipping down that slippery slope sooner rather than later. Personally, I don't see how expanding from covering serious misbehaviour (harassment etc.) to covering more generally non-conducive-to-civil-discussion actions would make things more or less open to potential abuse. Generally, opinions are not the problem, but rather the way people go about expressing them. > I'm not going to repeat arguments I've made half a dozen times as to why having a judicial system must be avoided, and why we must deal exclusively with desired behaviors and not the 'exception handling' of bad behaviors. I made my case in the best possible way I can and people who are interested in it can read it in my previous replies on the topic. Equally important - many others expressed similar views. Thus far, the only response is a laconic 'without penalties it's useless', even though we've brought numerous supporting arguments as why this is simply not true. Even if you believe that it's not a problem, that doesn't change the opinion of people who do think that an unenforced code of conduct is problematic. > I will repeat that I'm very much in favor of a CoC that includes our positive core values, and that includes a mediation team in case people are feeling offended and that can intervene also w/o complaint - but that does not have any sort of special powers - but is instead exclusively based on good will of all parties. Even if certain people don't think that's good enough, I don't believe that anybody would argue that it's BAD - the way many think the current CoC proposal is. This is precisely why this is the right place to start. A set of positive values is all well and good, but that won't fix anything when people nonetheless act outside the rules, which is what a code of conduct sets out to deal with. Or, basically, I think it's sort of derailing, though I realise that is not what you intend. A set of positive values doesn't constitute a "code". That said, laying down what our values are might be a worthwhile project, it should just be in a separate discussion. Having a slightly more definitive idea of what PHP and its community is and it stands for would be nice. Thanks. -- Andrea Faulds https://ajf.me/