Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82854
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender)
Reply-To: <francois@php.net>
To: "'Rowan Collins'" <rowan.collins@gmail.com>,
	<internals@lists.php.net>
Date: Mon, 16 Feb 2015 16:31:15 +0100
Message-ID: <010b01d049fd$9a09a020$ce1ce060$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AdBJ8xEBEh4pMSRFSRGd7KWQY/mNGQ==
Content-Language: fr
Subject: Proposing [constructive] solutions (was: I quit)
From: francois@php.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=)

> De : Rowan Collins [mailto:rowan.collins@gmail.com]
>
> Saying "that's enough" isn't even a productive comment. Enough what?
> What is it you are asking to happen next?

Maybe an initiative to write an RFC about the rules we should follow =
when writing to the list. People who agree could show their support by a =
vote. The vote would never end and would just mean 'I agree and will try =
to follow these rules'. It probably already exists somewhere but =
refreshing it wouldn't be useless. It's purely symbolic but, once people =
explicitly show strong support, it becomes an opposable reference.

> - There is a lack of expertise at the core level of the code, so
> collaboration on each feature is low. RFCs tend to have a single
> sponsor, who has to see the whole process through to the end.

- One thing we can encourage, while indirect in this case, is writing =
more comments in code. With PHP 7, Sara's book is almost unusable and =
nobody will write another one soon. 'UPGRADING' and friends are fine but =
far from sufficient, especially for newcomers. The only solution I =
imagine is adding comments in the code. I know it is annoying when you =
don't have much time, but comments can be improved at any time. They can =
be written by the feature author, but also by other people, who needed a =
(too) long time to understand a feature, and write explanations to help =
followers. As an example, I spent some time understanding the =
multi-level architecture of str_[i]replace functions and added a lot of =
comments along with the patch I will propose. Actually, everywhere you =
spend time understanding what's going on, more comments are needed. =
That's really important because, today, the code contains almost no =
comments except function prototypes. That=E2=80=99s ant work and I am =
far from perfect about comments in my own code, but it can make a =
difference, especially making the project more attractive for newcomers =
(and we *need* new blood).

- We also can encourage co-authoring RFCs. People are used to work alone =
but it can change if there's a will. We can also find a set of skilled =
volunteers agreeing to give their opinion on RFCs before they're =
announced on the list. That's just an opinion but it can avoid the =
discussion going nowhere from the beginning.

> - The leadership of the language is left to consensus, so that when
> consensus cannot be reached, someone has to take on the role of =
mediator
> / chairman / leader for the feature, and try to push through a =
compromise.

I have no democratic solution for this. In the PHP spirit, as Zeev =
explained, if the RFC process doesn't bring a consensus before the vote, =
the discussion should stop and the RFC should be modified. Trying to =
push it to a 2/3 approval while people are fighting is =
counter-productive. In this regard, IMO (and I told her), Andrea should =
have withdrawn her RFC much sooner. It would have allowed to take more =
time for building the next one, and start a new discussion in a more =
constructive atmosphere. Upcoming feature freeze was probably the reason =
but the result is that we need to restart everything from scratch in a =
bitter atmosphere.

> - The RFC process traditionally has only one voting phase, with a
> Proof-Of-Concept patch completed, and voters expecting few
> implementation details to change. So a lot of time has to be committed
> to the details of a feature which might be outright rejected. It might
> be more efficient if the principle of a change, details such as =
syntax,
> and final implementation, could be considered separate phases.

That's the tradition but I think it is quite open for improvements. =
While we are traditionally using one final vote with multiple options, =
nothing refrains anyone to organize informative pre-votes during =
discussion to test the popularity of a feature before he starts writing =
code, clearly stating that it is not the final vote. This would allow a =
better information from the community to the RFC author. The interest of =
such running pre-votes is that they can contain many more options than =
the final vote and can be started and closed at anytime during =
discussion. The only requirement is that everyone understands that it in =
*not* the final vote.

Considering the final vote, that's normal to demand a proof of concept =
patch, as the feature implications are generally not clear (even in =
author's mind). But the final vote does not require the final PR to be =
completed. The same for documentation. You just need to prove that your =
future changes won't create side issues that couldn't be discussed. =
That's quite understandable and that's a point the scalar type hints RFC =
was failing because the vote would have ended with a lot of remaining =
open issues.

> - The internals list is quite high-volume, and the same points end up
> being raised multiple times, so a feature sponsor has to give the same
> counter-point or explanation each time.

That's the main issue to the RFC process, IMO, and I'd really favor =
switching to a more elaborate system. It was often said but it's a pity =
that a language like PHP, which runs so many high-level collaborative =
environments, uses such archaic tools for its own purpose. Github =
provides almost everything we need through issues =
(subscriptions/notifications, post edition, links to PRs and code =
blocks, and more), and only lacks an usable voting system. A lot of =
people are asking for it, but github is not very receptive at user's =
requests. Maybe we can use it and keep the final vote elsewhere, as the =
most important is the discussion. If everyone agrees, I can try writing =
my next RFC this way (a wiki page containing just metainfo and a link to =
the php-src github issue).

The mailing list should be restricted to questions and replies, =
announcing new RFCs, and general discussion about PHP internals. As soon =
as an RFC is published, it should evolve in its own space, and people =
interested in the subject would explicitely subscribe to the discussion. =
Even the vote should ideally take place only among subscribed people as =
there is no reason for someone who did not follow the discussion to =
participate in the final vote (but it will remain open).

> Most of these don't have easy solutions, but hopefully they're =
specific
> enough points that we can come up with some concrete ideas on how to
> improve things.

This post is way too long but that's just ideas. If you think some may =
be worth starting a separate thread, just tell me.

Regards

Fran=C3=A7ois