[VOTE] Bylaw: PSR Review Workflow

357 views
Skip to first unread message

Phil Sturgeon

unread,
Jul 22, 2013, 11:01:11 AM7/22/13
to php...@googlegroups.com
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 original thread will show a lot of the formative conversation, as will the pull request.

The basic idea is to solve the current problems in PSR formation:
  1. Following every single email is impossible.
  2. Knowing what to do with alternative proposals is hard.
  3. Knowing when something can be put in for vote is confusing.
  4. People often feel like something was rushed through (remember the complaints about PSR-3?).
  5. Ego-trips can potentially block feedback (not saying it has happened, but there is room for it currently).
  6. Changes happening late in the game can ruin votes or progress.
  7. If a supporter vanishes then a PSR is dead in the water.
  8. You go away for 2 weeks and WTF IS HAPPENING? 
  9. 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

Donald Gilbert

unread,
Jul 22, 2013, 11:09:47 AM7/22/13
to php...@googlegroups.com
+1 from Joomla

Cal Evans

unread,
Jul 22, 2013, 11:09:45 AM7/22/13
to php...@googlegroups.com
Having reviews both this email and the PR, I have to say that I think this is a great idea and will go a long way to solving some of the problems we are experiencing. 

+1

=C=


--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/1b0667df-a02b-42c7-88f3-25ff9ede1db9%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
Read this book before you hire a 
developer to build your website.

Pádraic Brady

unread,
Jul 22, 2013, 1:08:05 PM7/22/13
to php...@googlegroups.com
Separate thread for voting, no???

Paddy

On 22 July 2013 16:09, Donald Gilbert <dilber...@gmail.com> wrote:
> +1 from Joomla
>
> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/d7e9f9bb-63f0-4cf2-aef8-6a5699635e5a%40googlegroups.com.
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative

Phil Sturgeon

unread,
Jul 22, 2013, 1:09:11 PM7/22/13
to php...@googlegroups.com
This is a separate thread for voting...

-- 
Phil Sturgeon

You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

Pádraic Brady

unread,
Jul 22, 2013, 1:12:35 PM7/22/13
to php...@googlegroups.com
In which case... +1 from Zend Framework ;)

P.S. It's not a separate thread according to Gmail which is
aggregating it with the original thread from 20 June. Unless that was
the separate thread... It may not appear to be a voting thread to
not-so-religious voting members.
> https://groups.google.com/d/msgid/php-fig/A06023D26BD94497A0788908B47D3147%40philsturgeon.co.uk.

Phil Sturgeon

unread,
Jul 22, 2013, 1:14:11 PM7/22/13
to php...@googlegroups.com
THANKS GOOGLE!

It has a similar title, so it may have smushed them in together, but this definitely is a new thread. 

-- 
Phil Sturgeon

Larry Garfield

unread,
Jul 22, 2013, 11:07:25 PM7/22/13
to php...@googlegroups.com
As we discussed in IRC earlier today, there is a bug that slipped in at the last minute.  The text now reads "FIG voting members and non-voting members".  But per Bylaw 03, there is no such thing as a "non-voting member".  We very deliberately removed that concept as it is utterly meaningless and synonymous with "random person on the mailing list".  We should thus not be referring to it in other bylaws.

The vote's already started and we cannot modify the document while voting is open.  However, bylaws unlike PSRs are not set in stone for all time.  They can be amended with an additional vote.

So, +1 from me with the expectation that we'll follow-up with another vote to fix that problem.

(Yes, I'm being a pedant.  But dotting our i's and crossing our t's is how we ensure that people can't challenge us for not following our own rules and just being a bunch of egotistical dictators; many of us are rather egotistical but that should not be brought to bear in PHP-FIG.)

--Larry Garfield, Drupal
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

Phil Sturgeon

unread,
Jul 22, 2013, 11:15:54 PM7/22/13
to php...@googlegroups.com, php...@googlegroups.com
Yup, that'll be fixed post vote.

Taylor Otwell

unread,
Jul 24, 2013, 11:50:22 AM7/24/13
to php...@googlegroups.com
+1 from Laravel

Jordi Boggiano

unread,
Jul 25, 2013, 4:54:58 AM7/25/13
to php...@googlegroups.com
+1

--
Jordi Boggiano
@seldaek - http://nelm.io/jordi

Paul M. Jones

unread,
Jul 25, 2013, 2:45:57 PM7/25/13
to php...@googlegroups.com
+1 from Solar/Aura

-- pmj

Mike van Riel

unread,
Jul 25, 2013, 4:52:03 PM7/25/13
to php...@googlegroups.com
phpDocumentor votes +1

William DURAND

unread,
Jul 25, 2013, 5:11:15 PM7/25/13
to php...@googlegroups.com
Finally took the time to review the bylaw. Great!

+1 from Propel

--
William

Brett Bieber

unread,
Jul 25, 2013, 5:21:19 PM7/25/13
to php...@googlegroups.com
+1 from PEAR


--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.



--
Brett Bieber

Lukas Kahwe Smith

unread,
Jul 28, 2013, 4:23:24 AM7/28/13
to php...@googlegroups.com
+1 from Jackalope
> --
> You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/1b0667df-a02b-42c7-88f3-25ff9ede1db9%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org



Ryan Parman

unread,
Jul 30, 2013, 1:30:07 PM7/30/13
to php...@googlegroups.com, php...@googlegroups.com
AWS votes +1.

--
Ryan Parman

Paul Dragoonis

unread,
Jul 30, 2013, 3:41:08 PM7/30/13
to php...@googlegroups.com
+1 from PPI Framework.

Thanks to everyone who participated in making this happen.
 

Kris Wallsmith

unread,
Jul 30, 2013, 3:54:01 PM7/30/13
to php...@googlegroups.com
+1 from Assetic. Thank you Phil!

Fabien Potencier

unread,
Jul 30, 2013, 5:03:38 PM7/30/13
to php...@googlegroups.com
+1 from Symfony

On 7/22/13 5:01 PM, Phil Sturgeon wrote:
> 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 original thread
> <https://groups.google.com/forum/#!topic/php-fig/qHOrincccWk> will show
> a lot of the formative conversation, as will the pull request
> <https://github.com/php-fig/fig-standards/pull/146>.
>
> The basic idea is to solve the current problems in PSR formation:
>
> 1. Following every single email is impossible.
> 2. Knowing what to do with alternative proposals is hard.
> 3. Knowing when something can be put in for vote is confusing.
> 4. People often feel like something was rushed through (remember the
> complaints about PSR-3?).
> 5. Ego-trips can potentially block feedback (not saying it has
> happened, but there is room for it currently).
> 6. Changes happening late in the game can ruin votes or progress.
> 7. If a supporter vanishes then a PSR is dead in the water.
> 8. You go away for 2 weeks and WTF IS HAPPENING?
> 9. Random nicknames for PSRs gets confusing. PSR-X, PSR-T, PSR-PM, PSR-WUT?
> <https://github.com/philsturgeon/fig-standards/blob/workflow-bylaw/bylaws/004-psr-workflow.md>.
>
> *+1 from PyroCMS*

guilher...@gmail.com

unread,
Jul 30, 2013, 7:17:57 PM7/30/13
to php...@googlegroups.com
+1 from Doctrine



To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/1b0667df-a02b-42c7-88f3-25ff9ede1db9%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.





--
Guilherme Blanco
MSN: guilher...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

Nils Adermann

unread,
Aug 2, 2013, 7:06:11 AM8/2/13
to php...@googlegroups.com
+1 from phpBB

On 07/22/2013 05:01 PM, Phil Sturgeon wrote:
> 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 original thread
> <https://groups.google.com/forum/#!topic/php-fig/qHOrincccWk> will show
> a lot of the formative conversation, as will the pull request
> <https://github.com/php-fig/fig-standards/pull/146>.
>
> The basic idea is to solve the current problems in PSR formation:
>
> 1. Following every single email is impossible.
> 2. Knowing what to do with alternative proposals is hard.
> 3. Knowing when something can be put in for vote is confusing.
> 4. People often feel like something was rushed through (remember the
> complaints about PSR-3?).
> 5. Ego-trips can potentially block feedback (not saying it has
> happened, but there is room for it currently).
> 6. Changes happening late in the game can ruin votes or progress.
> 7. If a supporter vanishes then a PSR is dead in the water.
> 8. You go away for 2 weeks and WTF IS HAPPENING?
> 9. Random nicknames for PSRs gets confusing. PSR-X, PSR-T, PSR-PM, PSR-WUT?
> plenty of time to read through the Bylaw Document
> <https://github.com/philsturgeon/fig-standards/blob/workflow-bylaw/bylaws/004-psr-workflow.md>.
>
> *+1 from PyroCMS*
>
> --
> You received this message because you are subscribed to the Google
> Groups "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to php-fig+u...@googlegroups.com.

John Mertic

unread,
Aug 3, 2013, 11:00:55 PM8/3/13
to php...@googlegroups.com
+1 from SugarCRM

Phil Sturgeon

unread,
Aug 5, 2013, 9:42:13 AM8/5/13
to php...@googlegroups.com
Vote Results: 19 for, 0 against out of 27 members. That gives us 70% in favor, so the bylaw passes.

Thank you to everybody for voting, and of course thank you for voting in favor. 

We'll be using this workflow for Autoloading, Caching and DocBlock PSRs which are all hopefully going to show their heads for an entrance vote very soon. I'm sure well need to make amendments (there is one going in for vote tomorrow, its minor, sorry about that) but we'll perfect stuff over time.

Mike van Riel

unread,
Aug 5, 2013, 9:53:14 AM8/5/13
to php...@googlegroups.com
Congratulations on the passing of the bylaw, Phil.

I will submit a draft PSR for the PHPDoc Standard this evening (CEST) as a new PSR in draft status in the
role of editor. I hope, yet am also confident, I will find two sponsors.
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

Larry Garfield

unread,
Aug 5, 2013, 1:40:25 PM8/5/13
to php...@googlegroups.com
PR question: I know some people outside of FIG have been referring to
the new autoloader as PSR-4 already. Do we want to let Paul get that in
as the first "new model" spec to keep the number, just to keep
consistency? (No one was calling caching or PHPDoc by a number recently
so those are fine.)

--Larry Garfield

On 8/5/13 8:53 AM, Mike van Riel wrote:
> Congratulations on the passing of the bylaw, Phil.
>
> I will submit a draft PSR for the PHPDoc Standard this evening (CEST) as
> a new PSR in draft status in the
> role of editor. I hope, yet am also confident, I will find two sponsors.
>
> On 08/05/2013 03:42 PM, Phil Sturgeon wrote:
>> Vote Results: 19 for, 0 against out of 27 members. That gives us 70%
>> in favor, so *the bylaw passes*.
>>
>> Thank you to everybody for voting, and of course thank you for voting
>> in favor.
>>
>> We'll be using this workflow for Autoloading, Caching and DocBlock
>> PSRs which are all hopefully going to show their heads for an entrance
>> vote very soon. I'm sure well need to make amendments (there is one
>> going in for vote tomorrow, its minor, sorry about that) but we'll
>> perfect stuff over time.
>> --
>> You received this message because you are subscribed to the Google
>> Groups "PHP Framework Interoperability Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to php-fig+u...@googlegroups.com.
>> To post to this group, send email to php...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/php-fig/b064788e-95f0-4a3e-8049-2d6a7c47588c%40googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/51FFAE4A.2000808%40gmail.com.

Mike van Riel

unread,
Aug 5, 2013, 1:45:19 PM8/5/13
to php...@googlegroups.com
If people are referring to that proposal as PSR-4 then I'd figure we should
keep it that way to prevent confusion.

Paul Dragoonis

unread,
Aug 5, 2013, 2:17:10 PM8/5/13
to php...@googlegroups.com
On Mon, Aug 5, 2013 at 6:40 PM, Larry Garfield <la...@garfieldtech.com> wrote:
PR question: I know some people outside of FIG have been referring to the new autoloader as PSR-4 already.  Do we want to let Paul get that in as the first "new model" spec to keep the number, just to keep consistency?  (No one was calling caching or PHPDoc by a number recently so those are fine.)

People referring to a spec proposal as its own official PSR number before it's been accepted or voted on, is a bad idea for now and going forward.

Come up with an acronym that refers to a proposal number. How about the number of the pull request that's been made.

Cache proposal pull request number is 149 (https://github.com/php-fig/fig-standards/pull/149). So how about we refer to it as FIG149 internally as the FIG repo's PR number 149

The cache proposal has been around longer than the autoloading one, so imagine we called the caching PSR-4 and then the autoloader proposal goes through in 2 weeks time, it'd be a bit of a mess.

Can we agree to come up with a "proposal number" strategy moving forward?


--Larry Garfield


On 8/5/13 8:53 AM, Mike van Riel wrote:
Congratulations on the passing of the bylaw, Phil.

I will submit a draft PSR for the PHPDoc Standard this evening (CEST) as
a new PSR in draft status in the
role of editor. I hope, yet am also confident, I will find two sponsors.

On 08/05/2013 03:42 PM, Phil Sturgeon wrote:
Vote Results: 19 for, 0 against out of 27 members. That gives us 70%
in favor, so *the bylaw passes*.


Thank you to everybody for voting, and of course thank you for voting
in favor.

We'll be using this workflow for Autoloading, Caching and DocBlock
PSRs which are all hopefully going to show their heads for an entrance
vote very soon. I'm sure well need to make amendments (there is one
going in for vote tomorrow, its minor, sorry about that) but we'll
perfect stuff over time.
--
You received this message because you are subscribed to the Google
Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send

To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/b064788e-95f0-4a3e-8049-2d6a7c47588c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



--
You received this message because you are subscribed to the Google
Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send

To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/51FFAE4A.2000808%40gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

Larry Garfield

unread,
Aug 5, 2013, 2:46:04 PM8/5/13
to php...@googlegroups.com
On 8/5/13 1:17 PM, Paul Dragoonis wrote:
>
>
>
> On Mon, Aug 5, 2013 at 6:40 PM, Larry Garfield <la...@garfieldtech.com
> <mailto:la...@garfieldtech.com>> wrote:
>
> PR question: I know some people outside of FIG have been referring
> to the new autoloader as PSR-4 already. Do we want to let Paul get
> that in as the first "new model" spec to keep the number, just to
> keep consistency? (No one was calling caching or PHPDoc by a number
> recently so those are fine.)
>
>
> People referring to a spec proposal as its own official PSR number
> before it's been accepted or voted on, is a bad idea for now and going
> forward.

Well, it was when the autoload spec was up for a final vote, before it
got pulled.

> Come up with an acronym that refers to a proposal number. How about the
> number of the pull request that's been made.
>
> Cache proposal pull request number is 149
> (https://github.com/php-fig/fig-standards/pull/149). So how about we
> refer to it as FIG149 internally as the FIG repo's PR number 149
>
> The cache proposal has been around longer than the autoloading one, so
> imagine we called the caching PSR-4 and then the autoloader proposal
> goes through in 2 weeks time, it'd be a bit of a mess.
>
> Can we agree to come up with a "proposal number" strategy moving forward?

That's exactly what the new bylaw says we do. :-) I'm just talking
about the proposal number for the stuff that's already in-the-works; I'm
assuming that the "vote to consider" for both autoload and cache will be
perfunctory anyway and both will get numbers at the end of it.

The easy solution: PMJ, move faster than I do and get the autoload
proposal up for a "vote to consider" vote quickly. :-)

--Larry Garfield

Drak

unread,
Aug 5, 2013, 4:27:51 PM8/5/13
to php...@googlegroups.com
+1 from Zikula (it's still 5th August btw)

Phil Sturgeon

unread,
Aug 5, 2013, 4:39:38 PM8/5/13
to php...@googlegroups.com
On Monday, 5 August 2013 16:27:51 UTC-4, Drak wrote:
+1 from Zikula (it's still 5th August btw)

I cast the vote in the morning so I called the results in the morning. I should have mentioned what time I'd cast results when I called the vote, but you probably shouldnt wait until the last day to vote anyway :)

RE: PSR Autoloader's Number

Paul D: The bylaw already explains how numbers are going to work, Larry is just trying to resolve potential confusion in that PSR-X has already been referred to (wrongly, or prematurely) as PSR-4. 

Larry: I don't think it matters too much either way, but...

Paul M J: It would be great if you smashed out that meta document fast so we could get it past the entrance vote before PSR-Cache, thus negating any potential confusion over the fact it was called PSR-4 - as it well then ACTUALLY be PSR-4.

Going forwards all numbers will just be assigned based on incrementing the last tracked PSR on the wiki. Simple.

Drak

unread,
Aug 5, 2013, 4:41:39 PM8/5/13
to php...@googlegroups.com
On 5 August 2013 21:39, Phil Sturgeon <em...@philsturgeon.co.uk> wrote:
On Monday, 5 August 2013 16:27:51 UTC-4, Drak wrote:
+1 from Zikula (it's still 5th August btw)

I cast the vote in the morning so I called the results in the morning. I should have mentioned what time I'd cast results when I called the vote, but you probably shouldnt wait until the last day to vote anyway :)

Honestly speaking, gmail filtered the [VOTE] part from my mails so I want sure this was a real vote. Must be a new google feature :-P
Reply all
Reply to author
Forward
0 new messages