Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104005
MIME-Version: 1.0
References: <03f401d4b96b$18b9dc60$4a2d9520$@php.net> <CAJHtznxq_i3t+sQ9mqxNP8HWLG19Y7RT6cF-XkrOFR9ej30wxw@mail.gmail.com>
 <CAPKYkKy3LeiBb8whBpcXS-4NHQMKu7Ci=-yAQprbmzJN4Rxszg@mail.gmail.com> <2455870.Alx54tMJ86@vulcan>
In-Reply-To: <2455870.Alx54tMJ86@vulcan>
Date: Sat, 2 Feb 2019 03:11:40 +0200
Message-ID: <CAJW__o0BxHuVnMt_PkDsaD=A1C2HhzcKaYS6frRuYMRYUCJKsw@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)
From: kalle@php.net (Kalle Sommer Nielsen)

Den fre. 1. feb. 2019 kl. 02.42 skrev Larry Garfield <larry@garfieldtech.com>:
> Disclosure: I am a long-time member of PHP-FIG, but I am NOT speaking on
> behalf of FIG in this post, only for myself.
>
> As Zeev noted, I think it's very good to have some mechanism for formal
> involvement from people who aren't C coders.  Currently, in order to vote
> (have a direct impact) you need to be a C developer; you technically don't
> need to even know how to write PHP, just C. :-)  That's a very different
> mindset and perspective than people who write PHP all day, and both are
> valuable.  The PHP community is much, much larger than the PHP Internals C
> developer community.
>
> At the same time, I fully agree with Kalle and Johannes that it would be a
> very bad idea for the Internals/C developers to be "forced" to maintain
> something they think is a bad feature because the great unwashed masses (who
> by nature don't realize just how terrible an idea is for the parser, for
> instance) thought it was cool and trendy.  Yet the fact that the unwashed
> masses think something is useful is relevant and a point that should be
> considered.
>
>  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.

> Whether FIG is the best way to select that community-voter constituency I'm
> not sure.  Or rather... I don't see any alternative mechanism that wouldn't
> involve, essentially, replicating the work FIG has done to determine
> appropriate "leading members of the community at large".  So if tapping FIG
> isn't the preferred way, the alternative would involve, essentially,
> duplicating at least a large part of FIG's process.

Any project that would like a say in something related to PHP as a
language, should, much like yourself, contribute to discussions. We as
developers do listen to feedback and take that into account when
designing and implementing features for the language, as it is
naturally made for our users, we value that input a lot and I use that
often as a determining factor to whether or not I vote yes to an RFC,
and I'm certain that I'm not the only one that puts personal bias a
little to the side in that scenario.

> 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 moment we as The PHP Project collaborate with you as the FIG, it
means that we will be seen as promoting FIG, and therefore it means
there is a certain favoritism towards picking what the FIG does
because the PHP project collaborates with them, essentially not
allowing competing projects or initiatives to have a space there, or
it would mean we also would have to take them aboard etc. That is a
mess and something we should avoid and why we do not use others
packages and projects for building our own web infrastructure. We need
to be neutral and transparent as a project because of the scale that
is PHP.

> Another point there is that the RFC doesn't specify what "member of FIG"
> means.  FIG currently has 3 defined groups of people: Secretaries (3 people),
> the Core Committee (12 people), and Project Representatives (36 people at
> Zeev, which group is intended?
>
> To provide some insight (with a little over-simplification):
>
> * Project Representatives are appointed by their respective projects, and are
> usually but not always project leads.  The bar for membership is extremely
> low, by design, and most in practice most project representatives are inactive
> 99.99% of the time.
>
> * The Core Committee is elected by Project Representatives, and are at least
> moderately active, much of the time.  They're responsible for reviewing,
> tracking, and approving PSR proposals, and are supposed to be active
> generalist architects.
>
> * The Secretaries are elected by Project Representatives, and keep the
> machinery working but are not involved in spec development.  They're basically
> FIG's project managers.
>
> If there's a concern about adding 50 "outsiders" to the voting rolls, I would
> propose just inviting the 12 Core Committee members to vote.  They're already
> elected in an open process to represent/work for the PHP ecosystem as a whole,
> with an eye toward compatibility, consistency, and all the same kind of stuff
> that Internals cares about.  And 12 people would not pose a threat of
> overwhelming the direct contributors, especially as a handful of them are
> already Internals contributors anyway.

Should this insane idea of allowing FIG members to vote pass, does
that also mean that the ~175 members of PHP get an equal voting right
in line with a so called Core Committee member? I doubt that. Reading
the FIG personnel page, I can spot 4 members that currently have
voting right because of their contributions to the project. Should
this RFC pass without allowing outsiders to vote, that would most
likely be down to 2 (Sara and Lukas). Besides that I spot an
additional 5 project members that can already vote or have contributed
back to PHP by code, obviously I'm only a human so my memory with the
names may be vague but there is already a presence because those
people are contributors to PHP.

In theory you already got a large say in voting on an individual
basis, even if the contributions to PHP itself is sparse.

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.

What about when your Core Committee members change, that means we need
to change karma granted because your process changes? No thank you.

> (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.

> Any other selection process for outside voters would, I believe, essentially
> duplicate what FIG already does.  It's better to just outsource that selection
> process to a known entity.

Any presence from an outside group means we need to have a much
different process and a lot more political babble, which quite
frankly, most other Core Developers don't really care THAT much about
unlike the FIG. Something we shouldn't have a need for, despite (to
use your own word), chaotic, nature of how internals is at times. All
we want to is to write code and enjoy it like we have done for almost
25 years this year, while the internals is no longer the "closed
gentle mans club" as it was when I joined 11 years ago, it still is
quite distinct from other OSS projects and one of the reasons why I
personally stick around, as I like that spirit the project has, which
is why I'm very protective of that as I'm certain you must have
noticed.

> Again, I'm not speaking on behalf of FIG here in any way, so other FIG members
> may have their own views on the subject.
>
> --Larry Garfield



-- 
regards,

Kalle Sommer Nielsen
kalle@php.net