[RFC] Prevent disruptions of conversations

  107234
September 19, 2019 17:18 Danack@basereality.com (Dan Ackroyd)
Hi internals,

Here is an RFC to "Prevent disruptions of conversations"
https://wiki.php.net/rfc/prevent_disruptions_of_conversations?do=edit

A couple of notes:

* although the RFC would only be applicable to messages sent once it
might be approved, it would still be nice if people consider how their
messages affect other people before then.

* any inappropriate messages sent privately to me have a very high
chance of being replied to on the internals list.

* everyone should bear in mind this RFC might gain more attention from
people outside the PHP internals community than normal.

* I think this solution isn't going to be a great one, and that it
would be better if we had a less controversial way to address
non-productive behaviour. If someone wants to start a discussion on
replacing this RFC that would be great, but as I said in the RFC in my
opinion this is a needed short term solution.

cheers
Dan
Ack
  107236
September 19, 2019 17:33 chasepeeler@gmail.com (Chase Peeler)
On Thu, Sep 19, 2019 at 1:18 PM Dan Ackroyd <Danack@basereality.com> wrote:

> Hi internals, > > Here is an RFC to "Prevent disruptions of conversations" > https://wiki.php.net/rfc/prevent_disruptions_of_conversations?do=edit > > A couple of notes: > > * although the RFC would only be applicable to messages sent once it > might be approved, it would still be nice if people consider how their > messages affect other people before then. > > * any inappropriate messages sent privately to me have a very high > chance of being replied to on the internals list. > > * everyone should bear in mind this RFC might gain more attention from > people outside the PHP internals community than normal. > > * I think this solution isn't going to be a great one, and that it > would be better if we had a less controversial way to address > non-productive behaviour. If someone wants to start a discussion on > replacing this RFC that would be great, but as I said in the RFC in my > opinion this is a needed short term solution. > > cheers > Dan > Ack > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Would the removal votes be limited to the same people able to vote on RFCs,
or open to all list members? -- Chase Peeler chasepeeler@gmail.com
  107237
September 19, 2019 17:36 Danack@basereality.com (Dan Ackroyd)
On Thu, 19 Sep 2019 at 18:33, Chase Peeler <chasepeeler@gmail.com> wrote:
> > Would the removal votes be limited to the same people able to vote on RFCs,
Yes, that's correct. cheers Dan
  107238
September 19, 2019 17:38 chasepeeler@gmail.com (Chase Peeler)
On Thu, Sep 19, 2019 at 1:36 PM Dan Ackroyd <Danack@basereality.com> wrote:

> On Thu, 19 Sep 2019 at 18:33, Chase Peeler <chasepeeler@gmail.com> wrote: > > > > Would the removal votes be limited to the same people able to vote on > RFCs, > > Yes, that's correct. > > cheers > Dan >
So, in other words, if the majority of core members decide they want to force strict typing in PHP 9, and non-core PHP developers voice their opposition to such a change, there would be nothing to prevent those core members from voting to suspend the non-core members from the list, except to hope that such power wouldn't abused? -- Chase Peeler chasepeeler@gmail.com
  107239
September 19, 2019 18:10 kalle@php.net (Kalle Sommer Nielsen)
Den tor. 19. sep. 2019 kl. 20.38 skrev Chase Peeler <chasepeeler@gmail.com>:
> So, in other words, if the majority of core members decide they want to > force strict typing in PHP 9, and non-core PHP developers voice their > opposition to such a change, there would be nothing to prevent those core > members from voting to suspend the non-core members from the list, except > to hope that such power wouldn't abused?
That is correct. What it seems to me like you are hinting here is that no Core Developer is listening to the community at large feedback, which is simply not true. I do not see the latter part of your question as an issue if you got nothing to hide. In the time the PHP project has been going, then I think less than a handful of people have been banned from Internals, one of them being Reindl who still keeps messaging people off list (as you most likely remember from some of the previous debates you have taken part of). So given that track record, along with how the project philosophy generally is, I do not see abuse being a problem, even the sligtest. If you think that not having a say by not having the right to vote, then I advise you to contribute by code to earn it like all of us have. -- regards, Kalle Sommer Nielsen kalle@php.net
  107248
September 20, 2019 06:00 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> taken part of). So given that track record, along with how the project > philosophy generally is, I do not see abuse being a problem, even the > sligtest.
There are a lot of things that I thought our project philosophy does not admit, but turns out I have been wrong. I don't see why if we are already discussing banning people for questioning the holy RFC process, we'd need any "abuse" to have a problem. I think mere "use" of this RFC, as written - to ban people for expressing "wrong" thoughts that somebody (who?) deems "disrupting" - IMO would be abuse enough. And if it's never intended to be used, then why have it? As you yourself mentioned, we've dealt with rare disruptive individuals before it without too much problem and without dramatic speech code RFCs. Clearly, this is meant to go further than that. And that direction is scary to me. -- Stas Malyshev smalyshev@gmail.com
  107250
September 20, 2019 07:14 Andreas Heigl <andreas@heigl.org>
--VcQyx3FL3LUiKidXCfwbK6nTvJmPxnka4
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Hey Stas, Hey All.

Am 20.09.19 um 08:00 schrieb Stanislav Malyshev:
> Hi! >=20 >> taken part of). So given that track record, along with how the project=
>> philosophy generally is, I do not see abuse being a problem, even the=
>> sligtest. >=20 > There are a lot of things that I thought our project philosophy does no= t
> admit, but turns out I have been wrong. I don't see why if we are > already discussing banning people for questioning the holy RFC process,=
> we'd need any "abuse" to have a problem. I think mere "use" of this RFC= ,
> as written - to ban people for expressing "wrong" thoughts that somebod= y
> (who?) deems "disrupting" - IMO would be abuse enough. And if it's neve= r
> intended to be used, then why have it? As you yourself mentioned, we've=
> dealt with rare disruptive individuals before it without too much > problem and without dramatic speech code RFCs. Clearly, this is meant t= o
> go further than that. And that direction is scary to me.
"we" have not dealt with disruptive people, IIRC someone took action and removed them. "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... "without dramatic speech code"... Yes. That was exactly the problem. No process that was agreed on *before* shit hits the fan. No one wants to ban people "for questioning the whole RFC process". A ban is something that *can* occur *after* people have tried other means of making the person in question aware of their disruptive behaviour *and nothing changed*. *After* that *everyone with a vote* can decide on whether that behaviour validates a ban. 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. 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... Just my 0.02 =E2=82=AC Cheers Andreas
>=20
--=20 ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50=C2=B022'59.5" E 08=C2=B0= 23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +---------------------------------------------------------------------+ | http://hei.gl/root-ca | +---------------------------------------------------------------------+ --VcQyx3FL3LUiKidXCfwbK6nTvJmPxnka4--
  107260
September 20, 2019 09:52 zeev@php.net (Zeev Suraski)
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 <andreas@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
  107266
September 20, 2019 11:24 kontakt@beberlei.de (Benjamin Eberlei)
On Fri, Sep 20, 2019 at 11:53 AM Zeev Suraski <zeev@php.net> wrote:

> 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 <andreas@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. >
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.
> 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. 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. 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.
> 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. >
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. I would really like to see that you propose an RFC with the technical details of how a strict mode should look like and work. Then we can finally discuss it based on how it would work and not how it could look like. But by never actually proposing a technical solution I feel that the discussion just drags on unproductively.
> 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 >
  107268
September 20, 2019 15:03 zeev@php.net (Zeev Suraski)
On Fri, Sep 20, 2019 at 2:24 PM Benjamin Eberlei <kontakt@beberlei.de>
wrote:

> > > On Fri, Sep 20, 2019 at 11:53 AM Zeev Suraski <zeev@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.
  107337
September 27, 2019 05:59 zeev@php.net (Zeev Suraski)
On Fri, Sep 20, 2019 at 12:52 PM Zeev Suraski <zeev@php.net> wrote:

> > Speaking of 'disruptive behavior' that the antithesis of promoting 'good > will' - this pseudo RFC is a textbook example. >
I wrote an analysis of this outlandish proposal that I hope some may find useful: https://wiki.php.net/rfc/analysis/prevent_disruptions_of_conversations Zeev
  107338
September 27, 2019 08:26 brendt@stitcher.io (Brent)
Hello all

While my conclusions differ from Zeev's on this topic, this document addresses many valid point as to why this RFC in its current form shouldn't be voted in. I believe it should be added in the original RFC as a counterargument — I think internals@ recently agreed that adding counter arguments to RFCs was something that's allowed?

Zeev, while I agree with many of your points, you also don't offer a concrete solution. You've been very vocal about the RFC process being broken, which caused the majority of what people consider "disruptions" on internals@ lately. I think the community would benefit if internals@ started to put things into practice. That means making a CoC and reevaluating the RFC process.

Maybe this can only be done if key core members came together IRL for a few days? I reckon money might be a problem here, but this could probably be solved via crowd funding. If 5 to 10 million people are using PHP, chances are there a quite a few companies invested enough in its future to actually contribute to it, financially.

I do think Dan's RFC lacks in several areas, though he actually took the time to try and improve the system. I hope core members like yourself will make the same effort in the near future, so that months of having the same discussions can finally end.

Kind regards
Brent
On 27 Sep 2019, 08:00 +0200, Zeev Suraski <zeev@php.net>, wrote:
> On Fri, Sep 20, 2019 at 12:52 PM Zeev Suraski <zeev@php.net> wrote: > > > > > Speaking of 'disruptive behavior' that the antithesis of promoting 'good > > will' - this pseudo RFC is a textbook example. > > > > I wrote an analysis of this outlandish proposal that I hope some may find > useful: > > https://wiki.php.net/rfc/analysis/prevent_disruptions_of_conversations > > Zeev
  107343
September 27, 2019 12:55 rowan.collins@gmail.com (Rowan Tommins)
On Fri, 27 Sep 2019 at 09:27, Brent <brendt@stitcher.io> wrote:

> Zeev, while I agree with many of your points, you also don't offer a > concrete solution. >
To be fair to Zeev, he did in fact try to kick off a discussion about Workflows and Voting back in January: https://externals.io/message/103917 | https://wiki.php.net/rfc/voting2019 For various reasons, both within the community and outside it, this proposal was suspended. The other problem with demanding people propose solutions at this point is that we haven't agreed on what the problems are. Depending who you ask, the problems to be tackled might include any of: - the tone of the list is too aggressive, and needs moderation - discussions are happening on the list which should be elsewhere - people are posting too many messages - proposals are being made which are against the spirit of the language - the language is evolving too fast, or too slowly - the direction of the language is poorly defined - proposals are being put to a vote which should be decided a different way - core developers are wielding undue influence, or being denied necessary influence - voting rights are ill-defined .... and many more besides. Some of these should be tackled as separate issues, but some are symptoms of each other. If I had to pick one root cause, it would be the lack of clear leadership and process, because without that it's not clear who has authority to tackle the others. But we need to reach some consensus on the right question before we start digging into detailed answers. Regards, -- Rowan Tommins [IMSoP]
  107341
September 27, 2019 09:43 Danack@basereality.com (Dan Ackroyd)
On Fri, 27 Sep 2019 at 07:00, Zeev Suraski <zeev@php.net> wrote:
> > the RFC process, which was never designed to regulate > the most fundamental communications channel
Systems grow, and sometimes are used for things outside those that they were initially designed for. An example of this is PHP, which is used for many things other than 'homepages'.
>'Adversarial' off-topic discussions are best off not happening > at all, but if they do happen - it's best that they're super > short and taken off list. There's no need to bug everyone > with the drama.
I strongly disagree. Theoretically, if someone wants to send 'adversarial' communications to other internals contributors, they should either do it where everyone can see those messages, or not send them. sincerely, Dan Ackroyd
  107344
September 27, 2019 21:25 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> I strongly disagree. > > Theoretically, if someone wants to send 'adversarial' communications > to other internals contributors, they should either do it where > everyone can see those messages, or not send them.
I appreciate that this may be your personal preference, but it's just that - your personal preference. There's no justification to force the communication style preferred to you on everybody else. You may easily enforce it for yourself - just don't read any emails that did not pass through the list on any of the list topics, you can even make an automatic filter to make that happen - but there's no base for forcing it onto others that may prefer different mode of communication and making it a matter of general vote. -- Stas Malyshev smalyshev@gmail.com
  107342
September 27, 2019 11:56 pierre.php@gmail.com (Pierre Joye)
On Fri, Sep 27, 2019, 1:00 PM Zeev Suraski <zeev@php.net> wrote:

> On Fri, Sep 20, 2019 at 12:52 PM Zeev Suraski <zeev@php.net> wrote: > > > > > Speaking of 'disruptive behavior' that the antithesis of promoting 'good > > will' - this pseudo RFC is a textbook example. > > > > I wrote an analysis of this outlandish proposal that I hope some may find > useful: > > https://wiki.php.net/rfc/analysis/prevent_disruptions_of_conversations
I read it through (will comment on a few points at a later time), however I would like to see first and foremost a clear rule about abusing languages, sent on internals or as private emails to any participants. best,
> >
  107240
September 19, 2019 18:11 marandall@php.net (Mark Randall)
On 19/09/2019 18:38, Chase Peeler wrote:
> So, in other words, if the majority of core members decide they want to > force strict typing in PHP 9, and non-core PHP developers voice their > opposition to such a change, there would be nothing to prevent those core > members from voting to suspend the non-core members from the list, except > to hope that such power wouldn't abused?
You may be misinterpreting the intent of the RFC. I don't believe this RFC is aimed at silence productive debate, it is clearly aimed at limiting the access of what I can only imagine is a small number of people whose continued involvement would be severely detrimental the proper functioning of internals. For example, if one person were to be responsible for between 30% to 40% of all posts in a given high-volume day, that person would, quite rightly, be seen as entering the realms of disruptive behaviour in light of the existing internals guidelines regarding considerate posting, and they may find themselves prevented from continuing those actions. Something I think most people would consider entirely reasonable. Mark Randall
  107242
September 19, 2019 18:54 pmjones@pmjones.io ("Paul M. Jones")
> On Sep 19, 2019, at 12:18, Dan Ackroyd <Danack@basereality.com> wrote: > > Hi internals, > > Here is an RFC to "Prevent disruptions of conversations" > https://wiki.php.net/rfc/prevent_disruptions_of_conversations?do=edit
Quoting the RFC:
> The RFC process is currently the way that the PHP internals team make decisions.
"Make decisions" on what specific topics? Is there any articulable limiting principle here? -- Paul M. Jones pmjones@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
  107247
September 20, 2019 05:50 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> Here is an RFC to "Prevent disruptions of conversations" > https://wiki.php.net/rfc/prevent_disruptions_of_conversations?do=edit
I am not sure what is the purpose of this. Teaching other adults how to behave? Its usually a futile task. The RFC is expressed in extremely vague terms, like: they are not allowed to use their voice to try to prevent other people's conversation. What's "preventing other people's conversation"? How could I, not having access to admin interface of the list to unsubscribe/block people, prevent anybody from conversing with anybody else on the list? Sending many more emails than other contributors. What's "many more"? Who decides it? Why sending more emails is bad - maybe it's RFC author answering questions? Maybe it's somebody who knows a lot about the topic of the discussion? Repeatedly telling other contributors that they are not allowed to discuss You mean like this RFC which literally just told people they are not allowed to send "too many" emails and discuss RFC votes? Well, I guess it's not "repeatedly" but if this RFC is mentioned once more... Repeatedly asking people to hold off on proposing an RFC. Why not? If I think an RFC makes no sense, why won't I suggest the potential proposer to save themselves the effort and the negative feelings by not proposing something which is no good? However other behaviors that people find disruptive What people? Who chooses which people are allowed to ban people from discussions by declaring them "disruptive" and why do we need to give them such power? And why would we want to have such people? That looks like a recipe for disaster. It is very disruptive to have people say that they reject the result of an RFC vote So now people are not allowed to speak about their opinions that something wasn't done properly here. Not only we declare the RFC vote process sacred and the only possible way to decide anything forever and reject even trying to find any other ways - now we want to ban people that dare to speak about possible deficiencies and problems in our decisions from the community completely? What is going on here?! Being open to criticism and disagreement is the only way to maintain the quality of any community - software or otherwise. Once we start banning people for disagreeing with the holy RFC, there wouldn't be any reasonable discussion possible. It's only when a conversation is adversarial that the conversation should remain on list. Why should we police actions of people outside community? If you don't want to receive emails from a particular person, I could help you with setting up your email filters. There are other members of the community that I heard recently also are pretty proficient with those, so if you don't want to speak with someone, it is easy to achieve without starting to pretend to be Email World Police. I am sorry if somebody sent you a nasty email (I have no idea if somebody did, but looks like it) but that's not the reason to introduce martial law here.
> * although the RFC would only be applicable to messages sent once it > might be approved, it would still be nice if people consider how their > messages affect other people before then.
I have read this message, announcing this RFC, and it affected me very negatively. It looked to me as an attempt, under the guise of making discussion better, to stifle the expression, introduce arbitrary and vague rules, which would inevitably lead to rule lawyering and replacement of discussion on technical merits with discussion of who should not be allowed to talk at all - the very thing this RFC ostensibly tries to prevent it will inevitably produce.
> * everyone should bear in mind this RFC might gain more attention from > people outside the PHP internals community than normal.
If I wasn't convinced before that this is the thing we need the least of all I am completely convinced now. Nothing makes working through difficult issues better than a good twitter mob and a bunch of yellow journalism outlets quoting people out of context and trying to pull them into whatever campaign they are trying to wage at this time. Seriously, I don't see any single thing "more attention from people outside" would make better. Not one.
> * I think this solution isn't going to be a great one
I agree wholeheartedly. -- Stas Malyshev smalyshev@gmail.com
  107258
September 20, 2019 09:10 Danack@basereality.com (Dan Ackroyd)
On Fri, 20 Sep 2019 at 06:50, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> > I am not sure what is the purpose of this.
Please can you look at the past 3 months of discussions on this list and ask yourself have those conversations been productive and/or pleasant? Do you think other people think those conversations have been productive and/or pleasant? If you can't see how non-productive and unpleasant those conversations have been, or can't understand that other people see them as non-productive and unpleasant, then I'm not going to be able to persuade you about the need for some rules for preventing disruption.
>> Repeatedly asking people to hold off on proposing an RFC.
> Why not? If I think an RFC makes no sense, why won't I suggest the > potential proposer to save themselves the effort and the negative > feelings by not proposing something which is no good?
It's possible to send the same message with different emotional affect. If it's phrased as, "I think I would vote no on an RFC" it makes your message clear without making the recipient feel bad. If it's phrased as, "You shouldn't bother wasting your time, by proposing a clearly crap idea", it makes the person you are sending it to feel bad. One of those is fine, the other is really wearying behaviour.
> but that's not the reason to introduce > martial law here.
Trying to compare an attempt to keep the mailing list productive to 'introducing martial law' seems quite a stretch. cheers Dan Ack
  107270
September 20, 2019 18:30 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> Please can you look at the past 3 months of discussions on this list > and ask yourself have those conversations been productive and/or > pleasant? Do you think other people think those conversations have > been productive and/or pleasant?
I've seen a lot of conversations here, both productive and not. I am not sure how adding conversations about who should not be allowed to talk and should be expelled from the community for wrongthink and questioning the holy RFC process makes it any better. In my opinion, it would make it much worse.
> It's possible to send the same message with different emotional affect.
So now we have the RFC to boot people from the community because their message has wrong "emotional effect" (on whom?). The emotional effect of this on me is that it makes me very, very sad and disappointed.
> If it's phrased as, "I think I would vote no on an RFC" it makes your > message clear without making the recipient feel bad.
I am sure if you wrote a guide on how to properly speak and put it on wiki, it would be very useful and popular among many members of the community. However what I am objecting to is not to your very helpful advice about how to express my feelings and intents, but your RFC about voting people off the island for saying something somebody decides has wrong "emotional effect". This is a disastrous idea and will lead to complete degradation of the quality of discussion - if you think it's non productive now, wait until you add threads about people demanding their opponents to be silenced because reading their emails makes them feel bad. And I think merely saying "I would not vote for it" does not make it clear how bad I think such development would be. Moreover, saying "I would not vote for it" is quite useless without explaining why. And yes, reading explanation why somebody thinks your idea - which you undoubtedly invested a lot into - is bad may be emotionally taxing. I appreciate that, but that's what should happen when the idea is bad, and I trust everybody here is enough of a mature adult to be able to deal with such an event.
> Trying to compare an attempt to keep the mailing list productive to > 'introducing martial law' seems quite a stretch.
It is a bit of a stretch, I of course do not mean it literally, as I am sure you know. I mean that the things you propose is way out of proportion and will only make things worse productivity-wise. I appreciate and share you intent of making the list productive but I completely reject the means you choose for this - namely, instituting mechanism of (ab)using RFC process to ban people from the community for things like "sending too many emails", questioning RFC process and sending messages with "different emotional affect" than you'd like. -- Stas Malyshev smalyshev@gmail.com
  107249
September 20, 2019 06:25 brendt@stitcher.io (Brent)
internals@ needs what every community needs: proper moderation. Moderators are no dictators who will force their opinion on how the language is shaped, nor will they silence people with fear. This is no alien concept on the internet, and nothing ground breaking or disruptive is being proposed.

Now even though not directly mentioned in the RFC, everyone who has been following internals@ for the last three months knows exactly who and what the RFC is aimed at. My fear is that this discussion will end the same way almost all RFC discussions ended these past months. That's so much time and effort wasted for such a simple thing that almost every community knows how to handle.

Simply appoint some people who have proven they can keep their calm in the past, and act with common sense when it comes to interpersonal communication.

The next step would be to provide a proper CoC — a problem that many OSS communities also have solved already, so no need to invent the wheel — though I fear that proper moderation will be needed in order to have a constructive discussion about a CoC.

After all of that, we can finally focus on things that matter again: building PHP.

Kind regards
Brent
On 19 Sep 2019, 19:19 +0200, Dan Ackroyd <Danack@basereality.com>, wrote:
> Hi internals, > > Here is an RFC to "Prevent disruptions of conversations" > https://wiki.php.net/rfc/prevent_disruptions_of_conversations?do=edit > > A couple of notes: > > * although the RFC would only be applicable to messages sent once it > might be approved, it would still be nice if people consider how their > messages affect other people before then. > > * any inappropriate messages sent privately to me have a very high > chance of being replied to on the internals list. > > * everyone should bear in mind this RFC might gain more attention from > people outside the PHP internals community than normal. > > * I think this solution isn't going to be a great one, and that it > would be better if we had a less controversial way to address > non-productive behaviour. If someone wants to start a discussion on > replacing this RFC that would be great, but as I said in the RFC in my > opinion this is a needed short term solution. > > cheers > Dan > Ack > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
  107267
September 20, 2019 14:03 pmjones@pmjones.io ("Paul M. Jones")
> On Sep 20, 2019, at 01:25, Brent <brendt@stitcher.io> wrote: > > Moderators are no dictators
Maybe, maybe not. But moderators can and do play favorites, banning or silencing one voice (of whom they disapprove) for the same things that they ignore from another voice (of whom they do approve). Moderators, with the power to ban and to silence, become the owners of the project whose communications they moderate. By controlling the flow of information in a project, moderators control the status of the members in that project, and thereby control the direction of the project. -- Paul M. Jones pmjones@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
  107289
September 23, 2019 07:12 brendt@stitcher.io (Brent)
Hi Paul
On 20 Sep 2019, 16:04 +0200, Paul M. Jones <pmjones@pmjones.io>, wrote:
> > > > On Sep 20, 2019, at 01:25, Brent <brendt@stitcher.io> wrote: > > > > Moderators are no dictators > > Maybe, maybe not. > > But moderators can and do play favorites, banning or silencing one voice (of whom they disapprove) for the same things that they ignore from another voice (of whom they do approve).
I feel like internals@ members have very little trust in their peers and fear the world will burn and PHP will die because of moderators who try to keep the discussions ontopic and civil. Say five moderators are appointed and one turns out to be a bad one, a dictator, a villain; the other four *and* the community at large can simply dismiss that bad one.
> > Moderators, with the power to ban and to silence, become the owners of the project whose communications they moderate. By controlling the flow of information in a project, moderators control the status of the members in that project, and thereby control the direction of the project.
I've been part of numerous online communities over the years, and this has never, ever, been a problem anywhere. Now PHP and internals@ might be the exception, though I think a little common sense and human decency will get us a long way and might even make internals@ productive again. Kind regards Brent
> > > -- > Paul M. Jones > pmjones@pmjones.io > http://paul-m-jones.com > > Modernizing Legacy Applications in PHP > https://leanpub.com/mlaphp > > Solving the N+1 Problem in PHP > https://leanpub.com/sn1php > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
  107296
September 23, 2019 13:55 pmjones@pmjones.io ("Paul M. Jones")
Hey there --

>>> On Sep 20, 2019, at 01:25, Brent <brendt@stitcher.io> wrote: >>> >>> Moderators are no dictators >> >> Maybe, maybe not. >> >> But moderators can and do play favorites, banning or silencing one voice (of whom they disapprove) for the same things that they ignore from another voice (of whom they do approve). > > I feel like internals@ members have very little trust in their peers
Perhaps; trust can be hard to come by.
> and fear the world will burn and PHP will die because of moderators who try to keep the discussions ontopic and civil.
I think the fear is not of "the world burning" but of "being silenced." Further, "on-topic" is in the eye of the beholder; once there are moderators, their eyes are the only ones that matter.
> Say five moderators are appointed and one turns out to be a bad one, a dictator, a villain;
We need not presume a villain or dictator. We need presume only groupthink -- a groupthink that biases moderator actions to err always on the same side (that is, the side populated by voices the moderators approve of).
> the other four *and* the community at large can simply dismiss that bad one.
Ah, if only that were true. No, moderators have the power to act immediately, whereas any oversight regarding them can act only slowly, with deliberation, after long latency -- and even *then* only after long discussion, which the moderators themselves control. No, there is no way to "simply" dismiss a moderator.
>> Moderators, with the power to ban and to silence, become the owners of the project whose communications they moderate. By controlling the flow of information in a project, moderators control the status of the members in that project, and thereby control the direction of the project. > > I've been part of numerous online communities over the years, and this has never, ever, been a problem anywhere.
I've been a part of numerous online communities as well, and I have found it to be a problem quite often -- especially at the point of introduction of moderators.
> Now PHP and internals@ might be the exception, though I think a little common sense and human decency will get us a long way and might even make internals@ productive again.
I think there is quite a bit of "common sense and human decency" in play here already, even if not universal and uninterrupted -- nobody on this list is an angel, though some are more devilish than others. -- Paul M. Jones pmjones@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
  107297
September 23, 2019 14:16 cmbecker69@gmx.de ("Christoph M. Becker")
On 23.09.2019 at 15:55, Paul M. Jones wrote:

> Ah, if only that were true. No, moderators have the power to act immediately, whereas any oversight regarding them can act only slowly, with deliberation, after long latency -- and even *then* only after long discussion, which the moderators themselves control. No, there is no way to "simply" dismiss a moderator.
Please read <https://wiki.php.net/rfc/prevent_disruptions_of_conversations>. Thanks, Christoph
  107299
September 23, 2019 14:54 pmjones@pmjones.io ("Paul M. Jones")
> On Sep 23, 2019, at 09:16, Christoph M. Becker <cmbecker69@gmx.de> wrote: > > On 23.09.2019 at 15:55, Paul M. Jones wrote: > >> Ah, if only that were true. No, moderators have the power to act immediately, whereas any oversight regarding them can act only slowly, with deliberation, after long latency -- and even *then* only after long discussion, which the moderators themselves control. No, there is no way to "simply" dismiss a moderator. > > Please read <https://wiki.php.net/rfc/prevent_disruptions_of_conversations>.
I have; I suggest do the same. With that out of the way: was there something in particular to which you wished to draw attention? -- Paul M. Jones pmjones@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
  107251
September 20, 2019 07:30 mtkocak@gmail.com (=?UTF-8?Q?Midori_Ko=C3=A7ak?=)
Wow.

A RFC that it's motivation is to prevent beginners from asking questions.

That's horrible.

 I rather prefer a CoC. What about this? https://confcodeofconduct.com/


On Thu, 19 Sep 2019 at 19:19, Dan Ackroyd <Danack@basereality.com> wrote:

> Hi internals, > > Here is an RFC to "Prevent disruptions of conversations" > https://wiki.php.net/rfc/prevent_disruptions_of_conversations?do=edit > > A couple of notes: > > * although the RFC would only be applicable to messages sent once it > might be approved, it would still be nice if people consider how their > messages affect other people before then. > > * any inappropriate messages sent privately to me have a very high > chance of being replied to on the internals list. > > * everyone should bear in mind this RFC might gain more attention from > people outside the PHP internals community than normal. > > * I think this solution isn't going to be a great one, and that it > would be better if we had a less controversial way to address > non-productive behaviour. If someone wants to start a discussion on > replacing this RFC that would be great, but as I said in the RFC in my > opinion this is a needed short term solution. > > cheers > Dan > Ack > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  107253
September 20, 2019 07:43 Andreas Heigl <andreas@heigl.org>
--D6yxy9i4GfpEAPkOniw5apIlYpeuP7PUr
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Hey Midory, Hey all.

Am 20.09.19 um 09:30 schrieb Midori Ko=C3=A7ak:
> Wow. >=20 > A RFC that it's motivation is to prevent beginners from asking question= s.
Is it? I'm citing from the RFC:
> This explicitly wouldn't apply to 'positive' conversations. e.g. if som= eone asks for help, and you want to contact them in private to offer them=
help, that would be fine. It's only when a conversation is adversarial t= hat the conversation should remain on list. It is not motivated at preventing beginners from asking questions. On the contrary. IMO it encourages them to do so. But one of the first questions should perhaps be who would be willing to answer newcomer-questions off-list. I believe that a newcomer will learn much more with one or two mentors than by asking all the questions to the list= =2E So the motivation is *not* to stop beginners to ask questions, but to prevent the list being flooded by questions that can be handled in a better way for all involved people.
>=20 > That's horrible.
Yes it would be, would that be the intention. I'd like to repeat myself here: The intention is to keep disruptions to a minimum.
>=20 > I rather prefer a CoC. What about this? https://confcodeofconduct.com/=
Let's tackle one goal after the other. While having a CoC is a good thing, that I personally would like the PHP-Project to have, I still remember the last discussions on that topic and they were as disruptive as the current ones.... And I =E2=80=93 again =E2=80=93 want to quote the RFC on that:
> This RFC does not propose a comprehensive Code of Conduct, which will t= ake a significant amount of effort to draft carefully. This is a stop-gap=
measure to allow us to use the internals newsgroup to be able to ship PH= P 7.4 successfully.=20 Cheers Andreas --=20 ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50=C2=B022'59.5" E 08=C2=B0= 23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +---------------------------------------------------------------------+ | http://hei.gl/root-ca | +---------------------------------------------------------------------+ --D6yxy9i4GfpEAPkOniw5apIlYpeuP7PUr--
  107271
September 20, 2019 18:36 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> This is a stop-gap measure to allow us to use the internals newsgroup > to be able to ship PHP 7.4 successfully.
Another thing I feel I have to emphasize here. This has absolutely nothing to do with successful 7.4 release. If from now on internals became so bad we could literally agree on nothing, pass no RFCs, make no decisions, etc. - we still could very well release 7.4 without much trouble. 7.4 is in RC2 and there's no need for any big decisions to be taken at this advanced release stage. So I think it's best to leave 7.4 out of this completely. -- Stas Malyshev smalyshev@gmail.com
  107272
September 20, 2019 18:40 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> Another thing I feel I have to emphasize here. This has absolutely > nothing to do with successful 7.4 release. If from now on internals
Unless I am missing something and we do have still unresolved issues that block the release? Then we probably should go back to figuring them out and not how to ban people instead. -- Stas Malyshev smalyshev@gmail.com
  107298
September 23, 2019 14:27 Danack@basereality.com (Dan Ackroyd)
Hi Stas,

On Fri, 20 Sep 2019 at 19:36, Stanislav Malyshev <smalyshev@gmail.com> wrote:


> This has absolutely nothing to do with successful 7.4 > release. If from now on internals became so bad we could > literally agree on nothing, pass no RFCs, make no > decisions, etc. - we still could very well release 7.4 > without much trouble.
You're right that 7.4 will probably come out, I remain concerned that fixing any bugs that are found during the release process, or inevitably those found after the 7.4.0 release occurs, would be more difficult if people are hesitant to discuss issues on internals. But your point is right, that wording was a commentary and not a required part of the RFC, so I have removed it. I've also added some words to help focus the goal on making conversations more productive, rather than addressing disruption. ---------------------------------------------------------------- # Guidance for 'disruption points of contact' People who are 'disruption points of contact' should: * focus on helping people understand how they are communicating could be disrupting conversations and/or making it hard for other people to have their voices heard. They shouldn't focus on suspending people. * avoid trying to address disruptions for discussions they are taking part in. It's really hard for someone to objectively think about someone's behaviour when you're also taking part in a discussion with them. * avoid acting rashly or unilaterally. Where possible the 'disruption points of contact' should talk through the situation and how best to handle it with at least one other 'disruption point of contact', before addressing it. ---------------------------------------------------------------- cheers Dan Ack
  107302
September 23, 2019 18:28 smalyshev@gmail.com (Stanislav Malyshev)
Hi!


> You're right that 7.4 will probably come out, I remain concerned that > fixing any bugs that are found during the release process, or > inevitably those found after the 7.4.0 release occurs, would be more > difficult if people are hesitant to discuss issues on internals.
What is the base of your concern? Were you or anybody else deterred from using bugs.php.net and reporting 7.4 issue because of completely unrelated discussions going on internals? Which specific bugs were those? Please point them out to the RMs so they could get proper attention. That's why we have threads in every mailing software out there - so you could manage multiple conversations without interfering with each other. I so far haven't heard of any bugs being unfixed because of anything your RFC mentions. Can you name some in 7.4? If it never happened - and the same for all previous releases, which had their share of heated discussions - then I think your concern may be unwarranted, at least as far as releasing 7.4 and fixing the following bugs is concerned.
> I've also added some words to help focus the goal on making > conversations more productive, rather than addressing disruption.
I would like to emphasize again that I completely appreciate the goal of making conversations more productive, but I continue to believe you chose entirely wrong way to go about it and any part of your RFC that deals with excluding people and publicly deeming them disruptive or whatever it is called would lead to exactly the opposite effect. It doesn't mean the community can't have bad apples and doesn't have to deal with them - it's just dealing with them in this manner would likely cause worse effects than the original disruptions. The motivation to abuse such system - especially when it's born out of heated discussions and the RFC seems to have examples targeted at particular opinions of particular people (maybe it's a coincidence, but if it looks that way, that's all that matters) - and use it as a tool to suppress opposition (for their own good, of course) would be too great.
> * avoid trying to address disruptions for discussions they are taking > part in. It's really hard for someone to objectively think about > someone's behaviour when you're also taking part in a discussion with > them.
I wonder where you going to find people that: - Understand the subject of discussion enough to be able to follow it and to render informed opinion on what's going on - Never participated in that discussion or any similar ones - Never had previous discussions with the same people that may left them holding grudges or personal attachments to participants of the current discussions - Do not hold any strong opinions on the topic that may cloud their objectivity - Are active in the community enough so that they can be universally trusted - Are tactful, infinitely patient and have enough free time to thoroughly read humongous discussion threads, politely calm down all the parties and not be ever tempted to take a side of anyone, but remain always objective How would we find such unicorns? -- Stas Malyshev smalyshev@gmail.com
  107257
September 20, 2019 09:01 Danack@basereality.com (Dan Ackroyd)
On Fri, 20 Sep 2019 at 08:30, Midori Koçak <mtkocak@gmail.com> wrote:
> > A RFC that it's motivation is to prevent beginners from asking questions.
Asking questions by itself is not a problem. It only becomes a problem when those questions are taking up a lot of other people's time and making it difficult to even follow threads on this mailing list that it becomes a negative effect. And this RFC seeks to stop disruption, so that the mailing list can be productively used as the main communication for developing PHP core.
> I rather prefer a CoC.
So would I. But please could you start a separate thread so that people can follow that subject separately. cheers Dan Ack
  107345
September 28, 2019 19:10 rowan.collins@gmail.com (Rowan Tommins)
On 19 September 2019 18:18:40 BST, Dan Ackroyd <Danack@basereality.com> wrote:
>Here is an RFC to "Prevent disruptions of conversations" >https://wiki.php.net/rfc/prevent_disruptions_of_conversations
Looking at this RFC purely from the stated motivation, I think that there are two key things that need improving before it is considered for a vote. Firstly, it doesn't define things clearly enough. It is certainly easier to define general principles than it is to codify every possible scenario in advance; however, the looser those definitions, the more trust needs to be placed in whoever has the task of interpreting them. As it stands, this proposal carefully avoids appointing anyone to have that authority, meaning that every application of the process would be subject to open-ended debate. If the intention is to put a short-term rule in place without opening too many additional questions, it would perhaps be clearer to propose a small set of specific rules, which don't cover everything, but can be applied clearly and immediately. Secondly, it only handles the most extreme cases; there is no halfway between asking nicely and an indefinite ban. Not only does that leave a lot of grey areas that are not addressed at all, but it reduces the deterrence power - all that's needed to avoid punishment is to be not quite bad enough for the harshest penalty. A simple approach that I've seen work well is to have a short ban - say a week, or a month - for a first offence, scaling to a year (or indefinite) after three or more. That gives warnings more "teeth", and punishments more flexibility. I would be interested to hear your thoughts on these suggestions. Regards, Hi Dan, -- Rowan Tommins [IMSoP]
  107346
September 29, 2019 19:22 Danack@basereality.com (Dan Ackroyd)
On Sat, 28 Sep 2019 at 20:10, Rowan Tommins collins@gmail.com> wrote:
> > > I would be interested to hear your thoughts on these suggestions. >
I encourage you to work on them. Or anyone else who cares to. And the sooner there is concrete alternative proposal the better. But in the meantime, I think this RFC is an improvement on the current situation. If nothing else, the way that people were previously dealt with was unfair, at least in my opinion. Having a defined process would be better, imo, than Rasmus 'dictatorially' removing people: https://news-web.php.net/php.internals/101528 Although I agree with the action of removing those people, there were no clear rules, or people who could 'officially' tell those people "your behaviour is being disruptive". This RFC at least provides a framework for that. cheers Dan Ack
  107347
September 29, 2019 19:34 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> Although I agree with the action of removing those people, there were > no clear rules, or people who could 'officially' tell those people > "your behaviour is being disruptive". This RFC at least provides a > framework for that.
We don't need any people that need to "officially" tell anything. You can just tell. You don't need anything "officially" for that, your send button works just fine without that. What this RFC provides framework for is for initiating contentious and harmful personal attacks on people because they "send too many emails" or question the RFC process or tell somebody their idea for the RFC may not be the best one ever, and equally grievous sins, and somehow make it look as if these people are somehow against the community by the mere fact that somebody felt they are "disruptive". There's no need of any "framework" for such thing. -- Stas Malyshev smalyshev@gmail.com
  107349
September 29, 2019 21:06 pmjones@pmjones.io ("Paul M. Jones")
> On Sep 29, 2019, at 14:34, Stanislav Malyshev <smalyshev@gmail.com> wrote: > > What this RFC provides framework > for is for initiating contentious and harmful personal attacks on people > because they "send too many emails" or question the RFC process or tell > somebody their idea for the RFC may not be the best one ever, and > equally grievous sins, and somehow make it look as if these people are > somehow against the community by the mere fact that somebody felt they > are "disruptive". There's no need of any "framework" for such thing.
Hear, hear. -- Paul M. Jones pmjones@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
  107350
September 30, 2019 09:39 rowan.collins@gmail.com (Rowan Tommins)
On Sun, 29 Sep 2019 at 20:22, Dan Ackroyd <Danack@basereality.com> wrote:

> On Sat, 28 Sep 2019 at 20:10, Rowan Tommins collins@gmail.com> > wrote: > > > > > > I would be interested to hear your thoughts on these suggestions. > > > > I encourage you to work on them. Or anyone else who cares to. And the > sooner there is concrete alternative proposal the better. >
Hi Dan, The purpose of the two week discussion period for RFCs is so that we can work together to improve them, not so that people can independently work on overlapping proposals.
> But in the meantime, I think this RFC is an improvement on the current > situation.
As I said, I have tried to measure the proposal against its stated aim: to prevent disruption of the mailing list. In its current form, I do not think it will achieve that aim.
> Although I agree with the action of removing those people, there were > no clear rules, or people who could 'officially' tell those people > "your behaviour is being disruptive". This RFC at least provides a > framework for that.
Your proposal provides neither clear rules, nor clear authority, and indeed goes out of its way to avoid both, with an open definition of "disruptive behaviour" and a careful avoidance of the word "moderator". In some extremely rare cases there is consensus that a ban is clearly warranted; in such cases, any vote would be a formality. It would feel more legitimate than a "dictatorial" decision, but the situation arises so rarely it would make very little difference to the general tone of the community. In any other case, a vote under this proposal would be extremely contentious, and is likely to result in more disruption than it removes. Regards, -- Rowan Tommins [IMSoP]