About 6 weeks ago I started drafting up a basic workflow for PSRs. This has now had contribution and feedback from enough of the group that I feel confident we're ready to vote on this.
The basic idea is to solve the current problems in PSR formation:
- Following every single email is impossible.
- Knowing what to do with alternative proposals is hard.
- Knowing when something can be put in for vote is confusing.
- People often feel like something was rushed through (remember the complaints about PSR-3?).
- Ego-trips can potentially block feedback (not saying it has happened, but there is room for it currently).
- Changes happening late in the game can ruin votes or progress.
- If a supporter vanishes then a PSR is dead in the water.
- You go away for 2 weeks and WTF IS HAPPENING?
- Random nicknames for PSRs gets confusing. PSR-X, PSR-T, PSR-PM, PSR-WUT?
These are all well known problems, and this workflow takes care of all of them.
By promoting the idea of using meta documents, we have a "summary" of what has been happening, what proposals or alternatives are available and why they were merged or why they were ignored, means everyone can always look at ONE document to see whats going on. Winner.
By spreading the responsibility between multiple people we avoid "my way or the highway" solo authors, and everybody is clear about their responsibilities.
By forcing the PSRs to go though multiple stages there is never a rush, it will always take a set amount of time, and if you miss a PSR you must have been gone for at least a month - and if so, why did you not suggest a temporary stand-in while you were gone?
When in Review big changes cannot happen, it would invalidate the PSR and put it back to Draft.
By giving a PSR a number early we can always refer to an exact PSR. Only one active proposal can be alive for a specific topic, so if this goes ahead PSR-4 would be Caching and PSR-5 would be the new autoloader (for example). Maybe PSR-5 goes live, then PSR-4 goes live a month later. Or, maybe PSR-4 never goes live, but PSR-8 is the new autoloader. By offloading this to a wiki page of statuses we have a PEP style index, where numbers do not matter and just represent a proposal (which has a meta document for anyone confused about whats happening).
This might sound like a bunch of politics, but it solves pretty much every problem I can think of with PSR generation, and so far it has a lot of support from the people working on the current PSRs. If you're not sure or have concerns, please get in touch with me and we can talk. I'll be on IRC, twitter (of course) and you can email me directly too. Or, get on the original thread to have a more open conversation, but please do not post concerns in this thread: just votes. I've been screaming about this for weeks now so if you have major concerns I'll be really upset you didn't respond to the direct emails I sent, or my badgering on IRC and Twitter.
No pull requests will merged during this vote, unless its trivial typos. We can always amend bylaws later, so if this is not 100% perfect its still 100% better than the anarchy we've had over the last year.
Lets get this voted in, give Cache and Autoloader numbers, get them into Review and get on with making awesome sh*t, instead of looping around in circles and trying desperately to keep up with barrages of emails every day.
This vote will be counted on Monday 5th of August, meaning you have plenty of time to read through the
Bylaw Document.
+1 from PyroCMS