On 5 January 2016 at 16:15, Anthony Ferrara <ircmax...@gmail.com> wrote:
> All, > > On Mon, Jan 4, 2016 at 4:06 PM, Anthony Ferrara <ircmax...@gmail.com> > wrote: > > Hey all, > > > > I have created a new RFC for the PHP Project to adopt the Contributor > > Covenant as the official Code of Conduct for the project > > > > https://wiki.php.net/rfc/adopt-code-of-conduct > > > > Let me know what you think or if there are any concerns > > > > Thanks > > > > Anthony > > In response to significant feedback here and elsewhere, I have > expanded the text of the RFC significantly. It now includes the text > of the Contributor Covenant 1.3.0 as well as including verbage about > updating it requiring an RFC. > > I included a vote requirement for course of actions of 4/5 of the CoC team. > > I also included content about the "Reasonable Person Test", explicitly > stating that it shall be assumed that both parties are acting as > reasonable people until proven otherwise by significant evidence. It > also stipulates that reporting an incident does not excuse someone > from the CoC (meaning victims are still bound to follow it, and are > not excused from proper behavior because of a violation). > > I also made it explicit that potential actions should be a last > resort, and that the CoC team should make every reasonable attempt to > defuse the situation without having to resort to "punishment". > > I also removed the ability to remove commit karma from the team, > instead including that in the "ban" category (meaning that the CoC > team is no longer allowed to remove commit karma long-term without the > action of internals@) > > Additionally, I added a line specifying that bans (temporary or > permanent) should only be used in egregious cases. > > I added a section on transparency, Conflict of Interest (though this > needs expanding) and accountability (giving internals@ the ability to > "overturn" any action by the CoC team with a vote of 50%+1). I also > made it explicit that accused people have a right to confidentiality > as long as no action is taken by the team. > > I also added a section on appeals. > > Those are the changes to the RFC as it stands. Please review them. > > > > As to the comments in this thread, I won't reply to every one, but > here are a few points I'd like to make. > > It's been mentioned that we may want to adopt a CoC, but it shouldn't > "have teeth". I disagree here, as without an enforcement mechanism it > basically is no different from where we are at today. Saying we should > act reasonable is fine, but we need a method for what we are to do > when one of us acts unreasonably. Additionally, as has been stated, > requiring people to report publicly creates a barrier to entry. Many > people will simply chose to leave quietly rather than report publicly. > Simply look at the way people who speak out about harassment are > treated in public to understand why. The point of the CoC is to create > a safe place for everyone to contribute, not just those with thick > skin. > > As to why the Contributor Covenant as opposed to another CoC or our > own custom one, there are two reasons for this. First, it's a standard > that's been adopted by a number of significant scale projects. Second, > it saves us from having to bikeshed over every single word of a CoC. > If there's another standard CoC that we should entertain, I'm happy to > look at it. But I do not believe that we should create our own. > > As far as the conflict resolution process, that I am open to expanding > or retracting as much as practical. I do think it's important to have, > but would be happy to take advice from groups like Drupal who have > done this before. > > To those that say this is a solution in search of a problem, it very > well may be. But that doesn't mean it isn't important to do. You could > say the same thing about smoke detectors. Even if you've never had a > fire, that doesn't mean it isn't good practice to install protection > from one. In this case, we simply do not know if or how many > contributors we may have lost due to incidents covered by a CoC. Even > if that number is 0, does that mean it's not worth installing one to > prevent it in the future? > > Thanks, > > Anthony > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > I'd suggest we consider using drupals CoC as a model; it has a more positive tone. Additionally, given that this CoC has far reaching consequences, I would suggest opening up voting on it's implementation to a wider segment of the community eg those currently subscribed to the PHP mailing lists or at least those who have recently participated on one. ~C
