hi Zeev, On Tue, Feb 9, 2016 at 8:08 PM, Zeev Suraski <z...@zend.com> wrote: >> 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.
I cannot agree more with you here. > 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. However this is very very disturbing. While you smooth it a little bit later, this sounds to me like something I would really prefer not to see. It is not necessary related to what can be covered by these documents but a recent past shows me that the "shot down" part is more than detestable. It is perfectly fine to consider a RFC as bad and state it openly (as in on the mailing list). But there is a clear line that should never be crossed when it comes to "shoot down" a RFC or an idea. This line has been crossed a few times (64bit patches or the STH RFC for example). And this is something I like to be covered to some extend. I am not against private discussions, by any mean, if they are fundamentally technical or goes in a friendly manner to try to get a 1-1 in-depth discussion. But some of these private discussions were more about putting unacceptable pressure to request the authors to cancel their proposals. This is in my opinion not acceptable, not even remotely acceptable and it has to stop. It is even more critical when these pressures are applied by well known leaders. We can disagree on ideas, even define them as very bad, but if we do it privately to avoid public backlogs of what is being said (for obvious or less obvious reasons) then it became a serious problem. > 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. Yes that's why the discussion period exists. Also one problem we have now with the RFCs is feedback not being taken into account because it does not match the author ideas. It forces competitive RFCs for the exact same subject instead of having different proposals grouped in one and accepted/rejected. It also prevents other ideas, maybe better ideas, to get in because many simply do not want to go through the pain of creating competitive RFCs. > 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..." With the hope that "propose them to the RFC author to try and evolve the idea into a better one", even as options to the given RFC, get accepted, but it is sadly very rarely the case. Thanks, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
