Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103928
MIME-Version: 1.0
References: <03f401d4b96b$18b9dc60$4a2d9520$@php.net> <CAJW__o1q3e1+1DoFVE3dpUdn=f-AnPHuVXpM+6jruQYYrJ6PSQ@mail.gmail.com>
In-Reply-To: <CAJW__o1q3e1+1DoFVE3dpUdn=f-AnPHuVXpM+6jruQYYrJ6PSQ@mail.gmail.com>
Date: Thu, 31 Jan 2019 08:03:18 -0800
Message-ID: <CAKOpQSzQiEp7G9uvEYq_RnUFyy0bDaOZ8qBqR1OiAGTcQ-TXOA@mail.gmail.com>
To: Kalle Sommer Nielsen <kalle@php.net>
Cc: Zeev Suraski <zeev@php.net>, PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f6def40580c32a7d"
Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)
From: kris.craig@gmail.com (Kris Craig)

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

On Thu, Jan 31, 2019, 7:58 AM Kalle Sommer Nielsen <kalle@php.net wrote:

> Hi Zeev
>
> Den tor. 31. jan. 2019 kl. 15.44 skrev Zeev Suraski <zeev@php.net>:
> >
> > Without further ado, an RFC that=E2=80=99s attempting to comprehensivel=
y solve
> many of the issues that have plagued our RFC process since it was hastily
> introduced in 2011:
> >
> >
> >
> > https://wiki.php.net/rfc/voting2019
>
> I wholeheartedly disagree with the PHP-FIG special exception to who
> can vote, call me biased but I do not believe it serves any purpose
> and is absurd. People who actively work on PHP, should be the ones to
> be able to have a choice, I think that should be reserved for any
> contributor who puts effort working on PHP.
>
> I do understand that we are the language and our work affects the
> others the most. However making special exceptions for who can vote
> and essentially having a say from an external source in what I in
> theory need to help maintain as a PHP Core Developer is terrible. Why
> not allow WordPress Core Developers to have a say instead, as their
> work has a larger impact on the usage of PHP? (That was obviously a
> bit of sarcasm, the last part). We are not allowed to vote at their
> individual projects features (nor do we need to have a say if we are
> not actively involved in the development of said projects or
> organizations) and I stand very strongly behind that belief.
>
> Besides this, it also creates uncertainty about who elects such, and
> simply should be dropped from the voting RFC as it was already fairly
> unclear from the original one.
>
> The contributors appendix also lists ChangeLog, SVN Migration etc,
> something to keep in mind if this RFC is moved forward to filter the
> list.
>
>
> Do I understand the PHP Packaging Decisions right that it requires to
> vote for a timeline for each version? I remember we have different
> opinions raised regarding the time to a new major version (should we
> have 7.4 vs go to 8.0, same for the 5 to 7 transition back then
> regarding a 5.7). This is the only issue I can think of and should be
> changed to requiring a vote if there is a dispute in regards to what
> the next version should be. As I don't really wanna vote just to vote
> for each of the minor versions of 8 once a year when its the most
> logical reason to go to 8.1 from 8.0, and so on until we reach the
> point where the next major is considerable.
>
>
> I think changes like the requiring a patch for RFCs is a very welcomed
> addition.
>
> --
> regards,
>
> Kalle Sommer Nielsen
> kalle@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


Given how complex and controversial this question of restricting who can
vote is, I propose that it be moved to its own RFC instead of being bundled
with this one.  It would certainly boost likelihood of passage, if nothing
else, as there are a lot of good ideas in this RFC.

--Kris

>
>

--000000000000f6def40580c32a7d--