ZendCon 2015 FIG Meeting notes

[Larry Garfield]

Thanks to ZendCon for organizing a room for us, since it didn't have an Uncon or BoF space.  We had several FIG representatives at the conference, but unfortunately only about half were able to make it.  It was a very productive meeting nonetheless.  We went over a number of important topics, so I would encourage everyone to read to the end.

If you really really don't care, the "Structural Issues" section toward the bottom is the most important for voting reps.

If you wish to discuss any particular section of this report in more detail, please start a new thread and/or fork this thread with a new subject line, just to keep everything organized.  Thanks.

Attendance
---------------

Voting Reps:
Larry Garfield, Drupal
Paul Jones, Aura
Chris Tankersley, Sculpin
Jeremy Lindblom, Guzzle
Chris Pitt, Silverstripe

Distinguished Guests:
Matthew Turland
Matthew Weier O'Phinney
John Bafford
Joe Ferguson


Topics discussed, not necessarily in order:


PSR-6 - Caching
---------------------

All present felt that the expiration cleanup PR that was at the time outstanding was Review safe, and it has since been merged. Yay.

We also discussed the other concern, that some methods return true/false for "Worked/Didn't Work" rather than throwing an exception.  Most of the discussion centered on the save() routines.

The general consensus was that while changing that would not be a Review-safe change, we shouldn't change it anyway for a number of reasons.

1) Cache backends are frequently unreliable by nature, so a save not working is not necessarily exceptional.
2) Given that, wrapping so many operations in a try-catch would be a DX fail.
3) Even with that aside, no one present really felt strongly enough about it to want to restart Review over it.

Thus, the recommendation is to not change those returns and continue as-is, with PSR-6 being ready for a vote really-soon-now-for-reals!


PSR-Version
----------------

This is the version deprecation proposal I've been shopping around.  Everyone present was +1 on such a community covenant existing.  John Bafford noted that it would help consultants, too, as they (he) can tell clients "I won't support your site unless you update your server, like everyone else is doing" and have more weight behind it.

That said, many questioned if FIG was the right venue for it to be discussed or hosted or voted on, particularly given the importance of hosts in the discussion.  After some back and forth, we concluded that such a covenant belongs as a separate effort from FIG.  However, FIG can and should publicly and officially endorse such an effort once it gets off the ground.

So, I will retract my PSR proposal and let someone else have PSR-13. :-)  Now to find somewhere else to host it.  Either a dedicated Google Group or maybe something in coordination with PHPVersions.info.  Phil, you still around?


Middlewares
----------------

As there has been some discussion of middlewares as a follow-up to PSR-7, and a possible Middleware PSR, we kicked that idea around for a while.  There are a couple of different styles in the wild already (we kept adding more and debated for a while if Guzzle's Request->Promise model constituted its own style), so it seems premature to lock one or even several down as PSRs.

Thus, let's leave this be at the moment.  We can collect more data on what middleware approaches emerge and become common, and revisit this question again in a year or so.  Let's give the market a chance to make up its mind first.


Async
--------

The proposed Event Loop and Promises PSRs were also discussed, and support for moving forward with them was basically universal.  The discussion was mainly around who the Working Groups would be.  As of the end of the meeting, we were looking at:

Promises:
- Editor: Jeremy Lindblom
- Coordinator: Volunteers still welcome, although Matthew volunteered Zend if no one else steps up
- Sponsor: TBD

Event loop:
- Editor: Andrew Carter
- Coordinator: Chris Pitt
- Sponsor: TBD

Larry indicated a willingness to Sponsor either one, but would prefer to spread the roles around a bit so volunteers welcome!  We also felt it was wise to invite Aaron Piotrowski of Icicle to both conversations for self-evident reasons.

Expect entrance votes on both PSRs in the next few weeks.  One of you can have PSR-13. :-)


PSR-12 - Revised coding standards
----------------------------------------------

The main question for PSR-12 was whether it should be targeted as an extension/add-on, or a full replacement.  Most immediately felt it should be a full replacement for PSR-1/2.  Larry played devil's advocate for a while, but after it was noted that IETF of late is also doing full-replace as a strategy everyone settled on full-replace fairly quickly.

However, the question of "when" then came up, given that the main aim is to add PHP 7-related considerations and PHP 7 isn't quite a thing yet.  (Almost!)  After some discussion, the general feeling of those present was similar to that of Middlewares and at the PNW meeting regarding the Container spec: Wait and see, then try to standardize what ends up being used.

The main arguments against were that projects would then need to change their standards (sometimes a less than easy process for large projects, even with tooling) and that, as happened with coding standards before, "wait and let the market decide" assumes that the market will decide.  There's a high probability of multiple competing conventions emerging, which would then make standardizing on one of them as contentious as PSR-2 was in the first place.  There was also a concern that PHP 7 adoption may not be rapid enough to even get a sense of what "the market" wants for several years.

At this time, the recommendation from the meeting is for the PSR-12 team to watch and see what projects that adopt PHP 7 end up doing over the next 6-12 months, and take their lead from that.  That doesn't necessarily mean "just do what they do", but be informed by it.


Membership
----------------

There was almost unanimous agreement that we should invite React PHP to join FIG.  Guess what, they've already applied!  Problem solved. :-)


The Naming of PSRs is a Difficult Matter
---------------------------------------------------

This was mentioned recently on the list, that the way we number/name PSRs is a bit confusing because people keep discussing things pre-Draft on list.  The general consensus in the meeting was ¯\_(ツ)_/¯.


Structural issues
----------------------

This was a large discussion covering a number of different concerns.

1) What do we do with PSRs that are in Draft forever and are not actually moving for long periods?  (As PSR-6 was on and off, and PSR-5, -9 and -10 are at present)
2) The web site is perpetually out of date, because no one "owns" it.  (As of the meeting, it still didn't have PSRs 11 or 12 listed. That has since been fixed with the new design that just went live.)
3) What ARE the rules around who has commit access to what, when?  The current rule on that is ¯\_(ツ)_/¯.  In fact, half of the people with admin access to the GitHub group right now are former members.
4) How can people who are not affiliated with a project specifically still help out FIG in a more formal capacity?

Matthew took far better notes than I did on this area, so I will include his notes below, almost verbatim.  Thanks, MWOP!

## Proposed By-Laws

### New FIG Role: Secretary

The secretary role would serve several functions:

- Keeping the website up-to-date, including merging pull requests.
- GitHub organization administration (assigning people to teams, removing people
  from teams, etc.). Specifically, this would involve providing editors and
  coordinators of proposals commit access prior to a proposal being accepted or
  rejected, and removing commit access once a proposal is complete (unless a
  member is also involved in other active proposals).
- Tallying votes.
- Tracking member project activity, and marking projects as inactive.

The role will be filled by 3 people, to ensure that at least one person is
always available in a timely manner. Additionaly, to remove partiality, the role
would be restricted to:

- non-voting members of FIG;
- members not actively involved in a current proposal (i.e., you cannot be an
  editor of a proposal AND fulfill the role of secretary).

Not discussed:

- duration of service. (i.e., does service terminate after a fixed duration?)
- eligility (are secretaries proposed? or do they volunteer?)
- election (is an entrance vote required?)

Joe Ferguson, who was present, volunteered for the role of Secretary.

### Commit Access

Providing members with commit access unrelated to proposals (e.g., for webite
maintentance) would require a 2 week discussion period, followed by a 2 week
voting period.

(Note: this may me a moot proposal considering the aforementioned Secretary Role
proposal.)

### Suspension/Abandonment of Proposals

Proposals will be considered **suspended** if no significant activity has
occurred for a period of six months or more. "Significant" in this context means
substantive changes — i.e., more than typographic or grammar fixes. At that
time, commit access by the editor, coordinator, and sponsor will be revoked
until such time as a substantive pull request is made and/or a call to move the
proposal into review is made. To re-open the proposal via pull request, the pull
request **must** ping the secretary role (which will be a team on the php-fig
GitHub organization).

Proposals will be considered **abandoned** if no significant activity has
occurred for a period of twelve months or more. At that time, the proposal may
be resurrected by any interested parties, but to do so will:

- require a re-entrance vote, per a standard proposal entrance; and
- require a new proposal identifier.

The Secretary shall be responsible for tracking proposal activity and announcing
suspension and/or abandonment status.

### Process for replacing abandoned proposal leadership

In the event that a proposal member — either editor, coordinator, or sponsor —
abandons their role, the following must occur to replace the role:

- First, the remaning members must communicate and determine if either wants to
  assume the abandoned role. If so, this must be communicated on-list.
- Second, once any such role changes are complete, the remaining members must
  solicit a replacement on-list.

Not discussed:

- Do proposal role changes need to be voted in after announcing intent, or is
  the announcementt enough?

Whew!  Good meeting, everyone!  We covered a lot of ground. :-)

--Larry Garfield

[Paul Dragoonis]

Inline.

On Tue, Oct 27, 2015 at 4:47 AM, Larry Garfield <la...@garfieldtech.com> wrote:

Thanks to ZendCon for organizing a room for us, since it didn't have an Uncon or BoF space.  We had several FIG representatives at the conference, but unfortunately only about half were able to make it.  It was a very productive meeting nonetheless.  We went over a number of important topics, so I would encourage everyone to read to the end.

If you really really don't care, the "Structural Issues" section toward the bottom is the most important for voting reps.

If you wish to discuss any particular section of this report in more detail, please start a new thread and/or fork this thread with a new subject line, just to keep everything organized.  Thanks. 

Attendance
---------------

Voting Reps:
Larry Garfield, Drupal
Paul Jones, Aura
Chris Tankersley, Sculpin
Jeremy Lindblom, Guzzle
Chris Pitt, Silverstripe

Distinguished Guests:
Matthew Turland
Matthew Weier O'Phinney
John Bafford
Joe Ferguson

Thanks everyone who took the time to sit down together :-)

 

Topics discussed, not necessarily in order:


PSR-6 - Caching
---------------------

All present felt that the expiration cleanup PR that was at the time outstanding was Review safe, and it has since been merged. Yay.

We also discussed the other concern, that some methods return true/false for "Worked/Didn't Work" rather than throwing an exception.  Most of the discussion centered on the save() routines.

The general consensus was that while changing that would not be a Review-safe change, we shouldn't change it anyway for a number of reasons.

1) Cache backends are frequently unreliable by nature, so a save not working is not necessarily exceptional.
2) Given that, wrapping so many operations in a try-catch would be a DX fail.
3) Even with that aside, no one present really felt strongly enough about it to want to restart Review over it.

Thus, the recommendation is to not change those returns and continue as-is, with PSR-6 being ready for a vote really-soon-now-for-reals!

All is sweet, REVIEW status remains :-)

I've been managing it since day one, but it isn't a one-man job, since lots of people are coming and going. Coincidentally I gave it some updating yesterday.

 

3) What ARE the rules around who has commit access to what, when?  The current rule on that is ¯\_(ツ)_/¯.  In fact, half of the people with admin access to the GitHub group right now are former members.

Right now I'm hesitant to remove people who are former members, because I don't want to cause a fuss. If there was something more formal in place about when people get removed, then that'd make my life easier for sure.

 

4) How can people who are not affiliated with a project specifically still help out FIG in a more formal capacity?

Matthew took far better notes than I did on this area, so I will include his notes below, almost verbatim.  Thanks, MWOP!

## Proposed By-Laws

### New FIG Role: Secretary

The secretary role would serve several functions:

- Keeping the website up-to-date, including merging pull requests.
- GitHub organization administration (assigning people to teams, removing people
  from teams, etc.). Specifically, this would involve providing editors and
  coordinators of proposals commit access prior to a proposal being accepted or
  rejected, and removing commit access once a proposal is complete (unless a
  member is also involved in other active proposals). 

- Tallying votes.
- Tracking member project activity, and marking projects as inactive.

The role will be filled by 3 people, to ensure that at least one person is
always available in a timely manner. Additionaly, to remove partiality, the role
would be restricted to:

- non-voting members of FIG;
- members not actively involved in a current proposal (i.e., you cannot be an
  editor of a proposal AND fulfill the role of secretary).

Not discussed:

- duration of service. (i.e., does service terminate after a fixed duration?)
- eligility (are secretaries proposed? or do they volunteer?)
- election (is an entrance vote required?)

Joe Ferguson, who was present, volunteered for the role of Secretary.

I've been doing "Secretary" role for a long time now, I'd welcome anyone else who wants to help out. 

Also, what I feel would help out in the case of maintaining things is if people just prompted Paul or Paul to do something it'd also get done quickly, since we're not always on top of what's happening on every PSR. Just my $0.02 to add to that.

 

--
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/562F01D0.5040102%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Cullum]

Inline

--

Michael C

I do think it would be a shame if this isn't done through the FIG as I think it could hurt adoption if it's not 'sailing on the FIG brand'. It is a slightly new category of PSR but then, so is PSR-9/PSR-10 and if PSR-Version moves out of the FIG, we need to consider what really belongs in the FIG as a PSR. I personally think that, taking the FIG back to raw basics, we are a group of large member projects, with wider community input who together work on, and discuss things, in order to put forward initiatives or proposals as a collective to ensure good quality and promote adoption. If we start creating faction groups then not only will that not have that FIG brand (and with it, the collective brand of our 40 projects) but also it will start to weaken the FIG's brand.

Middlewares
----------------

As there has been some discussion of middlewares as a follow-up to PSR-7, and a possible Middleware PSR, we kicked that idea around for a while.  There are a couple of different styles in the wild already (we kept adding more and debated for a while if Guzzle's Request->Promise model constituted its own style), so it seems premature to lock one or even several down as PSRs.

Thus, let's leave this be at the moment.  We can collect more data on what middleware approaches emerge and become common, and revisit this question again in a year or so.  Let's give the market a chance to make up its mind first.


Async
--------

The proposed Event Loop and Promises PSRs were also discussed, and support for moving forward with them was basically universal.  The discussion was mainly around who the Working Groups would be.  As of the end of the meeting, we were looking at:

Promises:
- Editor: Jeremy Lindblom
- Coordinator: Volunteers still welcome, although Matthew volunteered Zend if no one else steps up
- Sponsor: TBD

Event loop:
- Editor: Andrew Carter
- Coordinator: Chris Pitt
- Sponsor: TBD

Larry indicated a willingness to Sponsor either one, but would prefer to spread the roles around a bit so volunteers welcome!  We also felt it was wise to invite Aaron Piotrowski of Icicle to both conversations for self-evident reasons.

Expect entrance votes on both PSRs in the next few weeks.  One of you can have PSR-13. :-)

Could we wait for Icicle and React to both become members (~4 weeks) as I'm sure they'd be great fits for those roles? 

PSR-12 - Revised coding standards
----------------------------------------------

The main question for PSR-12 was whether it should be targeted as an extension/add-on, or a full replacement.  Most immediately felt it should be a full replacement for PSR-1/2.  Larry played devil's advocate for a while, but after it was noted that IETF of late is also doing full-replace as a strategy everyone settled on full-replace fairly quickly.

I agree, I made these changes about a week ago to the draft proposal as is.

 

However, the question of "when" then came up, given that the main aim is to add PHP 7-related considerations and PHP 7 isn't quite a thing yet.  (Almost!)  After some discussion, the general feeling of those present was similar to that of Middlewares and at the PNW meeting regarding the Container spec: Wait and see, then try to standardize what ends up being used.

The main arguments against were that projects would then need to change their standards (sometimes a less than easy process for large projects, even with tooling) and that, as happened with coding standards before, "wait and let the market decide" assumes that the market will decide.  There's a high probability of multiple competing conventions emerging, which would then make standardizing on one of them as contentious as PSR-2 was in the first place.  There was also a concern that PHP 7 adoption may not be rapid enough to even get a sense of what "the market" wants for several years.

At this time, the recommendation from the meeting is for the PSR-12 team to watch and see what projects that adopt PHP 7 end up doing over the next 6-12 months, and take their lead from that.  That doesn't necessarily mean "just do what they do", but be informed by it.

Some of the changes which take from PHP 5.5 and 5.6 we've done just that. With regards to PHP 7, there seems to be little contention as to the ways of doing things that we've gone for, with a few contentious points (the only one actually is the strict types declaration which I'll bring to the ML shortly), which after a discussion on the ML with projects present will have the same feedback as waiting to see what projects would do when they adopt PHP 7 (just soliciting earlier responses, but with an earlier timeframe). If anything, more projects are likely to respond to this than will adopt PHP 7 in the next few months so it will be a better representative sample of projects preferences. Ultimately the proposal only has a couple of sections left to add with regards to PHP 7 functionality then it should be mostly done. https://github.com/cs-extended/fig-standards/issues?q=is%3Aissue+label%3A%22New+functionality%22+is%3Aopen

Those of you who have been around for longer will remember I used to be around quite a bit (I left for a while) and I ended up filling a large chunk of this role (in particular voting tallying, tracking project activity etcetera) and in conversation people would often joke that I was the de-facto secretary of the FIG so I think this is great to have a formal role with formal responsibilities. I would also like to volunteer but I will be Editor of PSR-12 for the next couple of months so depending on the timing of when we get this voted in and the election (?) of the new secretaries I might not be eligible.

My suggestion would be new secretaries are 'voted in' (volunteer but find a member sponsor as membership requests do) at the beginning of each year (new ones would take over at the end of the voting process), and secretaries can run for 2 terms in a row, but all three secretaries cannot leave at the same time. If someone leaves part of the way through, a new secretary may be elected but is not required if there is less than 6 months before the next changeover.

### Commit Access

Providing members with commit access unrelated to proposals (e.g., for webite
maintentance) would require a 2 week discussion period, followed by a 2 week
voting period.

(Note: this may me a moot proposal considering the aforementioned Secretary Role
proposal.)

It seems slightly implied but is not explicit in the previous section. Did you discuss non-voting member editors getting commit access as well as just the co-ordinator/sponsor and voting editors? 

### Suspension/Abandonment of Proposals

Proposals will be considered **suspended** if no significant activity has
occurred for a period of six months or more. "Significant" in this context means
substantive changes — i.e., more than typographic or grammar fixes. At that
time, commit access by the editor, coordinator, and sponsor will be revoked
until such time as a substantive pull request is made and/or a call to move the
proposal into review is made. To re-open the proposal via pull request, the pull
request **must** ping the secretary role (which will be a team on the php-fig
GitHub organization).

Proposals will be considered **abandoned** if no significant activity has
occurred for a period of twelve months or more. At that time, the proposal may
be resurrected by any interested parties, but to do so will:

- require a re-entrance vote, per a standard proposal entrance; and
- require a new proposal identifier.

The Secretary shall be responsible for tracking proposal activity and announcing
suspension and/or abandonment status.

On the whole I agree this is a good idea but then what about the proposals which you wanted to let 'simmer' for 6-12 months. In theory they would come under this and be marked as suspended or abandoned.

I also dislike the requirement that once a proposal has been abandoned a new proposal identifier would be assigned as this means we could end up with a series of numbers which will never be used. I think if the aims and goals are the same then it should be possible to use the old PSR identifier and resurrect an abandoned PSR and a new one should only be introduced if they differ.

### Process for replacing abandoned proposal leadership

In the event that a proposal member — either editor, coordinator, or sponsor —
abandons their role, the following must occur to replace the role:

- First, the remaning members must communicate and determine if either wants to
  assume the abandoned role. If so, this must be communicated on-list.
- Second, once any such role changes are complete, the remaining members must
  solicit a replacement on-list.

Not discussed:

- Do proposal role changes need to be voted in after announcing intent, or is
  the announcementt enough? 

I think that is slightly unnecessary [voting on role changes] and will only cause to slow down the process (PSR-6 would be four weeks behind where it is now if this were the case]. If any objections are raised by a FIG member upon the announcement of a role switch, it can always defer to a vote? When the entrance vote occurs, you are voting on the concept of the proposal, not the working group or proposal content itself.

 

Whew!  Good meeting, everyone!  We covered a lot of ground. :-)

--Larry Garfield

--

[Moshe Brevda]

RE: SECRETARY: as a long time lurker who felt unable to contribute much due to not representing any projects, this might be a good way to get involved. I'm also in GMT+2, which should allow visibility and overlap during non us business hours. I would love to help out!

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAAqcDMj%2BJVanAdK%2BJrCKVEFTe8Ak0U2io2Lv-Rwuet_zektzFg%40mail.gmail.com.

[Korvin Szanto]

Inline.

On Mon, Oct 26, 2015 at 9:47 PM Larry Garfield <la...@garfieldtech.com> wrote:

Thanks to ZendCon for organizing a room for us, since it didn't have an Uncon or BoF space.  We had several FIG representatives at the conference, but unfortunately only about half were able to make it.  It was a very productive meeting nonetheless.  We went over a number of important topics, so I would encourage everyone to read to the end.

Thank you for taking and publishing these notes Larry, I hope we can get some over the air meetups going so that we can all engage in this kind of stuff more often. 

Yay 

PSR-Version
----------------

This is the version deprecation proposal I've been shopping around.  Everyone present was +1 on such a community covenant existing.  John Bafford noted that it would help consultants, too, as they (he) can tell clients "I won't support your site unless you update your server, like everyone else is doing" and have more weight behind it.

That said, many questioned if FIG was the right venue for it to be discussed or hosted or voted on, particularly given the importance of hosts in the discussion.  After some back and forth, we concluded that such a covenant belongs as a separate effort from FIG.  However, FIG can and should publicly and officially endorse such an effort once it gets off the ground.

So, I will retract my PSR proposal and let someone else have PSR-13. :-)  Now to find somewhere else to host it.  Either a dedicated Google Group or maybe something in coordination with PHPVersions.info.  Phil, you still around?

I'm sad to see this lose the weight of the FIG, but I'm still eager to help in any way I can. 

 

Middlewares
----------------

As there has been some discussion of middlewares as a follow-up to PSR-7, and a possible Middleware PSR, we kicked that idea around for a while.  There are a couple of different styles in the wild already (we kept adding more and debated for a while if Guzzle's Request->Promise model constituted its own style), so it seems premature to lock one or even several down as PSRs. 

Thus, let's leave this be at the moment.  We can collect more data on what middleware approaches emerge and become common, and revisit this question again in a year or so.  Let's give the market a chance to make up its mind first.

I'm not sure that I agree with this. I've begun working on a middleware manager for concrete5 and I realized pretty quickly that my middleware won't work with any of MWOP's middleware because he and others use the magic __call method rather than a class method to support adding straight callables to the stack. So for my middleware to work with MWOP's middleware, I have to decorate either mine or his. I think starting the discussion now with a real draft or pre-draft would be good for the community to make informed implementations that don't require a ton of work to rework into the standard.

I don't think we should rush to pass anything, but I do think we should have real discussion and thought in place for people who are implementing this today so that they aren't left to come up with whatever may suit them at the time.

 

Async
--------

The proposed Event Loop and Promises PSRs were also discussed, and support for moving forward with them was basically universal.  The discussion was mainly around who the Working Groups would be.  As of the end of the meeting, we were looking at:

Promises:
- Editor: Jeremy Lindblom
- Coordinator: Volunteers still welcome, although Matthew volunteered Zend if no one else steps up
- Sponsor: TBD

Event loop:
- Editor: Andrew Carter
- Coordinator: Chris Pitt
- Sponsor: TBD

Larry indicated a willingness to Sponsor either one, but would prefer to spread the roles around a bit so volunteers welcome!  We also felt it was wise to invite Aaron Piotrowski of Icicle to both conversations for self-evident reasons.

Now that the version deprecation PSR is off the table, I'd be glad to sponsor the Promises effort.

 

Expect entrance votes on both PSRs in the next few weeks.  One of you can have PSR-13. :-) 

PSR-12 - Revised coding standards
----------------------------------------------

The main question for PSR-12 was whether it should be targeted as an extension/add-on, or a full replacement.  Most immediately felt it should be a full replacement for PSR-1/2.  Larry played devil's advocate for a while, but after it was noted that IETF of late is also doing full-replace as a strategy everyone settled on full-replace fairly quickly.

However, the question of "when" then came up, given that the main aim is to add PHP 7-related considerations and PHP 7 isn't quite a thing yet.  (Almost!)  After some discussion, the general feeling of those present was similar to that of Middlewares and at the PNW meeting regarding the Container spec: Wait and see, then try to standardize what ends up being used.

The main arguments against were that projects would then need to change their standards (sometimes a less than easy process for large projects, even with tooling) and that, as happened with coding standards before, "wait and let the market decide" assumes that the market will decide.  There's a high probability of multiple competing conventions emerging, which would then make standardizing on one of them as contentious as PSR-2 was in the first place.  There was also a concern that PHP 7 adoption may not be rapid enough to even get a sense of what "the market" wants for several years.

At this time, the recommendation from the meeting is for the PSR-12 team to watch and see what projects that adopt PHP 7 end up doing over the next 6-12 months, and take their lead from that.  That doesn't necessarily mean "just do what they do", but be informed by it.

I agree with this sans the 6-12 month timeline. I'd contend that the PHP-FIG as a whole is a good representation of the "market" at large and anything we agree on as a group can reasonably be assumed to be what the greater market wants. 

I'd much rather come to the conclusion of waiting once someone raises an issue with the contents of the draft so that we actually have a measure of success and something to look for rather than just waiting an arbitrary amount of time before making a judgement.

 

Membership
----------------

There was almost unanimous agreement that we should invite React PHP to join FIG.  Guess what, they've already applied!  Problem solved. :-)

If a fig member wants a non-fig member project to be a member, reach out to them and offer to sponsor their membership application. I don't want to give the impression that this is somehow an invite only group that requires an in person meeting display of hands to join.

 

The Naming of PSRs is a Difficult Matter
---------------------------------------------------

This was mentioned recently on the list, that the way we number/name PSRs is a bit confusing because people keep discussing things pre-Draft on list.  The general consensus in the meeting was ¯\_(ツ)_/¯.

I think we might burn ourselves a bit by having pre-draft and draft be so similar, effectively the only difference is that there's a PSR number assigned. I think we should refer to a PSR as the "name" up until it gets a version number, then we all refer to it by the number by rule.

I've been toying with the idea of having PSR numbers assigned after review at the time of the final vote rather than after the entrance vote so that we don't have things like PSR-5 occupying a number forever.  Not sure what effect that would have on this particular issue, just a thought.

I like these ideas. I think we should get a working group together and try to get a bylaw in.

 

Whew!  Good meeting, everyone!  We covered a lot of ground. :-)

--Larry Garfield

--

[Larry Garfield]

On 10/27/15 11:00 AM, Korvin Szanto wrote:
>
>
> Membership
> ----------------
>
> There was almost unanimous agreement that we should invite React
> PHP to join FIG. Guess what, they've already applied! Problem
> solved. :-)
>
> If a fig member wants a non-fig member project to be a member, reach
> out to them and offer to sponsor their membership application. I don't
> want to give the impression that this is somehow an invite only group
> that requires an in person meeting display of hands to join.

There's no invite-only nature here. It was more "we keep talking about
async, has anyone talked to React? They really should be a member at
this point. Someone want to go bug them? Hey, look, they applied!"
Nothing fancier than that. :-)

> The Naming of PSRs is a Difficult Matter
> ---------------------------------------------------
>
> This was mentioned recently on the list, that the way we
> number/name PSRs is a bit confusing because people keep discussing
> things pre-Draft on list. The general consensus in the meeting
> was ¯\_(ツ)_/¯.
>
>
> I think we might burn ourselves a bit by having pre-draft and draft be
> so similar, effectively the only difference is that there's a PSR
> number assigned. I think we should refer to a PSR as the "name" up
> until it gets a version number, then we all refer to it by the number
> by rule.
> I've been toying with the idea of having PSR numbers assigned after
> review at the time of the final vote rather than after the entrance
> vote so that we don't have things like PSR-5 occupying a number
> forever. Not sure what effect that would have on this particular
> issue, just a thought.

We used to do that pre-2013. It was horribly confusing, as every PSR
was PSR-X. :-) It was even worse where there were multiple competing
proposals for the same problem space (both PSR-4 and PSR-6 had that
problem), as we had PSR-Bob and PSR-Alice. It was doubleplusungood.

Having a number be occupied forever, well, ¯\_(ツ)_/¯.

--
--Larry Garfield