Hi Mike,
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. ;-)
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.
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.
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:
* 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)
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:
* 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)
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.
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.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
