Similarly to how I answered Bob, I want to prefix my message with an
off-topic statement that I think is important, albeit obvious.
I think you're a remarkably talented developer that is an invaluable asset
to the PHP project. Your work on many fronts to improve the language has
been tremendous, and much like pretty much everyone else - I recognize it.
Again, even though I'm not telling you anything you don't already know, I
want to remove any shred of doubt about whether or not I'm sharing this way
of thinking. I do.
And now, on-topic:
I am putting myself at a disadvantage here. I am not suppressing Stas'
voice, only removing my own ability to argue against it, and effectively
strengthening its position.
Let's be fair and realistic here. You have a very strong following on
[email protected] - a position which is well-earned. In most situations when
these folks don't have a strong opinion about a given matter, they would
count on you to show the way and follow.
When you make a statement that you're going to ignore someone - you are
very much suppressing their voice; Beyond taking their ability to reason
with the most relevant person, and get their opinion on the various issues
raised - you're also signaling to your followers to do the same, whether
you intend to or not.
That said, I want to be clear - any RFC author is expected to explain and
defend their RFC, responding to both feedback and criticism - even if they
don't have the strong following you have. That following only makes it all
the more clear and necessary.
Everyone else can still see his arguments and
be swayed by them. If they're good arguments and well delivered, they will
be. If they aren't -- well, that's hardly my own fault.
There's a reason we call these things we do on internals "Discussion
Periods". They're not meant to be similar to Closing Statements from the
Prosecution and the Defense, trying to convince the jury without
interacting with each other.
In reality, much of the value of the RFC process comes from the discussion
period - and discussion means back and forth. It helps both refine the
RFC, weed out bad proposals, and perhaps most importantly - give people
more of a 3D view of the RFC - become acquainted with the practical pros
and cons of the RFC, some of its corner cases or unforseen impacts - which
are often not as easy to understand from reading the formal RFC text itself.
Refusing to take part in the discussion when provided with valid feedback
hampers the RFC process.
I read RFC feedback and engage in discussions, because I want to deliver
the best proposal I can, which incidentally is also the most likely to be
That makes perfect sense, but it also does not change the fact that you are
absolutely expected to engage in the discussion regardless. It's comes
with the territory.
I'm sorry that everything has to be formalized today - had we seen that
coming - we'd spell out that the discussion periods aren't meaningless
countdown timers that the RFC author(s) can simply wait out, but rather,
that they need to engage and respond to any meaningful feedback, and
certainly not signal out certain folks by nature of who they are instead of
the merit of their specific feedback. We thought that (as well as many
other things) was obvious.
I am not saying that one needs to respond to every last email message on
the subject. There are situations where the discussion reaches a point
where there's nothing new to say - on both sides of a certain divide (which
is, incidentally, a pretty bad situation to be in to begin with, but that's
another topic). But that's not what you're saying - you're saying you're
going to stop responding to a person (perhaps more than one) - regardless
of the content of feedback they provide.
However, not all forms of feedback are created equal. It is a
staple of polite debate that criticism be actionable -- it is not
sufficient to register your disapproval, you also need to suggest possible
avenues for improvement or alternative approaches that may be pursued.
While registering one's disapproval without explanation is definitely
insufficient, I think we can agree that this wasn't the case here. Even
without reading Stas's messages in detail - their length alone suggests
that they provide reasoning for why he's disappoving of the idea, and not
just crypitically saying that he disapproves. It becomes even clearer when
you do read them in detail.
But the other part if your sentence - that one must "suggest possible
avenues for improvement or alternative approaches" is really not quite
true. That wrongly assumes that an idea that's proposed in an RFC, any RFC
- is a good one and should pass - and the goal of the discussion period is
to simply hash out issues and make it better. That is clearly not the case.
Everything about the RFC process as it was created - both in terms of the
discussions before it, and the text itself - makes it clear that there's
bias for status quo, and that the burden of proof is on the person that's
proposing to change it. That's why we have 2/3 majority requirement (as
insufficient as I think it may be). That's why we have a 6 month cool-off
period after a proposal fails to pass. That's why the RFC template
instructs people to think very carefully whether it's really sensible and
necessary to have their feature/change introduced to a language used by so
many millions of people.
Nothing in the RFC process implies that everyone should help refine the RFC
and make it better, if they think that the premise itself is a bad one.
It's absolutely valid for someone to think a certain idea proposed is bad,
and can't be improved.
It's absolutely valid for someone to find holes in a proposal, and not have
any ideas on how to fix them - these ideas may sometimes come from someone
It's absolutely not a requirement for someone to come up with solutions for
the problems they find in a proposal. Of course - if they do, that's great
- but finding the edge cases, potential problems and possible negative
effects - is extremely valuable on its own. Sometimes, the dynamics of the
discussion between the feedback provider, RFC author and other participants
will help find better solutions. In others, it may simply make people
better understand the shortcomings (and advantages) of the RFC, and help
them make up their mind about it.
If I have found that a particular source of feedback has, over many years,
been consistently and persistently negative and only on rare occasions
yielded an actionable insight, I believe it is my prerogative to remove
this source from my personal consideration, especially if it has a negative
influence on my mental well-being.
It's hard for me to argue when someone is saying that if they do what's
needed, it will have a negative influence on their mental well-being, as
I'm so much familiar with it first hand. But the choice is yours, exactly
like it's anyone's (including Stas's, who I'm sure would do much better
from a mental well-being point of view if he didn't feel obligated to
respond to ideas he believes are negative to the language he's so vested
in, regardless of whether he's right or wrong; or me, for that matter,
when I definitely took a negative hit on my mental well being a few weeks
ago having to work hard to prevent a certain useful feature from being
removed for no reason - a discussion I had no part in starting and was in a
way forced on me). If you propose an RFC - you need to have the mental
strength to follow through with it, and that includes responding to
criticism, including criticism which from your point of view isn't
constructive or insightful. If you can't, you have other choices - to not
propose it, to have someone else author and lead that RFC, to propose fewer
RFCs so that the level of mental strain are reduced, to focus on other less
contentious areas, etc.
For me, the negative influcence on my mental well-being was a key (if not
exclusive) factor in the fact I never ended proposing the revamp of the
Voting/RFC rules - and quite a lot of other proposals/RFCs over the years.
I knew that if I did - I'd have to engage in unpleasant and often likely
uncivilized discussions, including with some very uncivilized people who
still believe they have the civilized higher ground (to clear any doubts,
that's absolutely not you). It a part of the rules of the game. You can
choose to play it, have someone else play it, or stay out. But one cannot
play it while creating a sandboxed environment that shields them from
feedback they don't like or people whose opinions they typically disagree
with. It doesn't work that way.
With all that said, it appears we would all do better if we came up with a
way that the two 'camps' on internals, which hold opposing views on many
topics regarding the direction of the language, could find a way where most
or at least some (and hopefully many) of these discussions are avoided in
the first place - but without blocking progress. None of us likes the
mental toll associated with the current situation, and I think the results
are often not very pleasing to either side. I'll be trying to work
something out, who knows, it might just work.