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