On Fri, Sep 20, 2019 at 2:24 PM Benjamin Eberlei <kont...@beberlei.de> wrote:
> > > On Fri, Sep 20, 2019 at 11:53 AM Zeev Suraski <z...@php.net> wrote: > This style of conversation has regularly lead to contributors that don't > want the intensity quit contributing silently. It is not healthy for this > community. > > Just because this style of communication was the DNA for 20 years doesn't > mean it has to be for the next 20 years. > > Some people can discuss a topic over and over again, maybe even get > strength out of it, others reach their limit of discussions at much earlier > points and turning inward and away. > This isn't so much a matter of a 'style of communication'. It's a matter of being able to address an evolving discussion and exhaust all the different aspects of the topic at hand. Yes, it can be, well, exhausting - but since we deal with decisions here that influence millions of people - this is absolutely the right thing to do. Let's take this very email for example. Your reply to me, and my reply to you. Am I supposed not to reply back, even though you brought up several new points? Even though you mentioned several things which I addressed in the past, but were perhaps not fully understood? Is someone with a minority opinion, who receives messages from multiple people at a given point, limited to answer just one or two of them, instead of addressing all of their points, because otherwise he'd be "sending many more emails than other contributors"? Placing arbitrary limits on conversations is not the answer. If we make internals more welcoming to contributors at the expense of shallower discussions - which result in catastrophic accidents for millions of end users - this is not a Good Thing. The right way is to build frameworks that allow us to roll out changes in such a way that everyone can live with them. Abuse - the kind of which we banned less than a handful of folks for so >> far, is something entirely different than what is being discussed here. >> Real abuse - abusive or foul language, off-topic rants, especially from >> people with no contribution track record - *might* constitute grounds for >> banning someone, although that is a very extreme case that should only be >> taken when a person clearly adds nothing to the discussion. >> > > There is no rule for absue yet though, and clearly specifiying these rules > as done in Dan's RFC would help soothe the discussions. > Not necessarily. Rules are up for interpretation. It's somewhat similar to laws in the context of countries - laws are laws, but ultimately, the only ones who can decide whether something is lawful or not are judges - and as we all know, their decisions can often be extremely controversial. Two judges could interpret the exact same law under the exact same circumstances in entirely different ways. And that's when we deal with judges for whom its their job - not untrained techies who may also have their own opinion on the discussion at hand. I imagine it would never be needed other than for simliar things than the > bans that happened before. But they provide a framework > that prevents these situations from draging on too long, escalating. > >> We both know that this isn't what's being discussed here. What's being >> discussed is placing arbitrary limits on and curbing on-topic discussions, >> > > This is exactly *not* what is discussed here. On-topic discussions are > totally fine. > > We have all read your, Stas and Chase's opinion and looking at the result > not a zero number has taken it into account for the engine warnings RFC. > > It is the ferocity, amount and wording of stating the opinion that I am > personally not OK with. > I'm not following. You're saying that [1] on-topic discussions are totally fine aren't being discussed here, go on to suggest that [2] the points from Stas, Chase and myself probably did result in some folks changing their opinion - and then go on to say that [3] in fact, they weren't OK in your view because they were too ferocious, wordy and opinionated. If [3] is simply your opinion, then that's fine. However, in a parallel universe where these proposed rules were binding - it may mean that some of us or all of us would get suspended for them. In turn, it may mean that the results of the corresponding polls would have changed. In other words, they absolutely would affect on-topic discussions, placing arbitrary limits on them and creating a mechanism for a majority to silence the minority. This email of yours https://news-web.php.net/php.internals/106963 really > overstepped many lines in terms of aggresiveness. > > To me this feels like your attempt of shutting down dissent and silencing > different opinions with ominous threats by abusing your position of power > in the project. > I hope you see this and why contributors feel the need to clarify rules. > While I agree it was a far-reaching message that I did not want to write - I still stand behind it. Nothing in this message threatens to ban or suspend folks who would continue campaigning for their opinions. It does make it clear, though, that if your opinion is that OTHERS *must* change the way they use PHP to fit the way and/or style that you prefer - this is fundamentally incompatible with key tenets of the project that far predate the RFC process - and that this process (and in particular the voting bar) was not designed to address. It's somewhat similar to the freedom principle in free societies - you're generally free to do as you please - however, that only holds true as long as you don't violate the rights of others . Preventing someone from being allowed to hit someone else does not constitute as limiting their rights. Back to our world - one would have to find an approach to promote their idea that does not force their way of thinking and coding style on everyone else. More than one such way is available. Until the RFC was put to a vote, me as well as others were cautiously optimistic that at least this part of the proposal would be retracted. About a week earlier - there were indications that this whole thing may be resolved by changing default INI settings instead of triggering a giganetic behavior change and a BC break. But despite the positive reception to this idea - that positive reception went ignored for reasons unknown, and the RFC simply charged ahead. > Nobody is against discussing a strict mode. But at the moment this > discussion is constantly derailed, because there are no actual technical > proposals how this looks like and if nobody is workong on it, then it will > not be happening. > > With speculation on the issue then comes the contentiousness in > discussions. We can only speculate how the castle in the air looks like. > First off, I'm absolutely sure that folks who proposed the recent gigantic BC breaks know precisely what 'strict mode' would be, how easy it is to implement, and if they wanted to go in this direction - they wouldn't need my help. It's directly related to the strictness proposals that are being brought up here (short_tags deprecation, undeclared variables behavior, etc.) - and bringing it up in that context isn't at all derailing the discussion. Strict mode, somewhat like in Perl (https://perldoc.perl.org/strict.html) and JavaScript ( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode) - would be a PHP level switch that would trigger several compatibility-breaking changes that would make PHP stricter and 'cleaner'. In terms of what it would look like and how it would behave - the simplest way would be reusing declare(), and have the exact same semantics we have for strict_types. We could decide whether we want to roll out these changes as a single switch (e.g., declare(strict=1)), or whether we'd want something more granular (e.g. declare(strict=SHORT_TAGS|UNDECLARED_VARS). And that's kind of it. There isn't that much to it. If & when Nikita or someone else comes up with a mechanism to apply such declare()s at the namespace or package level - this mechanism would benefit from it as well. This isn't a castle in the air. This is buying the Versailles palace for $9.95. It's ridiculously easy to implement. It's easy to explain. It's easy to use. The concept has been tested for several years through strict_types. The only downsides it has are that it doesn't force this new behavior on everyone and doesn't break astronomical numbers of lines of code. But really, these aren't downsides - they are prerequisites to making it an idea worthy of discussion. Zeev P.S.: Thanks for a well thought-out email.
