Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115882
MIME-Version: 1.0
References: <CADK1yXLZzoOjjNcpZ5ZtV9kSNgw4=SW9G74o26eLdAYV5cDzAQ@mail.gmail.com>
 <CAEZPtU5STkockXmwYBQi0kd+rBtNkb9Z4UwvxMe7ozRSDTm8Ew@mail.gmail.com>
 <CAMrTa2EWdH5TrUU5R3fpkuDC_xmvfjMkwNhzOm=3EQucyrE1ZA@mail.gmail.com>
 <CAEZPtU65=Yfe-oQzxjDnYvccsrMLf9_cj9G6m8fKKEGELB=XDw@mail.gmail.com>
 <CA+kxMuSq5WZCk-0R0eN6e0vfFAiD_Jr8pKMbBFyx1zJrDD8Z-w@mail.gmail.com> <CAEZPtU5hfDLP7i5L4Nr0BM39O+brnLVWefe+QGfMRdvrNGc9vQ@mail.gmail.com>
In-Reply-To: <CAEZPtU5hfDLP7i5L4Nr0BM39O+brnLVWefe+QGfMRdvrNGc9vQ@mail.gmail.com>
Date: Fri, 27 Aug 2021 18:39:32 +0100
Message-ID: <CA+kxMuTPzdBuVDQG_86CyfVjKMtnOarKWgDa5PfoMrWER_GFKA@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: tobias.nyholm@gmail.com, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Guidelines for RFC post feature-freeze
From: Danack@basereality.com (Dan Ackroyd)

On Tue, 24 Aug 2021 at 20:02, Pierre Joye <pierre.php@gmail.com> wrote:
>
> good evening Dan,
>
> First of all, could you please not merge  many different mails in one single reply? Thanks.

No. This is a mailing list, where conversations get spread over
different forks of threads.

When a reply is relevant to multiple previous messages, it's better to
combine them so people can see a complete message at once, rather than
expecting people to read through multiple messages in the correct
order, to understand what I'm saying.

> PHP is not at a stage where what
> is missing are easy additions like simple scalar return types.

First, "simple scalar return types" was not an RFC, that is at least
two RFCs or three:

Return Type Declarations - https://wiki.php.net/rfc/return_types - 2014-03-20
Nullable Types - https://wiki.php.net/rfc/nullable_types - 2014-04-10
Scalar Type Declarations -
https://wiki.php.net/rfc/scalar_type_hints_v5 - 2015-02-18

To me, this is a good example of how breaking large chunks of work is
an effective strategy.

Second, you are either completely forgetting or just denigrating the
amount of work that was involved in getting scalar types passed. It
was a shitshow of a discussion that took a huge amount of effort to
get passed.

Coming up with the technical details and implementing an RFC are only
part of the process, and are the fun bit. But then after that any RFC
author has to persuade the rest of PHP internals that it's a good
idea.

I talk to some of the people who do RFCs and one of the common things
I hear is that listening to internals feedback is a hugely stressful
and difficult thing to do.

This may be different to when you last passed an RFC, at least in part
because there are now relatively more people who don't commit to
PHP-src frequently (or at all) taking part in discussions, and so RFC
authors find it really hard to figure out which feedback should be
listened to, and which feedback is less relevant.

Although listening to user feedback can be useful, there is a lack of
detailed technical feedback and help in implementing RFCs.

> As the recent discussions show, it needs more time to design,
> plan and implement the desired additions.

Just saying people should work harder doesn't help. I'll agree that
the project would be in a better place if there were more people
making technical contributions but PHP is worked on by volunteers.

But just having people show up after RFCs have been passed, and say
"the work done isn't good enough" is completely disrespectful to the
people who have been maintaining and improving PHP.

I don't think a more difficult process is what the PHP project needs.
Instead it needs more people able to, and willing to work on the code.
One thing that might help with that is getting more sponsoring of
people who have done work.

I've made a list of RFC authors here:
https://phpopendocs.com/sponsoring/internals

sincerely
Dan
Ack