hi Zeev,
On Tue, Feb 9, 2016 at 8:08 PM, Zeev Suraski 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
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.


@pierrejoye | http://www.libgd.org

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 22 of 32 | next ›
Discussion Overview
groupphp-internals @
postedFeb 9, '16 at 12:33p
activeFeb 11, '16 at 6:39p



site design / logo © 2018 Grokbase