On Tue, Jul 30, 2019 at 10:37 PM Nikita Popov <nikita....@gmail.com> wrote:
> Zeev, > > Nikita, 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 internals@ - 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 > accepted. 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 else. 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. Zeev
