Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104000
MIME-Version: 1.0
References: <03f401d4b96b$18b9dc60$4a2d9520$@php.net>
In-Reply-To: <03f401d4b96b$18b9dc60$4a2d9520$@php.net>
Date: Fri, 1 Feb 2019 19:03:36 +0000
Message-ID: <CAJd4=YbDFNawBe_aUpEh7opOaQHyJGyTNihdms3nAqSesEx47g@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005b6c530580d9cd27"
Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)
From: mail@pmmaga.net (=?UTF-8?Q?Pedro_Magalh=C3=A3es?=)

--0000000000005b6c530580d9cd27
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

Regarding the definitions of what constitutes a Change, a Packaging
Decision and an Implementation Decision, I think it does a better job than
the current voting RFC but IMHO it still is over-complicated. Trying to
specify which changes are which just for the sake of allowing some things
to pass with a slim majority seems a wasted effort to me. As "proven" by
the currently open issues, it also misses a categorization for
administrative changes. Stating only which changes require a RFC and which
don't would be much simpler. Also, that last part about performance
degradation will also lead to unnecessary discussion if it isn't more
clearly defined (is it just the bench.php? mediawiki test suite?).

On the section about Changing the RFC, again a distinction is made between
extending the period for 1 or 2 weeks depending on what you subjectively
consider "substantial". For the sake of simplicity, I'd suggest it to be
always 1 week.

About No Discussion/Voting Periods, I think it would be simpler to just
extend the voting period to a minimum of 2 weeks. For anyone interested on
the subject, they would have 4 weeks to find out about it (2 for discussion
and 2 for voting). Maybe some people actually have more time to
contribute/participate in discussion during their holidays.

As stated before, The Eligible Voters section fails to mention its reason
to be. Lately, RFCs get around 20 to 40 votes, why do we have to reduce the
list of potential voters? To me, it seems arbitrarily hostile to newcomers
while overly protective of people that have long lost interest. In other
words, someone who has made their last contribution 10 years ago keeps
their vote while someone who fixed a bug every 2 weeks for the last year
isn't eligible. Also, the proposed measurements are subject to be "gamed"
(not squashing your commits, changes to license headers, etc..). And for
other members of the project the same problem poses, how do you measure
docs contributions? And maintaining the servers? And PECL extension
maintainers?
About FIG, it is an organization which has its own membership rules that
are subject to change at any time at its own discretion. While I truly
believe that it would be very important to provide a way to allow the users
to express their voice, doing that via an external organization doesn't
seem acceptable. Keep in mind that the current voting RFC keeps the
decision of which community members can vote in PHP's side.
To cater to an even larger audience, there could be a section on RFCs where
anyone could cast their vote so that the RFC author can also take it into
consideration but keeping it non-binding. (Or perhaps giving it a
predefined weight - 1, 3, 5 votes?)

Regards,
Pedro

On Thu, Jan 31, 2019 at 1:44 PM Zeev Suraski <zeev@php.net> wrote:

> Without further ado, an RFC that=E2=80=99s attempting to comprehensively =
solve
> many of the issues that have plagued our RFC process since it was hastily
> introduced in 2011:
>
>
>
> https://wiki.php.net/rfc/voting2019
>
>
>
> Emphasis on =E2=80=98attempting=E2=80=99.  I=E2=80=99m sure there are sti=
ll a lot of holes in it
> that should be plugged before we vote on it, but instead of waiting
> indefinitely =E2=80=93 I=E2=80=99d like us to start discussing it.
>
>
>
> Comments and suggestions welcome.
>
>
>
> Zeev
>
>
>
>
>
>

--0000000000005b6c530580d9cd27--