Stas, On Tue, Jan 5, 2016 at 11:57 PM, Stanislav Malyshev <smalys...@gmail.com> wrote: > 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 :)
Yeah, that sounds completely fair. Plus it puts the focus on resolution rather than punishment. I like that. I'll update the RFC shortly. >> 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. It is broad for a reason. If harassment that's obviously connected with the project (it would need to be obviously connected) happens off-list, that's still problematic. I think limiting the scope to just the project territories is dangerous as it provides too easy of a way for members to cause problems with no resolution possible. >> 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. Yeah, that's completely fair and worth while. I'll look at rewording that after talking with the Drupal CoC people. >> 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. Unless we lift that ban just for the appeal. Meaning that the banned individual requests an appeal, so they are unbanned for that single thread until it is resolved... >> 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. The other side is far more serious though. Many MANY people avoid coming forward about incidents because they are afraid they will be labeled. Simply look at *EVERY* woman who has come forward to talk about a harassment incident on the internet so far. Every single one has been met with at least a handful (usually an army) of people who claim they are just trying to slander the other side, and how the other side is innocent. No matter the strength of the evidence. Simply because no matter how strong and clear the evidence is, some people simply won't believe it. That's why confidentiality is critical. >> 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. Well, what's the alternative? To let them continue to cause trouble? I would never vote for a ban (temporary or permanent) unless there was a strong pattern of significant abuse, and I think many here would agree to that. So by the time it gets to that point to vote on, it should be exceptionally clear that the behavior is egregious. In that I don't foresee many (any?) RFCs for permanent bans in the first place, but even if there were I doubt any of them would be turned down. Simply because the level of evidence that would satisfy the "Reasonable" test for a permanent ban is so significant. As in the appeals process, perhaps we can figure out wording to lift the ban on the mailing list during the RFC process, under the explicit understanding that the accused offender not post to other threads until the RFC process is done. Would that at least partially resolve that concern? >> 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. Yeah, perhaps just require transparency when action is required (reverting commits, edits, etc or temp bans) >> 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. Sure, there are a bunch of projects with 1 contributor. But you have massive projects there as well including Rails, AngularJS, Babel, Cake, Composer, Eclipse, GitLab, Mono, .NET, Swift, etc. Some of those projects dwarf us in scale (in terms of numbers of contributors at least). So I think the argument that "we're too big for that" is a bit of a stretch... >> 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. I wanted to avoid citing personal examples for personal reasons. But since you refuse to read between the lines, here it goes: I have received no less than 4 direct threats of violence that were directly due to my involvement with the Scalar Type Declarations RFC. I believe that both Zeev and myself crossed significant lines during that discussion as well, to which there should have been some level of recourse or moderator that could have stepped in to cool us down and help. Since posting this RFC, there have been people openly speculating about my gender, sexual orientation and other personal matters. In contexts that are purely obvious that it is connected to this RFC, and hence the project. And that's just me. I know for a fact that several other people have had incidents. I know that several people avoid internals and the project because of fear of incidents. I won't speak for them, that's their prerogative. But please stop pretending nothing's ever happened. My experience alone should be enough to justify. >> 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? Because the argument stands on its own. We shouldn't have to talk specifics. In fact, we didn't until you insisted that nothing has ever happened, and hence this isn't necessary. You didn't buy the argument by itself, so we had to talk about those who are afraid. But both arguments stand on their own. And the vast majority of people agree that even if nobody was hurt, it's worth having (the smoke detector argument). Thanks for the feedback, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
