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
Hi internals,
Here is an RFC to "Prevent disruptions of conversations"
https://wiki.php.net/rfc/prevent_disruptions_of_conversations?do=editA 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--
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
Would the removal votes be limited to the same people able to vote on RFCs,
Yes, that's correct.
cheers
Dan
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
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
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
Hey Stas, Hey All.
Am 20.09.19 um 08:00 schrieb 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.
"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 €
Cheers
Andreas
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca |
+---------------------------------------------------------------------+
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.
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
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.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
On Fri, Sep 20, 2019 at 2:24 PM Benjamin Eberlei kontakt@beberlei.de
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.
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
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
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
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]
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
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
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,
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
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
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
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
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
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
Hi internals,
Here is an RFC to "Prevent disruptions of conversations"
https://wiki.php.net/rfc/prevent_disruptions_of_conversations?do=editA 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
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
Hi Paul
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.comModernizing Legacy Applications in PHP
https://leanpub.com/mlaphpSolving the N+1 Problem in PHP
https://leanpub.com/sn1php
Hey there --
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
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
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
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/
Hi internals,
Here is an RFC to "Prevent disruptions of conversations"
https://wiki.php.net/rfc/prevent_disruptions_of_conversations?do=editA 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
Hey Midory, Hey all.
Am 20.09.19 um 09:30 schrieb Midori Koçak:
Wow.
A RFC that it's motivation is to prevent beginners from asking questions.
Is it?
I'm citing from the RFC:
This explicitly wouldn't apply to 'positive' conversations. e.g. if someone 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 that 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.
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.
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.
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 – again – want to quote the RFC on that:
This RFC does not propose a comprehensive Code of Conduct, which will take 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 PHP 7.4 successfully.
Cheers
Andreas
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca |
+---------------------------------------------------------------------+
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
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
Hi Stas,
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
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
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
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]
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
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
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
On Sat, 28 Sep 2019 at 20:10, Rowan Tommins rowan.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]