Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103945
MIME-Version: 1.0
References: <03f401d4b96b$18b9dc60$4a2d9520$@php.net> <CAJW__o1q3e1+1DoFVE3dpUdn=f-AnPHuVXpM+6jruQYYrJ6PSQ@mail.gmail.com>
 <CAJHtznxq_i3t+sQ9mqxNP8HWLG19Y7RT6cF-XkrOFR9ej30wxw@mail.gmail.com>
In-Reply-To: <CAJHtznxq_i3t+sQ9mqxNP8HWLG19Y7RT6cF-XkrOFR9ej30wxw@mail.gmail.com>
Date: Thu, 31 Jan 2019 13:17:02 -0500
Message-ID: <CAPKYkKy3LeiBb8whBpcXS-4NHQMKu7Ci=-yAQprbmzJN4Rxszg@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: Kalle Sommer Nielsen <kalle@php.net>, Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002c7bfc0580c509ca"
Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)
From: chasepeeler@gmail.com (Chase Peeler)

--0000000000002c7bfc0580c509ca
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 31, 2019 at 11:52 AM Zeev Suraski <zeev@php.net> wrote:

> On Thu, Jan 31, 2019 at 5:58 PM 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 comprehensiv=
ely solve
> > many of the issues that have plagued our RFC process since it was hasti=
ly
> > 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.
> >
>
> That's a very fair point.  I'm personally undecided on this.  It's fair t=
o
> say that in 2011, my thinking was that voting rights should be given pret=
ty
> much exclusively to contributors.  It may sound like overreaching, but th=
e
> reality is that this is pretty much how ALL open source projects work (an=
d
> have been working).  The reason it sounds overreaching, is that over the
> several years following the ratification of the 2011 Voting RFC - a statu=
s
> quo of "virtually anybody can vote" took hold, and it's now fairly
> entrenched in people's minds.  It's still very, very awkward when taken i=
n
> the context of how OS projects behave in general.
> The thinking behind PHP-FIG (and for that matter, having some
> representation from WordPress, yes, I'm not kidding...) was to create
> something which goes a bit farther than what's usual in an OS project -
> because of the status quo we have today.  Making it a bit easier to
> digest.  But it may be that it's the wrong approach.  I'll be interested =
to
> see what others think about it as well.  I'm personally open both for
> extending that list further - or potentially trimming it down - making it
> more of a meritocracy, as is customary in virtually all other OS projects=
.
>
> I don't know if there is a good way to implement it, but I definitely
think there is value in some sort of voice being given to those that use
PHP to build things, but don't contribute to the actual source.

I think it's important, though, to make sure that developers that are out
there actually developing things with PHP (not to say that contributors
don't belong to that group) have a voice - I'm just wondering if that needs
to be defined in a more formal way. One statistic I just found says that
almost 6 million websites are running PHP7. Even if we assume that it
averages out to where there is 1 developer for every 100 sites, that's
still 60,000 developers being represented by 175 voters.

Maybe the voice that we currently have in the form of being able to
participate in these discussions is enough. I'd be interested in knowing
how often voters are persuaded to take a position on an issue after
discussing it with non-voting developers - whether via these discussion
lists or on other mediums.

Maybe instead of giving all members of PHP-FIG a vote, the RFC can be
amended to specify that PHP related groups with a certain number of active
members are given a single vote. Or, instead of membership numbers, an
application process of some sort can be put in place for various groups to
petition for representation. If accepted, that group is given a single
vote. A committee can be put together that is in charge of addressing the
applications.


> > 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 agree.  I'll look at the text and clarify it as needed.  Of course it
> makes no sense to have to vote on every version from scratch every time.
>
>
> > I think changes like the requiring a patch for RFCs is a very welcomed
> > addition.
> >
>
> Thanks for the feedback!
>
> Zeev
>
--=20
-- Chase
chasepeeler@gmail.com

--0000000000002c7bfc0580c509ca--