On Tue, 9 Feb 2016, Zeev Suraski wrote: > 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.
I've changed it to: * Debate the technical issues, and ideas behind them, but never attack the person holding them. People will disagree, so be it. > 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..." I've added this bit. > 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. I've updated this to: * Try to avoid hyperbole to defend your arguments. > 4. s/Do not post when you are angry/Try avoiding posting when you are > angry - for similar reasons I'm leaving this one standing. > 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 :) Heh - it's always been in there ! :รพ I've changed it to: - Please configure your email client to use a real name. - Please keep message signature short. Don't add legal disclaimers. > 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. Yeah, this twtpoll thing was a mistake too. Mostly, because you can post multiple times, and everybody can. I have now created a wiki vote at: https://wiki.php.net/adopt-code-of-conduct/guidelines (Will reply to original message too) cheers, Derick
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
