[VOTE] Contributor Guidelines, and Updates to Code of Conduct progress

Morning Derick, I know you're asking about another document right now, but I still find the language of the CoC jarring. This: "Coercing other members to vote for a particular option on an RFC, or to change or withdraw an RFC". That's too vague: https://twitter.com/krakjoe/status/685368852268593152 There is surely nothing wrong with that tweet, but it seems to violate the CoC in current form. Others have done the same kind of thing for past RFC's. Once again, I want to bring attention to this paragraph: "Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviours that they deem threatening, offensive, or harmful." That would also seem obviously too vague. It doesn't make sense to try to limit offence, elsewhere in these documents you try to espouse the attitude that people will disagree, and "so what". I think it better to stick with that line of reasoning, rather than giving people the idea that simply being offended is a thing anyone else should care about. In addition the word harmful is missing context, and should either be clarified or removed, with offence. All the rest of it is good, I think ... Cheers Joe On Tue, Feb 9, 2016 at 12:33 PM, Derick Rethans <derick@php.net> wrote:

I think this is a pretty good start and I can stand behind most of this text. I do have a number of issues/suggestions with it though (apologies for not doing this sooner - I was swamped in the last 3 weeks with travel & out of town visits): 1. "Debate the technical issues, and never attack a person's opinion. People will disagree, so be it." I think this sentence is problematic. Not that I'm pro-attacks, but opinions - as ideas - should absolutely be up for scrutiny and debate. What I think we should say instead is this: "Debate the ideas, never attack the person holding them." Criticizing ideas is absolutely fine, and it's healthy. Ideas can be bad even if they don't have any 'technical issues' in them. It's the personal attacks we should avoid. And of course, the criticism should be to-the-point - but the proposed text already covers that. We can consider adding another important part of the equation - "Don't consider critique of an idea you proposed as critique of you personally." As humans, we tend to do that, and we shouldn't. 2. "Suggest improvements to the RFC, don't just shoot it down." I disagree that this is a Good Thing. There are most certainly bad RFCs, that cannot be made better (typically ones that stem from bad ideas, which absolutely do exist as per the previous point). These RFCs need to be shot down. Moreover, there are cases when the person who is talented at finding holes in things isn't necessarily talented at coming up with solutions. Finding holes (negative aspects) of RFCs is an exceptionally important task, and we don't want to silence people who find issues - only because they can't think of solutions for them. What I think we should say instead: "When you disagree with a certain proposal, try to think whether there are changes that can be made to the RFC that will enable you to support it. If you come up with such improvements, respectfully propose them to the RFC author to try and evolve the idea into a better one. Only resort towards arguing against the RFC if you think it's a bad idea and you can think of no ways to improve it. When disagreeing..." 3. s/Don't use hyperbole/Try avoiding hyperbole - both because hyperbole is difficult to define, and because people respond better to asking vs. demanding. 4. s/Do not post when you are angry/Try avoiding posting when you are angry - for similar reasons 5. I think the 'max 2 lines email signature' requirement is a bit archaic. Who cares? Do we expect people to change their signature especially for internals? Not important, but if we're nitpicking :) Note that we have a serious issue with voting process on these topics, which is probably not much of an issue for this document (for which we should be able to garner a very strong majority, I believe, and you already said you consider the vote to be non-binding) - but will definitely be an issue for any CoC. But that's something we should discuss separately. Thanks for working on this! Zeev

Hi, On 09/02/16 12:33, Derick Rethans wrote:

I couldn't agree more. Ambiguity has a chilling effect on speech, and will damage the quality of discourse on internals. Having said that, I think that the CoC being proposed is too wordy, and still quite ambiguous, some examples of statements I think are problematic: 1. "Make sure you know what you are talking about." - ambiguous and hostile wording, which really isn't going to change anything. 2. "It is better to be descriptive than to be concise" is in clear conflict with "Write ... as little as you can get away with" and both address the same point. 3. "never attack a person's opinion" - challenging opinions is very important in technical discussion. I will submit a pull request later with some suggested amendments to improve clarity and remove duplicates.

These statements appear to be in direct conflict with each other. If the Drupal CWG have not needed to impose punishments as a result of their CoC, and in the history of Internals you could count the bans on one hand, then I really don't see why we need to go to the lengths of establishing committees and punishment procedures. I feel that the CoC has a much greater chance of achieving consensus if we don't try to impose a 'court of law' alongside it, especially considering that most proposals for a 'court' have been secretive and focused on privacy rather than on transparency (the opposite of all well-functioning legal systems).

This is an ambiguous statement, do you mean scope of enforcement (i.e. spaces outside of PHP technical spaces) or something else? Would you mind clarifying and also providing a brief summary of what lead to this conclusion? Again, I think that the CoC has a much greater chance of achieving consensus if we aren't trying to use it to police behavior outside of our spaces.

I've submitted a vote, not sure if I should as I don't have karma to vote on RFCs. I think this is a lot better (and more technically-focused) than the Contributer Covenant, so it's a step in the right direction, but I still think it needs some refining to be 'production-ready'. - Matt Prelude.

What does this mean in this context? We're voting but nothing will actually change?

Hi,

<snip> note - the voting thing is now on the WIKI at: https://wiki.php.net/adopt-code-of-conduct/guidelines cheers, Derick

Thanks for the work, Derick. Looks good! (aaand I just top-replied :p)

Hi Derick,

For my part, at least, things are in "hibernation" until the wiki is updated with the new draft. Meanwhile:

Is there a transcript or recording of the call? I'm very interested to know what transpired.

What is the reasoning behind this?

Why was that?

I think that presumes the people making up the Team will be present for all time thereafter, and never replaced. Indeed, it reinforces the idea that the political persuasions of the Team members will be the determiner of how the Code is enforced, if one is ever adopted. Since we cannot know in advance who will be in place *after* the first Team, I opine the rules should not be Team-member-dependent.

I'm reliable, considerate, and empathic toward accused persons. Does that count?

(The poll was later moved to the wiki at <https://wiki.php.net/adopt-code-of-conduct/guidelines>.) While the narrative itself is rather generic, there are several problems with the Guidelines. Others have mentioned some of them in various replies to this thread. For me, the biggest problem is that the Guidelines presume that every RFC can be made into something useful and/or desirable. There is no allowance made for declining an RFC as unworkable or unacceptable from the beginning, politely or otherwise; for example, something that is against the "vision" (however interpreted) of PHP in the first place. Some things are best rejected out-of-hand at their beginning. Some may not see that as "constructive"; but then, what is "constructive" depends on what you construct. Derick, can you imagine there might ever be a time when an RFC should be turned down on its face? If so, in which cases do you think that would apply? If not, why not? Second, the Guidelines lack definitions. They say, "Debate the technical issues, and ideas behind them, but never attack the person holding them." Derick, what does "attack" mean in this context? In lieu of a definition, do we have an actual example from PHP-Internals that shows an "attack" in that sense? If there is, it should be linked. If there is not, then why do we think "attacks" of this kind are a problem to be addressed? Finally, these are Guidelines, but for whom? Is their violation actionable? If so, by whom, and in what circumstances? If not, then the Guidelines should say so. I have other issues, but those will do for now.