Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103957
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> <CAPKYkKy3LeiBb8whBpcXS-4NHQMKu7Ci=-yAQprbmzJN4Rxszg@mail.gmail.com>
In-Reply-To: <CAPKYkKy3LeiBb8whBpcXS-4NHQMKu7Ci=-yAQprbmzJN4Rxszg@mail.gmail.com>
Date: Thu, 31 Jan 2019 23:43:40 +0200
Message-ID: <CAJW__o0PoF0hPq5Sg8YzaLr5xBfqLyijNCZr9+dOpmnuNLzfiw@mail.gmail.com>
To: Chase Peeler <chasepeeler@gmail.com>
Cc: Zeev Suraski <zeev@php.net>, 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 tor. 31. jan. 2019 kl. 20.17 skrev Chase Peeler <chasepeeler@gmail.com>=
:
> I don't know if there is a good way to implement it, but I definitely thi=
nk there is value in some sort of voice being given to those that use PHP t=
o 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 do=
n't belong to that group) have a voice - I'm just wondering if that needs t=
o be defined in a more formal way. One statistic I just found says that alm=
ost 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.

I do believe that the right to vote is a privilege of actually
contributing to the project, which in our case is seen by code as we
are a scripting language project, I think that is a fair definition.

However I do believe that because it is also a privilege it should be
considered as something you earn by dedicating yourself to the
project, if you are dedicated to the project then I would assume (and
I'm certain that I speak for most core developers) when I say that
those voting for changes in PHP does it in PHP's best interest.
Because they understand the complications and impact changing things
have.

We can take an example by looking at some of the more recent change
proposals for PHP8 that goes to show that not a lot of thought about
the implications and effect changing a few functions may have. For
your open source framework that have lets say maybe 10.000 users, that
is not a big deal, but when you take that number and maybe multiply it
by 1.000 (or you can swap around the zeros), then the impact of which
we change things are set in a very different perspective. Okay we do
have procedures for how to deal with some of these things for what can
and can't go into a branch. My point here is that when you are apart
of the project and more or less integrated with it, you would also
understand the ramifications on a project of the scale.

I do not want this to sound unwelcoming or so at all, I would like
more to join the project and put effort into improving our code base.
However like Johannes said in a mail earlier in this thread, if the
maintainers (core developers) are overruled by a third party, then a
point they simply loose interest and stop contributing and the project
will begin to halt. I would feel that same way myself.

> Maybe the voice that we currently have in the form of being able to parti=
cipate in these discussions is enough. I'd be interested in knowing how oft=
en 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.

I think the AFUP did something rather interesting, which we could use
as a model; If you are not familiar with the AFUP (Association
Fran=C3=A7aise des Utilisateurs de PHP), then it is the french usergroup
for PHP. Every now and then, we used to get emails from a member of
their group that would post a small summary of their thoughts
regarding a certain RFC, whether they were infavor of it or not and
potential problems they see as userland.

That I believe could work much better, as in giving external projects
or organization a way to comment on an RFC (which I would hope more
would have done instead of just being silent) about the pros and cons.
As core developers we take comments and feedback (Yes we have heard
the striking feedback about the standard library) as close as we can
to make sure that we don't just do something that would literally
render a PHP based project unusable by a change we have done.

> Maybe instead of giving all members of PHP-FIG a vote, the RFC can be ame=
nded to specify that PHP related groups with a certain number of active mem=
bers are given a single vote. Or, instead of membership numbers, an applica=
tion process of some sort can be put in place for various groups to petitio=
n for representation. If accepted, that group is given a single vote. A com=
mittee can be put together that is in charge of addressing the applications=
.

Please no committee or more bureaucracy as it just makes everything so
much more political and complicated for no satisfying reason.

--=20
regards,

Kalle Sommer Nielsen
kalle@php.net