[PSR-15] Reloaded - Go!

[Adam Culp]

I raise a motion that we get PSR-15 going again. The time for politics and emotion have passed, and we need to get stuff done.

We are past the date when pre-existing recommendations could slide in under the old FIG bylaws, and so we must get PSR-15 into FIG 3.0 shape.

Also, Paul M. Jones has elected not to continue with the FIG after 3.0 passed. Therefore we need a new Coordinator for PSR-15, which I believe Matthew Weier O-Phinney had volunteered to take over.

Once the previous 2 items are completed (convert to FIG 3.0 and get a Coordinator) this recommendation is ready to go to vote. Let's get it going.

Regards,

Adam R Culp

IBMiToolkit

[Michael Mayer]

First, at this time, HTTP Factories (PSR-17) must/should go first. PSR-15 1.2 Generating Responses states:

It is RECOMMENDED that any middleware that needs to generate a response will use HTTP Factories as defined in PSR-17, […]

Secondly, in my opinion, the Coordinator/Sponsor of a PSR should represent the interests of the FIG itself during the Draft and Review stages and also afterwards.

While I appreciate Matthew's contributions and especially his feedback based on implementing PSR-15 in Zend-Stratigility, he have had a great impact on very opinionated PSR-15 design decisions – which seems to be intended to advantage Zend-Stratigility (see http-middleware#24 (comment)), but may also create highly unexpected BCs for consumers (see Migration Issue for example).

Sorry, but if Matthew also becomes the Sponsor of PSR-15, then I believe the independence and objectivity of PSR-Sponsors might reasonably be questioned.

Regards,

Michael Mayer

[Matthew Weier O'Phinney]

On Mon, Mar 20, 2017 at 5:38 AM, Michael Mayer <mic...@schnittstabil.de> wrote:
> First, at this time, HTTP Factories (PSR-17) must/should go first. PSR-15
> 1.2 Generating Responses states:
>
>> It is RECOMMENDED that any middleware that needs to generate a response
>> will use HTTP Factories as defined in PSR-17, […]

PSR-15 has no dependence on PSR-17. This should likely be rephrased to
indicate that "middleware SHOULD compose a response or a factory that
will generate a response (such as those proposed in PSR-17 ...)". But
I see no reason to delay work or acceptance of PSR-15 based on PSR-17;
the two proposals are orthogonal.

> Secondly, in my opinion, the Coordinator/Sponsor of a PSR should represent
> the interests of the FIG itself during the Draft and Review stages and also
> afterwards.
> While I appreciate Matthew's contributions and especially his feedback based
> on implementing PSR-15 in Zend-Stratigility, he have had a great impact on
> very opinionated PSR-15 design decisions – which seems to be intended to
> advantage Zend-Stratigility (see http-middleware#24 (comment)), but may also
> create highly unexpected BCs for consumers (see Migration Issue for
> example).
> Sorry, but if Matthew also becomes the Sponsor of PSR-15, then I believe the
> independence and objectivity of PSR-Sponsors might reasonably be questioned.

This is a heavy accusation, and, honestly, feels like a pretty
personal attack, based on the history of exchanges we've had on the
http-interop group. You and I disagree on many of the decisions made
within the http-interop group. That's to be expected; not every
decision of every specification will satisfy every developer. However,
making the leap to say that our disagreement means _I_ cannot be
objective in this role feels very much like a reach.

The role of the coordinator/sponsor is to act as a liaison between the
working group and the core committee. Their goal should be to ensure
that the process is followed: that the requisite number of members
exist for the working group, that they have invited participation from
projects that might be affected or be interested in implementing
and/or consuming the proposal, that at least the minimum number of
implementations have been built, etc. Finally, they would be
responsible for tallying the results of the WG completion vote,
bringing the results to the CC, and initiating the CC vote.

The coordinator/sponsor is also a de facto _MEMBER_ of the WG. Which
means they may be proposing changes, creating implementations, or
consuming implementations themselves in order to test the ideas
presented. Members of the WG are expected to be involved!

The EDITOR's job is to facilitate and evaluate contributions to the
specification. They are the person driving the specification itself;
the coodinator/sponsor is coordinating _process_.

Considering that final decision making falls under the role of the
editor, I see no reason why I cannot be considered as sponsor.

If others disagree, however, I'm willing to limit my role to being
solely a member of the WG.

> Am Sonntag, 19. März 2017 16:44:23 UTC+1 schrieb Adam Culp:
>>
>> I raise a motion that we get PSR-15 going again. The time for politics and
>> emotion have passed, and we need to get stuff done.
>>
>> We are past the date when pre-existing recommendations could slide in
>> under the old FIG bylaws, and so we must get PSR-15 into FIG 3.0 shape.
>>
>> Also, Paul M. Jones has elected not to continue with the FIG after 3.0
>> passed. Therefore we need a new Coordinator for PSR-15, which I believe
>> Matthew Weier O-Phinney had volunteered to take over.
>>
>> Once the previous 2 items are completed (convert to FIG 3.0 and get a
>> Coordinator) this recommendation is ready to go to vote. Let's get it going.
>>
>> Regards,
>> Adam R Culp
>> IBMiToolkit
>

> --
> 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/9bfa790b-cbb2-4628-aa21-b82a8b8aa549%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



--
Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

[Michael Mayer]

I have neither claimed that you cannot nor that you will not be objective – do not try to read it into my comment.

Furthermore, do not try to downplay the Sponsor's role to a WG member with some administration tasks.

From the fig-standards/bylaws/001-mission-and-structure.md:

Sponsor
A PSR must be sponsored by a member of the Core Committee. […] they provide a level of oversight on the PSR's drafting on behalf of the Core Committee, […]

 

The Core Committee
[…] The Core Committee is responsible for ensuring a high level of quality and consistency amongst all published specifications, and that all relevant perspectives and use cases are given due consideration.
[…] Core Committee members are expected to consider the impact of their actions on the PHP ecosystem as a whole when acting in their capacity as a Core Committee member

Sorry Matthew, honestly, I cannot remember one relevant comment off the cuff, where you have considered the impact of PSR-15 on a middleware framework other than your own. IMO that is permissible for an arbitrary WG member, but not for the Sponsor.

[Woody Gilk]

As Editor of PSR-15, I would very much like to see the proposal move forward. Thank you for getting the ball rolling, Adam!

My opinion doesn't count for much in the Sponsor or WG selection process, but I fully support Matthew as sponsor of PSR-15. He has been involved with the process for months and has been able to articulate his position on a number of contentious issues without being detrimental to the process.

Looking forward to getting this proposal wrapped up, there is a ton of community interest in doing so!

--
Woody Gilk
http://about.me/shadowhand

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/01ff1d6f-7c67-446a-8328-152e9845e8c2%40googlegroups.com.

[Larry Garfield]

As a member of the Core Committee I have no problem at all with MWOP as the Sponsor for continuing PSR-15 work.  He's the natural candidate, and has a long track record of being a calm, level-headed, considered collaborator.

--Larry Garfield

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/CAGOJM6KTZvEufnKGthD_XjSz6cRUn6Lt7XCbw0715ZiL7tE2iA%40mail.gmail.com.

[grey...@gmail.com]

I second what Larry has said. MWOP is a fantastic person to sponsor this work. 

Graham

On Tuesday, March 21, 2017 at 11:05:45 AM UTC-4, Larry Garfield wrote:

As a member of the Core Committee I have no problem at all with MWOP as the Sponsor for continuing PSR-15 work.  He's the natural candidate, and has a long track record of being a calm, level-headed, considered collaborator.

--Larry Garfield

On 03/21/2017 08:55 AM, Woody Gilk wrote:

As Editor of PSR-15, I would very much like to see the proposal move forward. Thank you for getting the ball rolling, Adam!

My opinion doesn't count for much in the Sponsor or WG selection process, but I fully support Matthew as sponsor of PSR-15. He has been involved with the process for months and has been able to articulate his position on a number of contentious issues without being detrimental to the process.

Looking forward to getting this proposal wrapped up, there is a ton of community interest in doing so!

--
Woody Gilk
http://about.me/shadowhand

On Tue, Mar 21, 2017 at 4:11 AM, Michael Mayer <mic...@schnittstabil.de> wrote:

I have neither claimed that you cannot nor that you will not be objective – do not try to read it into my comment.

Furthermore, do not try to downplay the Sponsor's role to a WG member with some administration tasks.

From the fig-standards/bylaws/001-mission-and-structure.md:

Sponsor
A PSR must be sponsored by a member of the Core Committee. […] they provide a level of oversight on the PSR's drafting on behalf of the Core Committee, […]

 

The Core Committee
[…] The Core Committee is responsible for ensuring a high level of quality and consistency amongst all published specifications, and that all relevant perspectives and use cases are given due consideration.
[…] Core Committee members are expected to consider the impact of their actions on the PHP ecosystem as a whole when acting in their capacity as a Core Committee member

Sorry Matthew, honestly, I cannot remember one relevant comment off the cuff, where you have considered the impact of PSR-15 on a middleware framework other than your own. IMO that is permissible for an arbitrary WG member, but not for the Sponsor.

--
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/01ff1d6f-7c67-446a-8328-152e9845e8c2%40googlegroups.com.

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

[Sara Golemon]

Rather than spam the list with 11 "me too" messages, the core committee have collectively agreed we would like to endorse Matthew as Sponsor of PSR-15.  All working group members, including the sponsor should be knowledgable about the subject area and mwop unquestionably satisfies this.

The WG structure is designed to minimize the potential for one voice to drown out all others, and we're confident that the process will serve that goal. We look forward to PSR-15's continued development, and encourage all WG members to continue voicing their positions and contributing constructively.

Graham Daniels

Larry Garfield

Sara Golemon

Gary Hockin

Cees-Jan Kiewiet

Samantha Quiñones

Lukas Smith

Korvin Szanto

Chris Tankersley

Stefano Torresi

Beau Simensen