> Feel free to reply here with suggestions, comments, etc. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
