[VOTE] Bylaw: PSR Review Workflow

Showing 1-32 of 32 messages
[VOTE] Bylaw: PSR Review Workflow Phil Sturgeon 7/22/13 8:01 AM
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
Re: [VOTE] Bylaw: PSR Review Workflow Don Gilbert 7/22/13 8:09 AM
+1 from Joomla
Re: [VOTE] Bylaw: PSR Review Workflow CalEvans 7/22/13 8:09 AM
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.
Re: [VOTE] Bylaw: PSR Review Workflow Pádraic Brady 7/22/13 10:08 AM
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
Re: [VOTE] Bylaw: PSR Review Workflow Phil Sturgeon 7/22/13 10:09 AM
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.

Re: [VOTE] Bylaw: PSR Review Workflow Pádraic Brady 7/22/13 10:12 AM
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.
Re: [VOTE] Bylaw: PSR Review Workflow Phil Sturgeon 7/22/13 10:14 AM
THANKS GOOGLE!

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

-- 
Phil Sturgeon


Re: [VOTE] Bylaw: PSR Review Workflow Larry Garfield 7/22/13 8:07 PM
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.
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.
 
 

Re: [VOTE] Bylaw: PSR Review Workflow Phil Sturgeon 7/22/13 8:15 PM
Yup, that'll be fixed post vote.
Re: [VOTE] Bylaw: PSR Review Workflow Taylor Otwell 7/24/13 8:50 AM
+1 from Laravel
Re: [VOTE] Bylaw: PSR Review Workflow Jordi Boggiano 7/25/13 1:54 AM
+1

--
Jordi Boggiano
@seldaek - http://nelm.io/jordi
Re: [VOTE] Bylaw: PSR Review Workflow pmjones 7/25/13 11:45 AM
+1 from Solar/Aura

-- pmj

Re: [VOTE] Bylaw: PSR Review Workflow Mike van Riel 7/25/13 1:52 PM
phpDocumentor votes +1
--
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.
 
 

Re: [VOTE] Bylaw: PSR Review Workflow William Durand 7/25/13 2:11 PM
Finally took the time to review the bylaw. Great!

+1 from Propel

--
William
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/51F18FF3.4040808%40gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 
Re: [VOTE] Bylaw: PSR Review Workflow Brett Bieber 7/25/13 2:21 PM
+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.
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.
 
 



--
Brett Bieber
Re: [VOTE] Bylaw: PSR Review Workflow Lukas Kahwe Smith 7/28/13 1:23 AM
+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



Re: [VOTE] Bylaw: PSR Review Workflow Ryan Parman 7/30/13 10:30 AM
AWS votes +1.

--
Ryan Parman

Re: [VOTE] Bylaw: PSR Review Workflow Paul Dragoonis 7/30/13 12:41 PM
+1 from PPI Framework.

Thanks to everyone who participated in making this happen.
 
Re: [VOTE] Bylaw: PSR Review Workflow Kris Wallsmith 7/30/13 12:54 PM
+1 from Assetic. Thank you Phil!
Re: [VOTE] Bylaw: PSR Review Workflow Fabien Potencier 7/30/13 2:03 PM
+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*
Re: [VOTE] Bylaw: PSR Review Workflow Guilherme Blanco 7/30/13 4:17 PM
+1 from Doctrine





--
Guilherme Blanco
MSN: guilher...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
Re: [VOTE] Bylaw: PSR Review Workflow Nils Adermann 8/2/13 4:06 AM
+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?
Re: [VOTE] Bylaw: PSR Review Workflow John Mertic 8/3/13 8:00 PM
+1 from SugarCRM
Re: [VOTE] Bylaw: PSR Review Workflow Phil Sturgeon 8/5/13 6:42 AM
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.
Re: [VOTE] Bylaw: PSR Review Workflow Mike van Riel 8/5/13 6:53 AM
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.
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.
 
 

Re: [VOTE] Bylaw: PSR Review Workflow Larry Garfield 8/5/13 10:40 AM
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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
Re: [VOTE] Bylaw: PSR Review Workflow Mike van Riel 8/5/13 10:45 AM
If people are referring to that proposal as PSR-4 then I'd figure we should
keep it that way to prevent confusion.
Re: [VOTE] Bylaw: PSR Review Workflow Paul Dragoonis 8/5/13 11:17 AM



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?

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/51FFE389.2040300%40garfieldtech.com.

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



Re: [VOTE] Bylaw: PSR Review Workflow Larry Garfield 8/5/13 11:46 AM
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
Re: [VOTE] Bylaw: PSR Review Workflow Drak 8/5/13 1:27 PM
+1 from Zikula (it's still 5th August btw)

On Monday, July 22, 2013 4:01:11 PM UTC+1, 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 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
Re: [VOTE] Bylaw: PSR Review Workflow Phil Sturgeon 8/5/13 1:39 PM
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.
Re: [VOTE] Bylaw: PSR Review Workflow Drak 8/5/13 1:41 PM
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
More topics »