Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104033
MIME-Version: 1.0
References: <CAF+90c-auGYVhCzt-1GpdU1-uZ+xiY7A_FwWSRKftuKBwtszYg@mail.gmail.com>
 <CACDmYyc0GSdeNV8WGyPTmZnhuKS0gCbCJMwJs4bjFWEv4B2aaQ@mail.gmail.com> <CAOwTYAvDB7qHsOtFrh066fFTtLncL2p6EADkfbK99z-XNqgL1A@mail.gmail.com>
In-Reply-To: <CAOwTYAvDB7qHsOtFrh066fFTtLncL2p6EADkfbK99z-XNqgL1A@mail.gmail.com>
Date: Sat, 2 Feb 2019 18:15:35 +0100
Message-ID: <CAOwTYAt99FxYbZYdV9f5xUcQz7My1Y6vPwxSSJF1yL4tbWRn2Q@mail.gmail.com>
To: Legale Legage <legale.legale@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000f6e1e0580ec69ad"
Subject: Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
From: krakjoe@gmail.com (Joe Watkins)

--0000000000000f6e1e0580ec69ad
Content-Type: text/plain; charset="UTF-8"

Just a quick note ...

I should say that bug fixes should not require an RFC at all, but the line
between bug, quick fix and feature is blurry. Sometimes it is necessary to
gather consensus and voting is the most effective way we have to do that.

Cheers
Joe

On Sat, 2 Feb 2019 at 18:13, Joe Watkins <krakjoe@gmail.com> wrote:

> Hi Legale, internals,
>
> > I want to say that even a small and fairly
> simple code change,
> which I proposed to push through the bureaucracy, was difficult.
>
> This, I am afraid is all too common. Many many times, while working
> through github issues, I will be uncomfortable with making a merge for
> someone without input from internals. I would tell that person to start a
> discussion on internals and they would be flat ignored, their change dead
> in the water, and their reason to continue contributing evaporates.
>
> I think these proposals have a chance of reducing the occurrences of those
> situations: We all know that for less interesting topics, vote time is
> crunch time and that is when internals pays attention. If there is no
> necessity to wait for X weeks between proposing a change that nobody really
> has a desire to discuss, and opening a vote, that person can move forward
> quickly, we get our bug/quick fix faster, everyone is happy, especially
> that contributor who feels valued, and who feels that PHP's development
> process is geared toward actual development of PHP.
>
> Cheers
> Joe
>
> On Sat, 2 Feb 2019 at 18:02, Legale Legage <legale.legale@gmail.com>
> wrote:
>
>> Hello, internals.
>> I am with you recently. But as a person with a fresh look, let me insert
>> my
>> 5 penny coin.
>> About half a year ago, I knew about the C language only that such a
>> language exists.
>> The reason I decided to contribute is curiosity. So I'm probably not as
>> motivated
>> as some of other internals. I want to say that even a small and fairly
>> simple code change,
>> which I proposed to push through the bureaucracy, was difficult. So If RFC
>> process
>> becomes more difficult this "road" will be closed for some sort of random
>> people like me.
>> I hope this doesn't happen.
>>
>> Best regards, Ruslan
>>
>> On Sat, 2 Feb 2019 at 17:24, Nikita Popov <nikita.ppv@gmail.com> wrote:
>>
>> > Hi internals,
>> >
>> > After discussing the topic with a number of current and former
>> > contributors, I feel that the workflow & voting RFC currently under
>> > discussion is moving us in the wrong direction. I will not comment on
>> the
>> > rather questionable proposed changes to voting eligibility, as these are
>> > already extensively discussed in the RFC thread.
>> >
>> > The remainder of the workflow & voting RFC is mostly concerned with
>> > defining stricter rules and more rigid procedures for the RFC process.
>> It
>> > increases the amount of bureaucracy and overhead involved in the RFC
>> > process, making the RFC processes even less suitable for smaller changes
>> > than it already is.
>> >
>> > The proposal I would like to present in the following is not my own
>> idea,
>> > it has been suggested by Anthony Ferrara. Because I found the idea very
>> > compelling, I'm presenting it to the list now.
>> >
>> > ---
>> >
>> > Instead of making the RFC process more complex and rigid, we should
>> > simplify and streamline it. The RFC process is reduced to only two
>> rules:
>> >
>> > 1. All primary RFC votes require a 2/3 majority, while secondary votes
>> > resolving implementation details may use a simple majority. (This is
>> > already proposed in the voting margins RFC, so discussion about this
>> point
>> > should be directed into the corresponding RFC thread.)
>> >
>> > 2. All RFCs must have a voting period of at least 14 days, announced in
>> a
>> > separate [VOTE] thread.
>> >
>> > ---
>> >
>> > That's it. More notable than the rules itself are probably the two main
>> > omissions:
>> >
>> > 1. There is no required discussion period. However, if an RFC vote is
>> > opened without leaving enough time for discussion, then voters can and
>> > should vote the RFC down on the grounds of insufficient discussion.
>> >
>> > The motivation for not having a fixed discussion period (but a longer
>> > minimum voting period) is that RFCs come in many different forms and
>> sizes.
>> > Some RFCs are long and complex (such as the recent typed properties RFC)
>> > and require more time for an adequate discussion. Other RFCs are simple
>> and
>> > of limited scope (such as an extension function addition) and do not
>> > require extensive discussion.
>> >
>> > While a two week discussion period should remain a good guideline for
>> > language-related RFCs, it is up to the RFC author to decide when
>> opening an
>> > RFC vote is appropriate. This will depend both on the scope of the RFC
>> > itself and the activity of the discussion. (It is an unfortunate fact
>> that
>> > many RFCs receive their first meaningful feedback during the voting
>> > period.)
>> >
>> > 2. There is no moratorium period after an RFC vote fails. If you think
>> that
>> > you have made significant progress on an RFC and resolved the issues
>> that
>> > made the previous vote fail, you can give it another shot at any time,
>> > without having to wait out some fixed period.
>> >
>> > A failed vote does not (necessarily) mean that a feature is not wanted.
>> It
>> > is quite common for significant changes to fail on first vote, due to
>> > issues in the initial proposal. A failed vote should not be a
>> > discouragement, but a motivation to address problems expressed during
>> > discussion or voting.
>> >
>> > It should go without saying that if you restart a failed RFC vote
>> without
>> > making substantial changes to the RFC, the result is unlikely to change
>> in
>> > your favor, and that continued misbehavior might be seen as spam.
>> >
>> > ---
>> >
>> > Essentially, this is about making the RFC process more suitable for
>> changes
>> > small and large, and empowering both RFC authors and the voter base to
>> make
>> > decisions that are appropriate for each RFC.
>> >
>> > What do you think?
>> >
>> > Regards,
>> > Nikita
>> >
>>
>

--0000000000000f6e1e0580ec69ad--