> On Mar 19, 2020, at 4:46 PM, Rowan Tommins <rowan.coll...@gmail.com> wrote: > > 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.
I completely agree that the current process is sub-optimal. 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 From 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. From 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. 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
