Hi! > 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.
Thanks for improving the RFC. It is already much better than the initial variant, though I think more improvement is needed. As I wrote in previous emails, I'd like mode of what we want than what we hate. We already seen example from Drupal, here's one from Python: https://wiki.python.org/psf/CodeOfConduct I agree with having specific point of contact to turn to is beneficial and it should probably be featured on the same page as the text above. I am not sure I understand why list should be unarchived - while I see why *public* archive is not good, why not have private archive accessible to the members? After all, any member can archive all the emails anyway (and people with accounts like gmail probably routinely keep mails for years without deleting them). But having the established one avoids the situation where there's a problem with one member of the list and it turns to "she said, he said" situation with no proof of anything. > I included a vote requirement for course of actions of 4/5 of the CoC team. Good! Additionally, I would propose naming this team something like Mediation Team or Conflict Resolution Team, to emphasize that its primary role to find the best resolution of issues and not to bash people over the head with codes. Bikeshedding on the name along these lines is welcome :) > This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. I think this is way too broad. "individual is representing the project or its community" can be construed to mean basically anything - if a person is known in the community, any of their actions, even without relation to the community functions, can always be construed as "representing", especially by people with an ax to grind. We'd get people complaining "how could prominent member of this project vote for that vile politician X" and "how could prominent member of this community support that awful law Y" and we definitely not want to go there. > Process For Incidents I think the process should be amended to emphasize that the first course of action for the team should be to try and find amicable resolution of the issue (I imagine there are many established mediation techniques that can be applied and referenced, we're not exactly pioneers here :) and only when it proves futile (or misconduct is so egregious that it is obvious it is too late for mediation) the team would take further action. I.e. one does not need a vote to help diffuse the conflict. > 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 That is good. I think the principle of assuming good faith leads to better results. > 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". Excellent! > Either party may appeal an action by raising the concern to intern...@php.net. That would be impossible if one of the parties is banned from internals. > All incidents are to be kept in the strictest form of confidentiality I still think the secrecy bias is unhealthy. I remember how much controversy was produces by the supposedly private discussions of certain technical questions and RFCs. Imagine how much more heat would be generated if the discussion in question has a conflict as a starting point. The potential for toxic suspicions and distrust is enormous. > Additionally, I added a line specifying that bans (temporary or > permanent) should only be used in egregious cases. I'm not sure I still comfortable with notion of these bans, especially the one which bans somebody for the duration of RFC discussion in which their case is discussed. > 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 am a big fan of transparency, but here in particular I'm not sure that every mediation attempt should be indeed reported. Maybe if no further escalation was required, less publicity is better. We need to be careful here, as many things could be resolved in private more efficiently if public displays and egos are less involved :) This is another thing where over-legislation is bad, as there's a lot of common sense needed and you can't legislate that. > 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, I completely disagree that Contributor Covenant's text is any kind of "standard". I've seen a number of CoCs, and it's not the worst (though their homepage is... meh) but also not the best, and certainly not only. Yes, a bunch of projects adopted it, many out of convenience or to mimic bigger ones - I've seen a number of project references there that have single contributor and like 5-6 commits, so these numbers say nothing. But we're not some random 20-line tool which 5 people use. So we can't just take a cookie-cutter template and adopt it, disregarding our community specifics. It's much better for us to think on our own and to have something that suits us, then to run behind 10000 copy-pasted statements to which their authors probably gave no more than 10 seconds of thoughts. I don't blame them - if you have 20-line utility to which you alone ever commit, spending time developing code of conduct or even thinking about it too long is silly. But for us, it is not. > 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 I'm growing tired of this argument. We also do not know how many contributors we may have lost because we do not sacrifice a goat monthly to the Flying Spaghetti Monster, and we do not know how many contributors we may have lost because we do not publish a video of the committer dancing haka before each commit. The argument from ignorance, aka "you can't prove X is not magical, therefore we should do X" is one of the worst arguments in existence, and it would be really good if we stopped using it in rational discussion. > if that number is 0, does that mean it's not worth installing one to > prevent it in the future? Especially if the argument is then backed up with "regardless if this argument is true or false, we should do X anyway". If we should do it anyway, why bother with discussing imaginary scared contributors? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
