Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109153
To: internals@lists.php.net
References: <14383D05-EA33-4CD2-9648-40AA29A837A5@newclarity.net>
 <CA+kxMuRkCZjWbuR1yrw8KxcM20ZxZ-7Zu8s=RAxbspLkGsjO=Q@mail.gmail.com>
 <2AE639B7-7775-48CC-8435-2F455D429E6A@newclarity.net>
Message-ID: <17a8b468-e863-c528-3596-23dc4c60ddab@gmail.com>
Date: Thu, 19 Mar 2020 20:46:13 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <2AE639B7-7775-48CC-8435-2F455D429E6A@newclarity.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Capturing reasons for votes for historical sake?
From: rowan.collins@gmail.com (Rowan Tommins)

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]