Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103962
To: internals@lists.php.net
Date: Thu, 31 Jan 2019 18:42:21 -0600
Message-ID: <2455870.Alx54tMJ86@vulcan>
In-Reply-To: <CAPKYkKy3LeiBb8whBpcXS-4NHQMKu7Ci=-yAQprbmzJN4Rxszg@mail.gmail.com>
References: <03f401d4b96b$18b9dc60$4a2d9520$@php.net> <CAJHtznxq_i3t+sQ9mqxNP8HWLG19Y7RT6cF-XkrOFR9ej30wxw@mail.gmail.com> <CAPKYkKy3LeiBb8whBpcXS-4NHQMKu7Ci=-yAQprbmzJN4Rxszg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2594318.7voVjqcdeJ"; micalg="pgp-sha512"; protocol="application/pgp-signature"
Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)
From: larry@garfieldtech.com (Larry Garfield)

--nextPart2594318.7voVjqcdeJ
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Thursday, January 31, 2019 12:17:02 PM CST Chase Peeler wrote:
> 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>
> >=20
> > wrote:
> > > Hi Zeev
> > >=20
> > > 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 comprehens=
ively solve
> > >=20
> > > many of the issues that have plagued our RFC process since it was
> > > hastily
> > >=20
> > > introduced in 2011:
> > > > https://wiki.php.net/rfc/voting2019
> > >=20
> > > 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.
> > >=20
> > > 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.
> >=20
> > That's a very fair point.  I'm personally undecided on this.  It's fair=
 to
> > say that in 2011, my thinking was that voting rights should be given
> > pretty
> > much exclusively to contributors.  It may sound like overreaching, but =
the
> > reality is that this is pretty much how ALL open source projects work (=
and
> > have been working).  The reason it sounds overreaching, is that over the
> > several years following the ratification of the 2011 Voting RFC - a sta=
tus
> > 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=
 in
> > 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 projec=
ts.
> >=20
> > I don't know if there is a good way to implement it, but I definitely
>=20
> 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.
>=20
> 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 nee=
ds
> 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.
>=20
> 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.
>=20
> 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.


Disclosure: I am a long-time member of PHP-FIG, but I am NOT speaking on=20
behalf of FIG in this post, only for myself.

As Zeev noted, I think it's very good to have some mechanism for formal=20
involvement from people who aren't C coders.  Currently, in order to vote=20
(have a direct impact) you need to be a C developer; you technically don't=
=20
need to even know how to write PHP, just C. :-)  That's a very different=20
mindset and perspective than people who write PHP all day, and both are=20
valuable.  The PHP community is much, much larger than the PHP Internals C=
=20
developer community.

At the same time, I fully agree with Kalle and Johannes that it would be a=
=20
very bad idea for the Internals/C developers to be "forced" to maintain=20
something they think is a bad feature because the great unwashed masses (wh=
o=20
by nature don't realize just how terrible an idea is for the parser, for=20
instance) thought it was cool and trendy.  Yet the fact that the unwashed=20
masses think something is useful is relevant and a point that should be=20
considered.

 So I would support a mechanism of some sort to give formal voting rights t=
o=20
non-internals-C-developers who are still significant-PHP-contributors, as l=
ong=20
as the number of people involved is relatively low compared to the direct-
contributor number.  With a contributor voting pool of ~175 (which would no=
=20
doubt vary but let's assume stays in vaguely the same range), an "at large=
=20
voter" population of 5, 10, or 15 people would provide direct representatio=
n=20
without a meaningful risk of swamping the direct contributors, who I agree=
=20
should remain the overwhelming majority of eligible voters.

Whether FIG is the best way to select that community-voter constituency I'm=
=20
not sure.  Or rather... I don't see any alternative mechanism that wouldn't=
=20
involve, essentially, replicating the work FIG has done to determine=20
appropriate "leading members of the community at large".  So if tapping FIG=
=20
isn't the preferred way, the alternative would involve, essentially,=20
duplicating at least a large part of FIG's process.

This would be the first formal recognition of FIG by PHP Internals.  I am=20
completely OK with that, and personally would love to see Internals and FIG=
=20
collaborate more; I'm just noting it for completeness.

Another point there is that the RFC doesn't specify what "member of FIG"=20
means.  FIG currently has 3 defined groups of people: Secretaries (3 people=
),=20
the Core Committee (12 people), and Project Representatives (36 people at=20
Zeev, which group is intended?

To provide some insight (with a little over-simplification):

* Project Representatives are appointed by their respective projects, and a=
re=20
usually but not always project leads.  The bar for membership is extremely=
=20
low, by design, and most in practice most project representatives are inact=
ive=20
99.99% of the time.

* The Core Committee is elected by Project Representatives, and are at leas=
t=20
moderately active, much of the time.  They're responsible for reviewing,=20
tracking, and approving PSR proposals, and are supposed to be active=20
generalist architects.

* The Secretaries are elected by Project Representatives, and keep the=20
machinery working but are not involved in spec development.  They're basica=
lly=20
=46IG's project managers.

If there's a concern about adding 50 "outsiders" to the voting rolls, I wou=
ld=20
propose just inviting the 12 Core Committee members to vote.  They're alrea=
dy=20
elected in an open process to represent/work for the PHP ecosystem as a who=
le,=20
with an eye toward compatibility, consistency, and all the same kind of stu=
ff=20
that Internals cares about.  And 12 people would not pose a threat of=20
overwhelming the direct contributors, especially as a handful of them are=20
already Internals contributors anyway.

(Disclosure: I am a member of the Core Committee so that would include me; =
I=20
hope that doesn't itself turn anyone off of the idea :-), but I mention it =
for=20
transparency and feel it would be a good approach even if I weren't.)

Any other selection process for outside voters would, I believe, essentiall=
y=20
duplicate what FIG already does.  It's better to just outsource that select=
ion=20
process to a known entity.

Again, I'm not speaking on behalf of FIG here in any way, so other FIG memb=
ers=20
may have their own views on the subject.

=2D-Larry Garfield
--nextPart2594318.7voVjqcdeJ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEE/ph/GXfY8v0YwFBp4MMKwDFxYXcFAlxTle0ACgkQ4MMKwDFx
YXdcSwgA1XTszSGGC19xruITLgzmD2E4CBcFDzfCUeO8jF3vySOlhFUXPQr5K1X6
jiuwc5it2KdcnhTHYWHa1fK9I27P76++9xc4GSgoCLcbUTT1P1sp0F+C9KzSsA0I
XjvFSlx7HcpgnEJvxpsMGIQgmeXKP8qTB8fHXU8Wl25ZqOqCbbaACvWuozdEpXnB
3YjgsoifH1GG9DIpWOUhxfyjmXybwxsGsfo95Qv9OlM4MGix0jFIyzFKD5Nh5pjM
nUPyQx8vn7Exov7GeSSX4Q73XIRNBcIysjwOjn6vQh20A+t5g6vgwUzxmbbyFU9f
vLUpzFLt8E2uLQWtY1U5VGdOvi6sCw==
=tiiL
-----END PGP SIGNATURE-----

--nextPart2594318.7voVjqcdeJ--