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 alternati
> 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
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 anyth
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
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
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 -
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
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 t
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
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
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/analysi
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 o
> 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 -
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
> with
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
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
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 t
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
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 n
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 product
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
> 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, wit
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 wa
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
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 conversation
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 f
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 c
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
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 ph
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.
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
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:
t
> 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
>
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 wrot
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-c
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 t
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 the
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
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
>
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 th
40 matches
Mail list logo
