Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104032
MIME-Version: 1.0
References: <CAF+90c-auGYVhCzt-1GpdU1-uZ+xiY7A_FwWSRKftuKBwtszYg@mail.gmail.com>
 <CACDmYyc0GSdeNV8WGyPTmZnhuKS0gCbCJMwJs4bjFWEv4B2aaQ@mail.gmail.com>
In-Reply-To: <CACDmYyc0GSdeNV8WGyPTmZnhuKS0gCbCJMwJs4bjFWEv4B2aaQ@mail.gmail.com>
Date: Sat, 2 Feb 2019 18:13:38 +0100
Message-ID: <CAOwTYAvDB7qHsOtFrh066fFTtLncL2p6EADkfbK99z-XNqgL1A@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="0000000000000e94440580ec6275"
Subject: Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
From: krakjoe@gmail.com (Joe Watkins)

--0000000000000e94440580ec6275
Content-Type: text/plain; charset="UTF-8"

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
> >
>

--0000000000000e94440580ec6275--