Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109155
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <17a8b468-e863-c528-3596-23dc4c60ddab@gmail.com>
Date: Thu, 19 Mar 2020 17:25:39 -0400
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <BFDD4CDB-7241-405E-B130-7CE2D2E75A14@newclarity.net>
References: <14383D05-EA33-4CD2-9648-40AA29A837A5@newclarity.net>
 <CA+kxMuRkCZjWbuR1yrw8KxcM20ZxZ-7Zu8s=RAxbspLkGsjO=Q@mail.gmail.com>
 <2AE639B7-7775-48CC-8435-2F455D429E6A@newclarity.net>
 <17a8b468-e863-c528-3596-23dc4c60ddab@gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] Capturing reasons for votes for historical sake?
From: mike@newclarity.net (Mike Schinkel)

> On Mar 19, 2020, at 4:46 PM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> Hi Mike,
>=20
> On 17/03/2020 03:01, Mike Schinkel wrote:
>> Currently it takes herculean effort to get almost anything approved, =
but it takes effectively zero effort to stifle the hard work someone =
invests in trying to improve PHP. Is it really just that all their work =
can be nullified by a simple thumbs down like an emperor deciding the =
death of a gladiator? (sorry, couldn't resist using that analogy. ;-)
>>=20
>> BTW, I am thinking of the outrageous amount of work Paul M Jones is =
putting into Server-Side Request and Response Objects (v2) and fear for =
him that all his effort will be for naught, and he won't even have a =
concise list of reasons why it was voted down. The best he will be able =
to do is infer from the comments in thousands of the messages why people =
voted down. But he still won't know.
>=20
>=20
> I wanted to pull this point out from further up the thread, because I =
think it's a very real concern, but I think it's about something more =
fundamental than how people vote.
>=20
> Large RFCs, where there's significant implementation work, are =
essentially software projects. If we ran them that way, we'd all =
collaborate on some sequence of steps (or several agile iterations, or =
whatever), such as:
>=20
> * Identifying the problem or aim
> * Defining the scope
> * Identifying risks
> * Agreeing an approach
> * Initial implementation or prototype
> * Discovering problems based on the initial work
> * Testing
> * Final sign-off for release (this is what RFC votes should be)
>=20
>=20
> The problem is that the RFC process only really covers a small =
fraction of that process, and mostly the later parts. Most of the =
effort, and crucially most of the decisions, are left to whoever is =
drafting the RFC. So we end up with a process that feels more like a =
sales pitch for a shrink-wrapped product:
>=20
> * The RFC author identifies a problem, defines the scope, tries to =
identify risks, designs a solution, maybe builds an initial =
implementation or prototype, and starts refining and testing it
> * This is pitched to the community
> * There is some negotiation, usually over details rather than =
substantial rewrites, and often involving the author defending the =
decisions they've already made
> * The community decides whether to "buy" the proposal (this is what =
RFC votes often turn into)
>=20
> Some RFCs are rejected because the community doesn't actually agree on =
the definition of the problem or scope; capturing that in a reason for =
voting No might help someone later, but it's already far too late to =
save the effort of the author. Other RFCs are rejected because the =
community agrees on the problem, but not the details of the solution; =
writing that down encourages someone to try again, but repeatedly trying =
variations until one passes might not be the most efficient process.
>=20
>=20
> Just to be clear, I am not blaming authors for bringing ready-made =
pitches like this - it's what the current process tells them to do. Nor =
do I have a brilliant proposal that would change it overnight. But I do =
think we need to spend more time collaborating on ideas, and less on =
saying "yes" or "no" to each other's ready-made solutions.

I completely agree that the current process is sub-optimal. =20

It is basically like throwing a gladiator into the lion's den to see if =
they can survive.  If the person writing the RFC is good, they might get =
an upvote. If they have no experience with writing RFCs and/or can't =
implement the C code, they are most likely doomed to failure.  And PHP =
collectively is worse off because of this.

There is rarely if ever a collaborative process, except for what may =
happen ad-hoc between people off-list.

It would be great if instead of what we have know we could as a =
community discuss and determine a list of the top five (5) things we =
collectively want for PHP and put that out as a roadmap for PHP.  Maybe =
even plan a series of remote "conferences" over Zoom to collaborate on =
such a top five (5) list.

Ironically I just today read about Docker publishing their roadmap on =
Github:

- Docker Roadmap:  https://github.com/docker/roadmap/projects/1

=46rom there we could solicit a working group for each of the five (5) =
areas to each go off to a GitHub repo to collaborate and come back with =
a proposal for implementing in PHP, with the proposal to include a plan =
for all aspects of the what's needed, not just the idea.

=46rom there, we rinse and repeat.

Others:  Does this sound viable?

-Mike

P.S. However, even though I completely agree that the current process is =
suboptimal, that does not mean asking for reasons for voting for =
posterity should be tabled as the two concerns are orthogonal and some =
feedback would be more helpful to those looking to understand past votes =
than no feedback at all. =20

More importantly, adding reasons for voting would only require an update =
implemented an then an vote to use it, but fixing the process is an =
open-ended concern that would require herded lots of cats and then to =
impose a much bigger change, so I wouldn't want perfect to be the enemy =
of the good here.