Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104030
MIME-Version: 1.0
References: <CAF+90c-auGYVhCzt-1GpdU1-uZ+xiY7A_FwWSRKftuKBwtszYg@mail.gmail.com>
In-Reply-To: <CAF+90c-auGYVhCzt-1GpdU1-uZ+xiY7A_FwWSRKftuKBwtszYg@mail.gmail.com>
Date: Sat, 2 Feb 2019 18:43:25 +0200
Message-ID: <CAL0xaBESjzxismF+rmxFD+YffKX1vzNHvHY=gDNiHQS=YiiOdQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000207290580ebf750"
Subject: Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--0000000000000207290580ebf750
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=D1=81=D0=B1, 2 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. =D0=B2 18:24, Nikita=
 Popov <nikita.ppv@gmail.com>:

> 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 poin=
t
> 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 size=
s.
> 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 a=
nd
> 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 tha=
t
> 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 th=
at
> 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. I=
t
> 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 i=
n
> your favor, and that continued misbehavior might be seen as spam.
>
> ---
>
> Essentially, this is about making the RFC process more suitable for chang=
es
> small and large, and empowering both RFC authors and the voter base to ma=
ke
> decisions that are appropriate for each RFC.
>
> What do you think?
>
> Regards,
> Nikita
>

Hello Nikita, internals,

as a user-land developer and at least a decade reader of internals (and
basically seen it all on here) and occasional poster, I highly approve of
your proposal. I like it very much.

To me, this represents a great move towards a less bureaucratic and
edge-case prone process, that requires a high bar of approval from the
internal's community and ability to iterate on complex RFC's at a decent
pace and not hinder small easy changes that are relatively a no-brainer
like it is right now.

I literally see no holes or edge cases in this proposal. Though I can't
vote, this is a big +1 from me and a hope that this will calm down
internals list going forward after what has happened this past week.

--=20
Arv=C4=ABds Godjuks

+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

--0000000000000207290580ebf750--