Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104067
To: internals@lists.php.net
Date: Sun, 03 Feb 2019 11:29:30 -0600
Message-ID: <2083237.emE2DNI856@vulcan>
In-Reply-To: <CAJW__o0BxHuVnMt_PkDsaD=A1C2HhzcKaYS6frRuYMRYUCJKsw@mail.gmail.com>
References: <03f401d4b96b$18b9dc60$4a2d9520$@php.net> <2455870.Alx54tMJ86@vulcan> <CAJW__o0BxHuVnMt_PkDsaD=A1C2HhzcKaYS6frRuYMRYUCJKsw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart9750032.0VYkfKEO3J"; micalg="pgp-sha512"; protocol="application/pgp-signature"
Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)
From: larry@garfieldtech.com (Larry Garfield)

--nextPart9750032.0VYkfKEO3J
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Friday, February 1, 2019 7:11:40 PM CST Kalle Sommer Nielsen wrote:
> Den fre. 1. feb. 2019 kl. 02.42 skrev Larry Garfield 

> > >  So I would support a mechanism of some sort to give formal voting 
rights
> >  to
> > non-internals-C-developers who are still significant-PHP-contributors, as
> > long 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 doubt vary but let's assume stays in vaguely the same
> > range), an "at large voter" population of 5, 10, or 15 people would
> > provide direct representation without a meaningful risk of swamping the
> > direct contributors, who I agree should remain the overwhelming majority
> > of eligible voters.
> 
> So while you fully agree with its a bad idea that us the Core
> Developers have to maintain code that is decided by external, non
> contributing parties, still you think there should be a way for non
> Core Developers to vote? That is kinda absurd.

It's not absurd, it's a matter of degrees.  As Zeev noted in a later email, 
the current voting RFC already calls for some voting-level input from "major 
customers", but not a controlling vote.

To use hyperbolic examples: 

Would adding one single non-C-developer to the voting rolls mean that "the 
Core Developers have to maintain code that is decided by external, non 
contributing parties"?  No, that's "kinda absurd" to call it that, because 
that one voter is clearly swamped out by  the many other Internals developers 
that are also voting.

Would adding 200 non-C developers to the voting roll mean that?  Certainly 
yes, that would be an absurd situation.  But no one that I've seen is 
suggesting that at all, or anything close to it.

What's the threshold of absurdity here?  That we could debate.  However, it is 
not 0.  (I'd personally put it in the 10-20 range, bearing in mind that not 
all of them would vote all the time anyway, just like core developers, but 
others may feel differently.)


> > This would be the first formal recognition of FIG by PHP Internals.  I am
> > completely OK with that, and personally would love to see Internals and
> > FIG
> > collaborate more; I'm just noting it for completeness.
> 
> I'm not okay with that at all. I accept and respect what you as a
> project do, but because of that it doesn't mean you (you as in a
> project) should have a special right over our project because you
> represent some of the most used userland projects. Besides the very
> high profile projects like Laravel and Symfony (even projects like
> Doctrine and Guzzle) is no longer represented, WordPress is not even a
> part of the FIG.

The degree to which "participation in a big name project" correlates or has a 
causal relationship with "is a significant voice and influencer in the 
community" is a contentious question, and one that FIG has debated for years.  
Without going too far down that rabbit hole I will only say "it's very 
complicated" and not cut and dry either direction.

> Given the volume of people who currently votes on RFCs on average,
> that would literally mean that we would increase our average voting
> pool by 25%, something to consider as by then the FIG would
> essentially sit with about a 20% say in whether or not something
> should go in and their hands will stay clean because we as maintainers
> will have to do the dirty work and that is without projects like
> Laravel, Symfony and WordPress having a say, just the FIG.

To answer both you and Sanislav here together, as he raised a similar point, 
that presumes that 100% of the "invited outsiders" vote on every RFC.  I think 
that is unlikely, although I freely admit I have no real data to speculate 
either way.  Lacking any other evidence I'd say it would probably follow a 
similar pattern to Internals day.  (If we assume a 175 person voting pool and 
a turnout of about 50, then that's in the neighborhood of 25-30%.)  
Truthfully, though, none of us have any idea what the total impact would be.

That same point applies to any "invited outsiders", whether that's done 
through FIG or otherwise.  Per Zeev's email, it does seem like some mechanism 
for invited-outsiders was always intended, even if it never materialized.

> > (Disclosure: I am a member of the Core Committee so that would include me;
> > I hope that doesn't itself turn anyone off of the idea :-), but I mention
> > it for transparency and feel it would be a good approach even if I
> > weren't.)

> That itself worries me, because you are represent a part of the
> community using the language, but you are not a language designer. You
> are active with input on internals and RFCs etc, which I respect a
> lot, but without any interest in actually writing code (I can't really
> say if its true or not regarding the interest or its because of C
> know-how) or because of time schedules like we all have, I don't see
> why a special exception should be granted. No offense.

To clarify: I last wrote C code in 2004 for Palm OS.  I am quite rusty; on top 
of that I know just enough about Internals to say that it's not as much 
written in C as it is in a macro language built in C, so the learning curve 
would be rather high.  My personal lack of involvement in actual Internals 
code is mainly because the logistical barrier to re-learning enough tooling 
and language to do so is too high given that I have no professional 
justification for it.  I try to contribute to the PHP ecosystem in other ways 
instead, internals or otherwise.

Whether or not I am personally impacted, though, I do feel and have long felt 
that a more direct mechanism for user-land developers to have some influence 
on PHP would be beneficial.  (Though, yes, considerably less than the direct 
contributors working on the code base, who should still be the predominant 
constituency.)

--Larry Garfield
--nextPart9750032.0VYkfKEO3J
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/GXfY8v0YwFBp4MMKwDFxYXcFAlxXJPoACgkQ4MMKwDFx
YXc35QgAgBycJGNC/cLUBmF2KYiZrWFs+omqAtGcWqsK1Kun5cEeAjuYdk9dBPZy
qUfpvZYErKBe3FYuLlVNWLVG3yd1v3nglG1fXi9slQIwXsllkNSf0g7nkUWQxvnx
thMGQtU/T6KTz9ca6hsAG77dJfPW1WkCRAkXhanS8IHc5cqQgC9hfIU4H3XEV5e6
tN5IRucZvtWDGasEVYCKQGpBuMRLfgteon8DjTi6rLkdHlQ1CQPjJ7UZ4Ma4WGVi
NFbf7a85y6SulssHCZfsxF94Nt68P4wROSEHxWKlrPKfQMkYwx4d/K/q+2jEjNU2
Sxvsud3l2EhefcGPgehVBNwgI5JTWw==
=YQYm
-----END PGP SIGNATURE-----

--nextPart9750032.0VYkfKEO3J--