Status of PSR-12 survey

[glen-84]

Hi,

It seems that non-members can no longer access the IRC channel, so I'll ask here: Is there any news WRT the official survey for PSR-12?

IIRC, there was talk about this almost 8 months ago, possibly even earlier than that. PHP 7.1 is already in beta, and we still don't have consensus on things like declare constructs, return type declarations, etc.

Glen.

[Michael Cullum]

Hi Glen,

The PSR-12 team are just finishing off the survey (Emails were circulated about ti just earlier today as it happens), after which it should be in an almost ready to go state. Without making a promise, I'd predict it is possible that it could be in review before the end of August or mid-september, but please don't hold me to that.

Regarding the IRC channel, please make sure you're joining #phpfig on freenode and not #php-fig (which we have no control over because it's under a php namespace which nobody has control of); it is open to non members. If you're continuing to experience issues please email me on in...@php-fig.org.

Thanks,

Michael Cullum

PHP FIG Secretary

--

Michael 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/27667887-3783-497f-9df1-f51265d0ce12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Jones]

> On Jul 31, 2016, at 11:07, Michael Cullum <m...@michaelcullum.com> wrote:
>
> Hi Glen,
>
> The PSR-12 team are just finishing off the survey (Emails were circulated about ti just earlier today as it happens)

The survey -- was is a series of questions about what the respondents would *like* to do, or think *ought* to be done? Or was it about what they are *actually doing* in their PHP 7 projects? If the former, the survey is insufficient; if the latter, I look forward to reading the report.


--

Paul M. Jones
http://paul-m-jones.com

[Michael Cullum]

Hi Paul,

A mix of the two.

As previously stated, this PSR was always going to include a degree of both being prescriptive and being descriptive, most projects do not yet require PHP 7 but for those that do, then of course that will apply, for those that don't it is essentially asking them what decision they would make, were they upgrading their minimum requirement to PHP 7 now: (1) what would they choose out of a series of options (2) would they consciously object to x (x being what we currently include in the specification); this is due to the fact some projects would choose one thing, but not object to other methods (which might make more sense/be more in keeping with other rules in PSR-2 such as the try/catch). It's all about balance.

The fact this PSR would, to a reasonable but not excessive extent, be prescriptive, was a core part of the PSR description in the meta document and premise of the PSR when it passed an entrance vote.

https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide-meta.md#2-why-bother

--

Thanks,

Michael Cullum

(Not speaking formally as a FIG Secretary but as former Editor of PSR-12 inline with my declared conflict of interest on PSR-12)

--
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/A6D1DE62-1A5A-4A90-8393-4D620266B17F%40gmail.com.

[Paul Jones]

> On Jul 31, 2016, at 13:36, Michael Cullum <m...@michaelcullum.com> wrote:
>
> Hi Paul,
>
> A mix of the two.

Well, let's remove one part of that mix, then.

> As previously stated, this PSR was always going to include a degree of both being prescriptive and being descriptive,

Yes, and it's a mistake for it to be so. The better course is to see what people actually do in their own projects, and then collect it, rather than make things up. The place for creation-anew is in individual projects (bottom up) not here in the FIG (top down).

[Paul Dragoonis]

I second this.

I want us to replicate the success of PSR2 which means we need to wait for a significant amount of major projects, that support PHP7 in a stable release, to collect such results.

If the PSR-12 contributors have good reasons to show that we don't need to wait then i would like to hear it.

Cheers,
Paul

>
>
>
> --
>
> Paul M. Jones
> http://paul-m-jones.com
>
>
>

> --
> 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/D980BBCA-30E4-4D83-A2E1-6ADF43C7E39A%40gmail.com.

[Alexander Makarov]

While I agree that it could be a good idea to wait till PHP7 adoption and usage rate will raise, I think that it would be better if PSR-12 current state (master) will reflect what people prefer or like even if they aren't using PHP7 yet. It's definitely better alternative than not being backed up by any statistics.

After the survey proposal will be changed. Then it could be frozen till certain level of PHP7 adoption or not. That's to be discussed later.

[Hari K T]

Hi all, 

Prevention is better than cure.

So I guess it will be good to push than wait for people to write what they want and later argue and wait. I agree with Paul that there can be drawbacks, but we can always change / move to another PSR as we did for PSR-0 to PSR-4 and also erratas.

[Paul Dragoonis]

On 31 Jul 2016 8:28 p.m., "'Alexander Makarov' via PHP Framework Interoperability Group" <php...@googlegroups.com> wrote:
>
> While I agree that it could be a good idea to wait till PHP7 adoption and usage rate will raise, I think that it would be better if PSR-12 current state (master) will reflect what people prefer or like even if they aren't using PHP7 yet. It's definitely better alternative than not being backed up by any statistics.
>
> After the survey proposal will be changed. Then it could be frozen till certain level of PHP7 adoption or not. That's to be discussed later.

This is a fair compromise

> To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/70a8d8bb-47cd-459f-b8cf-8b2bb3c0e6a2%40googlegroups.com.

[Andrew Carter]

The objection to being prespective rather than descriptive makes absolutely no sense - and I couldn't disagree any more.

All of the projects in this group writing PHP 7 code will (hopefully) need to develop their own style guide anyway - save the work, and create one together now.

Don't wait for the community to diverge on this because that creates an absolute mess when it comes to merge conflicts on pull requests.

[Chris Tankersley]

On Sun, Jul 31, 2016 at 6:01 PM, Andrew Carter <andrewca...@gmail.com> wrote:

The objection to being prespective rather than descriptive makes absolutely no sense - and I couldn't disagree any more.

Which is the intent of the FIG? To provide an after-the-fact decision on how things should work, like the RFC process, or provide details on how things should work _before_ there is widespread adoption, more akin to the ISO process?

PSR-1 and PSR-2 took the former approach, and was based upon a general usage of what projects had been doing.

I'd argue that historically we should do the same. 

 

All of the projects in this group writing PHP 7 code will (hopefully) need to develop their own style guide anyway - save the work, and create one together now. 

So do we want to take the risk on creating a standard that might be different than what the rest of the development community ultimately decides to do?

 

Don't wait for the community to diverge on this because that creates an absolute mess when it comes to merge conflicts on pull requests.

On Sunday, July 31, 2016 at 3:35:12 PM UTC+1, glen-84 wrote:

Hi,

It seems that non-members can no longer access the IRC channel, so I'll ask here: Is there any news WRT the official survey for PSR-12?

IIRC, there was talk about this almost 8 months ago, possibly even earlier than that. PHP 7.1 is already in beta, and we still don't have consensus on things like declare constructs, return type declarations, etc.

Glen.

--

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/4ab014d8-8678-45d4-a269-fc212d8f7f97%40googlegroups.com.

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

--

Chris Tankersley
http://ctankersley.com

[Andrew Carter]

Some projects still don't use PSR-2 because of the hell involved in changing style guide mid project when you have hundreds of pull requests. PSR-2 didn't have the option of being prescriptive.

The job of the FIG is to solve problems by working together?

These projects are the community, so if they all work together creating one now - there's the best chance of acceptance. The more code written with custom style guides - the less likely this standard will achieve acceptance amongst the bigger projects.

All projects here will need a PHP 7 style guide. Just make one together now rather than all making different ones.

I've got nothing else to add so self throttling. Maybe this is the sort of thing voting members need to be surveyed on (prescriptive or descriptive).

[Larry Garfield]

On 08/01/2016 01:32 AM, Andrew Carter wrote:
> Some projects still don't use PSR-2 because of the hell involved in changing style guide mid project when you have hundreds of pull requests. PSR-2 didn't have the option of being prescriptive.

Additionally, the "lowest common denominator only" approach of PSR-2 led
to inconsistencies that still hinder its adoption. (The confusing and
inconsistent braces placement is *the* number 1 reason why Drupal still
refuses to adopt PSR-2, even moreso than the massive impact on the
codebase and community that such a change would entail.) Simply rubber
stamping a plurality survey does not lead to a consistent and coherent
spec, which is what we should be striving to achieve.

> The job of the FIG is to solve problems by working together?
>
> These projects are the community, so if they all work together creating one now - there's the best chance of acceptance. The more code written with custom style guides - the less likely this standard will achieve acceptance amongst the bigger projects.
>
> All projects here will need a PHP 7 style guide. Just make one together now rather than all making different ones.
>
> I've got nothing else to add so self throttling. Maybe this is the sort of thing voting members need to be surveyed on (prescriptive or descriptive).

Also quoting from Chris Tankersley:

> Which is the intent of the FIG? To provide an after-the-fact decision
on how things should work, like the RFC process, or provide details on
how things should work _before_ there is widespread adoption, more akin
to the ISO process?

In practice, a balance between the two. That is informally the case
now, and FIG 3's mission statement makes that explicit. We should not
be inventing things entirely from whole cloth, but that doesn't mean we
are bound exclusively to "what's been done already we can rubber stamp",
either.

PSR-0 was similar to the PEAR convention, but as no one was using
namespaces yet it was still forward-looking, based on experience.

PSR-3 was closely based on Monolog, but also pulled in a tokenizing
system inspired by Drupal, but using a syntax that was more Twig-esque
than either system.

PSR-4 was based on a feature request, but no one was using "truncated"
paths yet at that point. It was new, innovative, and controversial, but
the right call.

PSR-6 was developed essentially in parallel with Stash.

PSR-7 was naturally inspired by both HttpFoundation and Zend Framework's
Request library, but the use of a mostly-immutable design was fairly new
and neither major HTTP library at the time was already doing that. It
was still a good call, however, despite being "innovative".

We absolutely should gather data on what projects are already doing
already (for PSR-12 or for anything else), but it is grossly negligent
to say that we must be enslaved to the result. Producing a good spec is
more important than producing a legacy-centric spec. Historically,
that's almost always been our approach, and should remain so.

And now we've repeated in this thread the same conversation we've had
about PSR-12 every time it's come up, to the same result.

--Larry Garfield

[Alexander Makarov]

We hear you. We'll collect as much data as we can. Then will build a PSR based on the data collected but not only the data collected.

[Korvin Szanto]

Hi All,

Sorry for being a little late to this party, FIG has me a little exhausted at the moment to say the least. I agree with pretty much all of the opinions and responses in this thread other than the ones saying we should wait or that we should use the survey result as gospel. We are still moving forward with our plans to do a survey (As Paul recommended and campaigned for) and we will use our brains to decide what the best options are based on that survey.

It's just a matter of shaving off time and focus for me, I'm working on getting to that point but life has been hectic. I think Michael's "before the end of august" is a good estimate that we are shooting for.

Paul, I really appreciate the amount of energy you're putting into the PSR-12 discussion. We've already decided to do a more thorough survey based on your feedback, however we will not concede to waiting or to deciding on the final content of PSR-12 strictly based on a survey. Instead, we will send out the survey and will use the results to determine the best content for PSR-12. Once that is over and done with you can express your opinion on the matter through a vote.

Best wishes,

Korvin

--

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/47d8c9a9-2b1d-4316-895c-3a17c775a4e0%40googlegroups.com.

[glen-84]

Thanks for the replies, and the info regarding the IRC channel.

I agree with those who suggest a two-step process:

1. Run a survey now to get an initial idea of what the community is thinking and what they are either using now, or plan to use when upgrading to PHP7.
    PRO: The PSR will be updated to represent the *current* consensus of the community, even if that is not yet set in stone.
    PRO: The community will have something to start with if they're creating PHP7 projects now or in the short to medium term. They will not have to wait 5+ years (or however long it takes to gather sufficient data from PHP7 projects).
2. After enough time has passed (IMHO it's going to be quite a long time), analyse the data from member projects and compare that with the data from the initial survey. In cases where consensus is unclear, additional individual polls could be run. Release PSR-12 after the dust has settled.
    PRO: The final PSR would be based on real data from existing projects.
    PRO: The process would not be rushed, and there would be more time for clarifications and polishing.

It's the best of both worlds in my opinion.

I have two other questions, if I may:

1. I had assumed that non-voting members would have a say in these surveys – is that not true? I think that public voting has a place, even if our votes are given less weight.

2. In cases where the result of a single item of the survey is unclear (let's say 65% or less on one side), what is the process? I don't think that it's wise to prescribe something unless there is a fairly large consensus. In the extreme, if something ends at 50/50, I think that it's best not to include it in the PSR.

Thanks.

[Larry Garfield]

For a *vote* on a PSR, only voting reps from member projects can vote.
That's the definition of project voting rep. :-)

For a *survey* those are non-binding data-gathering tools. Generally
they've been open to anyone but we track what voting reps in particular
are saying.

For the survey in this case, it's not really a "poll the audience"
situation but "what is Drupal doing about X, what is PHPBB doing about
X, what is Zend Framework doing about X", so individual preferences of
people aren't the subject being surveyed. So voting rep status isn't
really relevant.

> 2. In cases where the result of a single item of the survey is unclear
> (let's say 65% or less on one side), what is the process? I don't
> think that it's wise to prescribe something unless there is a fairly
> large consensus. In the extreme, if something ends at 50/50, I think
> that it's best not to include it in the PSR.

As has been discussed, the survey is NOT a binding vote. It's a data
gathering tool only to inform an intelligent decision by the spec
authors and FIG membership. I don't think we can make a blanket
statement about what percentage result means what. Let's just get the
data before we make any decisions on anything. :-)

--Larry Garfield

[glen-84]

Thanks for the clarification, but I don't really follow the logic. "what is Drupal doing about X" doesn't seem to preclude "what is the public doing about X", unless the public are specifically excluded from such surveys. Yes, Drupal is a group of devs, but the public often represent groups as well (company development teams, etc.).

Public data may show up something unexpected, or at the very least back up the data seen in internal voting.

I guess I'm failing to see what the downside is.

Regardless: Will the data be made publicly available?

(I guess that's my quota of 2 posts for the day!)

[Paul Jones]

> On Aug 3, 2016, at 09:07, glen-84 <gle...@gmail.com> wrote:
>
> Thanks for the clarification, but I don't really follow the logic. "what is Drupal doing about X" doesn't seem to preclude "what is the public doing about X", unless the public are specifically excluded from such surveys. Yes, Drupal is a group of devs, but the public often represent groups as well (company development teams, etc.).

The driving idea behind FIG is for it to find commonalities between the projects its voting members represent, not in the wider world of all of PHP land. (Some members here wish to broaden FIGs approach to encompass all of PHP land, which is the sort of scope-creep I oppose.)

> Regardless: Will the data be made publicly available?

Keeping the data private would look very bad. With PSR-2, I appended the data and analysis to the document itself.

[Alexander Makarov]

We won't keep survey data private for sure. It will be in the meta.

PSR-1 and PSR-2 went far beyond FIG-member projects so I guess PSR-12 could be alike in terms of scope.