Andreas, all, Speaking of 'disruptive behavior' that the antithesis of promoting 'good will' - this pseudo RFC is a textbook example. But some of the responses on the thread are actually more interesting and nicely written and do warrant a response.
On Fri, Sep 20, 2019 at 10:14 AM Andreas Heigl <andr...@heigl.org> wrote: > Hey Stas, Hey All. > > "without too much problem"... I start to ask myself whether I read the > same mailinglist as you... > > "rare disruptive individuals"... Again I ask myself whether I read the > same mailinglist... > Different people have different expectations from what discussions should look like. Their personality, culture and other elements may feed into that. For some here, the most important thing about internals should be individuals not writing too many emails on the same topic. For others - it's for people not to use foul, disrespectful or condescending language. Thankfully (or not, depending on your point of view) - internals@ wasn't born in 2019. It's with us for over twenty years - since the project was born. Making decisions through discussions and debate is the DNA of the list, the DNA of the project. Discussions about contentious topics can get intense. They can end up with certain folks being over-represented in certain threads. This never has been and will not be considered abuse, it comes with the territory. No RFC is going to change that - the list and our most fundamental way of working predates the RFC process by almost 15 years and cannot be altered by it. 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. 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, because the way they are conducted isn't pleasant for some (or perhaps even many) of the readers and participants. We're talking about codifying a new DNA - that nothing is off limits for the Voting RFC, even turning PHP into a strictly typed language breaking every last piece of PHP code out there - if there's 2/3 support for it - a bar that was set for new features. That won't happen. More specifically, as Brent pointed out, we all know who this is aimed at. It's aimed at me, Stas and Chase - who fiercely opposed the recent new break-fest trend, and happen to remember the key tenets of the PHP project - even if they're not fully encapsulated in the hastily written Voting RFC. And all of this just happens to be promoted by folks who supported that very same break-fest, and are repurpusing the RFC process to have unlimited power about both conduct and radical, super controversial breaking changes. Despite claims to the contrary, this is no coincidence. The unpleasantness of these discussions - which I'll be the first to admit (I have, *literally*, lost sleep over some of them) - is no indication of their validity. As an example, as unpleasant as the discussion surrounding the 2nd fixed short_tags RFC was - and it was, for *everyone* involved - the difference between the results of the 1st and 2nd round of this RFC demonstrate the value of an open discussion - even if it's unpleasant. Yes, the discussion around round #1 was nice and pleasant, in fact it was virtually non-existent - and it was a textbook example of a *horrible* discussion process. Our first goal on internals@ isn't to have fun (although that's of course not a bad thing, and every once in a while that may happen too) - it's to come up with the best decisions for PHP. While discussions have to be respectful - it does not mean they'll necessarily be pleasant. Whether one gets involved in a discussion is their choice - and that's more true for RFC authors than virtually everyone else. As I recently wrote - if someone is going to bring up a controversial proposal (especially ones breaking new grounds in terms of impact) - they should be absolutely ready to deal with potentially fierce opposition. If they do it inadvertantly - they have the option of reevaluating whether it's worth their trouble. They do not have the option to silence others' on-topic feedback, period. "without dramatic speech code"... Yes. That was exactly the problem. No > process that was agreed on *before* shit hits the fan. > Had we wrote a speech code back in the 90's, placing message count limits would definitely not have been a part of it. Even the mailing list rules that Lukas wrote 12 years ago don't place arbitrary limits on messages, but ask the participant to think about whether he truly needs to frequently respond. In some of these recent threads, given the gravity of the situation and the scarcity of folks that were willing to actually campaign against the proposals (despite there being many who agreed with them) - it was absolutely warranted. > To me it looks like you are trying to make this RFC look like it tries > to force a ban on people that want to contribute. While this is not the > idea of the RFC I ask myself why you are so strongly against trying to > find a way to get a less disruptive email-list. > Simple - in a parallel universe where this was binding - we would have likely deprecated short tags and undefined variable access. We would, have, perhaps, decided to turn PHP into a strictly typed language by 2028 - because it's supposedly a long enough timescale for everyone to adjust to a radically different language, or be forced to stick with LTS. Because it is politically motivated and would have been used to oppress an internals@ minority - a minority that already has very few speakers willing to take the heat of the discussions repeatedly imposed on us (but at the same time represents a sizable minority). A toxic and disruptive email-list that drives the creation of PHP not > only drives people away that would like to contribute to the language > itself but also drives people away that might want to use PHP for their > projects but are not sure about whether the language is such a good > choice if that is the tone of development. People will leave PHP because > they are not sure whether PHP has a future when the people creating the > language can't even decide on how to talk to one another... The way to avoid contentious discussions, especially repeats of the ones we've had recently, is to come up with a solution that will prevent these contentious topics from being an issue to begin with. Not coming up with ways to silence dissent so that we can have a nice kumbaya discussion while the majority[*] overruns the minority[*] (* - on internals@, at least). Strict mode/Editions/similar options would have provided proponents of a stricter/'cleaner' PHP a good way forward - not just for these issues but for a whole class of others, while not imposing a gigantic headache and depressing changes on lenient/BC-oriented folks. It would have taken away the whole source of contention - for an entire new family of topics that appears to have popped up in recent months. It would have made the whole RFC scope discussion irrelevant - as it has been for the better part of a decade. It would have promoted good will for *everyone*, not just the majority camp that manages to overrun the other or minority camp that manages to stop the other in its tracks. It would have been a win/win. This is the kind of solution we should working on. And yet, any attempts to start discussion on those was met with deafening silence or worse. There seems to be a lot more appetite to devise new ways to silence dissenting voices. Are folks in favor of such new rules truly after a less toxic internals, or is it more about eliminating the pesky opposition that stands in their way to implement the one-sided vision they believe in? Because if it's a less toxic internals we're after, agreeing on frameworks mostly everyone can live with would go *a lot* farther than synthetically placing arbitrary limits on debate. It's never too late. Zeev
