Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Rowan Tommins]

On Sun, 29 Sep 2019 at 20:22, Dan Ackroyd  wrote:

> On Sat, 28 Sep 2019 at 20:10, Rowan Tommins 
> 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]

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Paul M. Jones]

> On Sep 29, 2019, at 14:34, Stanislav Malyshev  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
pmjo...@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

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Dan Ackroyd]

On Sat, 28 Sep 2019 at 20:10, Rowan Tommins  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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Rowan Tommins]

On 19 September 2019 18:18:40 BST, Dan Ackroyd  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]

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Rowan Tommins]

On Fri, 27 Sep 2019 at 09:27, Brent  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]

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Pierre Joye]

On Fri, Sep 27, 2019, 1:00 PM Zeev Suraski  wrote:

> On Fri, Sep 20, 2019 at 12:52 PM Zeev Suraski  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,

>
>

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Dan Ackroyd]

On Fri, 27 Sep 2019 at 07:00, Zeev Suraski  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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[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 , wrote:
> On Fri, Sep 20, 2019 at 12:52 PM Zeev Suraski  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

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Zeev Suraski]

On Fri, Sep 20, 2019 at 12:52 PM Zeev Suraski  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

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Paul M. Jones]

> On Sep 23, 2019, at 09:16, Christoph M. Becker  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 .

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
pmjo...@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

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Dan Ackroyd]

Hi Stas,

On Fri, 20 Sep 2019 at 19:36, Stanislav Malyshev  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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[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 .

Thanks,
Christoph

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Paul M. Jones]

Hey there --

>>> On Sep 20, 2019, at 01:25, Brent  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
pmjo...@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

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Brent]

Hi Paul
On 20 Sep 2019, 16:04 +0200, Paul M. Jones , wrote:
>
>
> > On Sep 20, 2019, at 01:25, Brent  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
> pmjo...@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
>

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Zeev Suraski]

On Fri, Sep 20, 2019 at 2:24 PM Benjamin Eberlei 
wrote:

>
>
> On Fri, Sep 20, 2019 at 11:53 AM Zeev Suraski  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 

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Paul M. Jones]

> On Sep 20, 2019, at 01:25, Brent  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
pmjo...@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

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Benjamin Eberlei]

On Fri, Sep 20, 2019 at 11:53 AM Zeev Suraski  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  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 

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[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  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 

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Dan Ackroyd]

On Fri, 20 Sep 2019 at 06:50, Stanislav Malyshev  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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Dan Ackroyd]

On Fri, 20 Sep 2019 at 08:30, Midori Koçak  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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Andreas Heigl]

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:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Midori Koçak]

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  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
>
>

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Andreas Heigl]

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:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[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 , 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
>

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Paul M. Jones]

> On Sep 19, 2019, at 12:18, Dan Ackroyd  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
pmjo...@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

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Chase Peeler]

I've copy/pasted Kalle's email at the bottom so that I can address points
made in both emails without risking someone getting distracted from the
myriad of emails relating to coordination of work on PHP.

On Thu, Sep 19, 2019 at 2:11 PM Mark Randall  wrote:

> 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.
>
>
It's not the intent that I'm worried about. It's the potential application.
No one ever puts a system in place and goes "I'm sure we'll abuse this,
but, who cares." Everyone always assumes that their group is the exception,
and they will be responsible, and will never abuse the power they were
given. History has shown us that regardless of how noble the intentions
were, if there is a potential for abuse, it will likely be exploited.

Also, part of the intent is to prevent RFC discussions from distracting
from the ability to use this list to coordinate work with PHP. If that's
the case, wouldn't the better option be to create a new list for RFC
discussions, and allow PHP-DEV to exist for coordinating work?

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.
>
>
It also has the unintended consequence of silencing people that are afraid
they might be stepping over the line. The line is imaginary and entirely
subjective, so, it's easy to see why.  Also, non-core developers definitely
feel intimidated by the core developers on this list. They feel they are
not encouraged to contribute. I was talking to someone the other day that
doesn't even feel comfortable voicing his agreement with certain things,
lest it come back to negatively impact his ability to propose some changes
he'd like to see.


> Something I think most people would consider entirely reasonable.
>
> Mark Randall
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



> 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.
>
>
That wasn't my hint at all. My hint was that this is a very big potential
for abuse.


> 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.
>
>
In that time we also haven't put a process in place where a small number of
PHP developers can vote on the ability to suspend another member. As such,
it took grievous abuses to get suspended.  Just because power wasn't abused
in the past, doesn't mean it won't be in the future. This is especially
true if you put things in place which allow those abuses to take place with
an air of legitimacy around them.


> 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.
>

I've never complained once about the fact that I can't vote. However, I
think it's all the more important that I'm able to voice my opinion because
of that. Also, while contributing to PHP in order to be able to vote on
changes to PHP makes sense, I don't necessarily think that contributing to
PHP qualifies you to have a say in who can participate in the discussions
about those changes.

In the end, why should I not fear abuse of power? Dan, who wrote this RFC,
ended an email yesterday with an attempt to intimidate me - noting my
response and how long it took me to send it. People like to accuse Zeev of
making power grabs - yet I've never seen him attempt to put something in
place which could be used to actually silence his critics.

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Kalle Sommer Nielsen]

Den tor. 19. sep. 2019 kl. 20.38 skrev Chase Peeler :
> 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
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Chase Peeler]

On Thu, Sep 19, 2019 at 1:36 PM Dan Ackroyd  wrote:

> On Thu, 19 Sep 2019 at 18:33, Chase Peeler  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
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Dan Ackroyd]

On Thu, 19 Sep 2019 at 18:33, Chase Peeler  wrote:
>
> Would the removal votes be limited to the same people able to vote on RFCs,

Yes, that's correct.

cheers
Dan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Chase Peeler]

On Thu, Sep 19, 2019 at 1:18 PM Dan Ackroyd  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
chasepee...@gmail.com

[PHP-DEV] [RFC] Prevent disruptions of conversations

[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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php