Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104145
MIME-Version: 1.0
References: <03f401d4b96b$18b9dc60$4a2d9520$@php.net> <2455870.Alx54tMJ86@vulcan>
 <CAJW__o0BxHuVnMt_PkDsaD=A1C2HhzcKaYS6frRuYMRYUCJKsw@mail.gmail.com> <2083237.emE2DNI856@vulcan>
In-Reply-To: <2083237.emE2DNI856@vulcan>
Date: Tue, 5 Feb 2019 00:59:19 +0200
Message-ID: <CAJW__o0ELnHtGVAeD3z-nH4ssTeSJDvo3QC5QmyFRgNR3_rgjQ@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)
From: kalle@php.net (Kalle Sommer Nielsen)

Den s=C3=B8n. 3. feb. 2019 kl. 19.29 skrev Larry Garfield <larry@garfieldte=
ch.com>:
>
> It's not absurd, it's a matter of degrees.  As Zeev noted in a later emai=
l,
> the current voting RFC already calls for some voting-level input from "ma=
jor
> customers", but not a controlling vote.
> To use hyperbolic examples:
>
> Would adding one single non-C-developer to the voting rolls mean that "th=
e
> Core Developers have to maintain code that is decided by external, non
> contributing parties"?  No, that's "kinda absurd" to call it that, becaus=
e
> that one voter is clearly swamped out by  the many other Internals develo=
pers
> that are also voting.

You and I both know the average turn-out of people voting here on
RFCs, that I do not doubt you follow in anyway and then you know that
if we add that top plus additional projects not represented under the
FIG, then that is a large deciding factor and don't tell me that
everyone who could get the ability by getting a vote won't be doing so
for at least the first long while. I do believe it will decrease over
time yes, but anytime soon if it passes.

> Would adding 200 non-C developers to the voting roll mean that?  Certainl=
y
> yes, that would be an absurd situation.  But no one that I've seen is
> suggesting that at all, or anything close to it.

There has to a limit. Whether it is 1 or 200 or even 1000 doesn't
matter. As long as it is more than 0 externals that has a direct
deciding factor for a change. There is a fine line whether a non
project member should have a say in the voting which is apart of our
project management over actively listening and engaging with the
community and taking that feedback into shaping PHP. The line I'm
trying to write here in bold is that having a say doesn't mean voting
power by any means.

If you as userland believes that we as the language project do not
include your feedback, then let's have a discussion about that in a
thread and look at how we can make a more engaging and open way to
actively work on what the community would want to see coming into PHP.
I do not believe influence should be linked to voting power within the
project by any means, that is one of my main arguments against this.

> 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 n=
ot
> all of them would vote all the time anyway, just like core developers, bu=
t
> others may feel differently.)

As long as a non project contributor, as have the power in the form of
being able to vote and therefore directly affect the active ones. That
is my threshold of absurdity and in a way I'm baffled that you do not
seem to understand that.

> To answer both you and Sanislav here together, as he raised a similar poi=
nt,
> 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 speculat=
e
> 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.

As a continuation of my answer above to this one; By looking at the
average turnout of people voting as it is now, there is a 50%+ of
people with just doc karma in one way or another (single translation),
just PEAR or even some without any form of karma voting. Looking at
the list of the 175 or so posted, it is a very small margin of those
on average that votes for RFCs, meaning that adding externals to the
top of that, that number in my original email is gonna be a lot larger
and therefore a lot more dangerous if we open the floodgates like
that.

> 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 mecha=
nism
> for invited-outsiders was always intended, even if it never materialized.

Back then I was also against that, and I'm happy it didn't materialize
further on the voting aspect. This gives us a chance to clean this
system up and streamline the processes.

> To clarify: I last wrote C code in 2004 for Palm OS.  I am quite rusty; o=
n 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 cur=
ve
> would be rather high.  My personal lack of involvement in actual Internal=
s
> code is mainly because the logistical barrier to re-learning enough tooli=
ng
> 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 influe=
nce
> on PHP would be beneficial.  (Though, yes, considerably less than the dir=
ect
> contributors working on the code base, who should still be the predominan=
t
> constituency.)

That I do agree with. But like I mention above in the reply, I do not
believe that influence should be on the behalf of voting power. The
PHP community is large, exceptionally large and while I wish there
were ways was more open for developers to join the "conversation", I
do not see how we can start tackling that, which itself is perhaps a
topic for another thread on its own.



--=20
regards,

Kalle Sommer Nielsen
kalle@php.net