PHP-FIG public relations

[Patrick Mulvey]

Hi everyone,

Anyone tuned in to the fig-standards repo on GitHub will by this point have noticed a deluge of comments on issue #35 within the last 24 hours. Many of these have a negative or even angry tone, accusing PHP-FIG of being a dictatorial group intent on forcing poorly-written standards on the wider PHP community. Most of us here will be (justifiably) inclined to dismiss these comments as being comically misinformed and childish, but I think they indicate a real problem facing this group. 

Based on the comments seen on GitHub issues and some of the proposals that have been made recently, it seems that there are a lot of developers out there who are reading the PSRs but not understanding their purpose and scope. I think it is worth doing something about this - these endless misguided comments and proposals are a distraction, and are arguably damaging to the public profile of the group. We need to improve public relations to combat this.

The php-fig.org website does clearly explain the purpose of the group, but evidently there are many developers who are not seeing this. This is not entirely surprising, as the other public faces of this group (GitHub and this mailing list) don't link to the website or provide any kind of introductory message. So here's what I think we should do:

• Link to the website from the README in the fig-standards repo on GitHub
• Create a "Proposing Standards" or similarly titled page on the website, explaining in detail the types of proposals that are appropriate for PHP-FIG, and link to this from the README
• If possible, create a sticky post on this mailing list to welcome newcomers and explain the purpose of PHP-FIG
• Pass a new bylaw requiring that every new PSR contains a link to the website

These are fairly easy steps for us to take, and they should make it easier for developers to find information and understand the function of PSRs. By properly educating the general community about what we're trying to do, we should be able to prevent the kind of distracting and misguided commenting seen on GitHub today and in the past.

See also: fig-standards issue #57

[Tim Otten]

This problem description is good, and the proposed measures seem concreate and helpful in addressing arguments about "process"  (e.g. is the PHP-FIG process democratic? meritocratic? politically-correct? politically-necessary? some combination thereof?)

However, perhaps this needs to go a level further? Consider that the audience for programming standards is disproportionately intelligent, detail-oriented, independent-minded, and (politically) tone-deaf. Moreover, standardization focuses on issues that invite conflict. The indentation conflict is perhaps the worst-case, but I think it's a deeper issue that stems from how one selects problems for standardization. (The problem must already have competing solutions -- solutions whose differences may be very important to a minority and largely irrelevant to a majority.) Taken together, this means standards development requires persuasion.

The PHP-FIG's publications have focused on decidedly technical details (symbol names, punctuation, functionality) which is great for implementers -- but totally neglects rhetoric and the needs of persuasion. True, one can find ample rhetoric/persuasion by reading the email archive, but that's unrealistic: even php-fig members have trouble following all the discussion on the list -- how can one expect an outsider or newcomer to understand an archived 6 month-long discussion?

Fortunately, on some occasions, a few people have done a good service in the middle of the discussion -- by writing a summary of the issues, ideas, alternatives, questions, decisions, etc. I believe this editorial work helps build consensus before ratification -- and (if suitably published) would extend consensus after ratification. It can be hard, time-consuming work, but doing this work will add legitimacy to the final standard.

TL;DR -- If you work on developing a standard, it is in your interest to have a rapporteur maintain a summary of the key discussions and most persuasive arguments. The summary should be developed, ratified, and published alongside the standard. In the eyes of potential adopters, it will legitimize your work.

--
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/msg/php-fig/-/FhMY5GBuTkcJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Hari K T]

Hi guys,

Patrick Mulvey your thoughts are good. But let us wait and promote the Yet another cache proposal

https://groups.google.com/d/msg/php-fig/VRUEzicwjb8/4Vu1YOyRNQEJ

So that we don't have too much noise and the members can concentrate and move it forward.

Assuming the move of Symfony to release 2.3 which will be LTS, and if this proposal can be pushed some how, it will be a gain for them and the PSR itself, than waiting for many long years .

So please make it fast considering all adoptions in the earliest.

Thank you.

Hari K T
M: +91-9388758821 | W: http://harikt.com/blog

[Andrew Eddie]

Patrick I think those suggestions are fine. Regarding any bylaw change, I think there's a few other things we can do better on as well, but maybe that's for another thread.

Regarding the thread in question, the reality is the people are taking this group seriously (which is actually a good thing) and, like it or not, we are imparted with the perception of some authority. Even if we don't want it, and it's enormously frustrating at time, it's going to stick. There are always going to be hot heads - it goes with the territory and you'll never prevent it. But for me it highlights an area of a PSR that is particularly inflexible when it doesn't need to be (in my opinion) and we should be open to review our standards from time to time.

As already mentioned, it would also be helpful to have a better way to track new PSR's that are under discussion.

Regards,

Andrew Eddie

[Ryan Parman]

The biggest issue is that we refer to them as "standards". They're not. They're "recommendations".

Changing our terminology in this area would, IMO, go a long way toward helping people understand.

--

Ryan Parman

Geek. Writer. Music Lover.

http://ryanparman.com

"Illiteracy will not be defined by those who cannot read and write, but by those who cannot learn and relearn." — Alvin Toffler

--
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/msg/php-fig/-/FqN6WtaczeoJ.

[Andreas Möller]

> The biggest issue is that we refer to them as "standards". They're not. They're "recommendations".
>
> Changing our terminology in this area would, IMO, go a long way toward helping people understand.

Well said, well said.

Those people having issues with adopting these recommendations have yet got to travel a bit further down the road to understand why they make sense.

Fighting them doesn't make any sense. Just have a look at their tone. It's awful.


Best regards,

Andreas

[Ryan Parman]

Agreed, but we need to remember that we're just starting to adopt these recommendations as a community pretty late in the life of the language, comparatively.

Java and C# are pretty settled. Pythonistas argue about 2.x vs. 3.x. Rubyists argue about the web server software of the week. I don't recall seeing these sorts of arguments in the JavaScript community when things like CommonJS were forming.

We've been the "wild west" for far too long, and now we're experiencing growing pains. By changing the language from "you must" (i.e., standards) to "we think you should, and here are the benefits" (i.e., recommendations), I think we'll see less push-back from the great unwashed masses.

We say "standards", they say "who made you king?" We say "most of the representative projects", they say "well, you didn't ask me!". Their inherent misunderstanding is simply exacerbated by our presentation of the ideas. If we present better, they'll respond better.

> --
> 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.

[Matthieu Napoli]

I think the fact that all discussions and decisions happen on that mailing list are part of the problem. It's not hidden, but it's mixed up with github.

These people see the tip of the iceberg on github: they just see standards written, PR denied or ignored, etc... which is OK, that's how it works: through the mailing list. But that's not clear enough. For example for me it took me a (useless) PR to understand that nothing was going to happen on github, everything should be discussed here.

That's confusing, and it make it looks like indeed the group is closed to the outside. People are expecting to discuss things on github because they are used to the github process (issues, PR, fork, ...).

So what I suggest is:

- make it very more clear that all discussions should happen on the mailing list. Even repeat that message on each PR (or issue) when they are created.

- maybe even disable the "Issues" on github? (if every discussion is to happen here anyway)

- have a public summary of discussions, votes and decisions (yes that is some work): I was completely against PSR-2, tabs VS spaces, etc... But then I re-read the discussions and understood why. And now I'm at peace. It just felt like discussions never happened and decisions were taken arbitrarily before I could see it wasn't the case

Or else move every discussion and vote to github, but is that even possible? (I don't think so, but that's a possibility worth mentioning I believe)

Matthieu

[justin]

Adding a CONTRIBUTING.md file to the repo would probably help with this, since it adds a yellow notice to the top of the "new issue" and "new pull request" forms:

--j

--

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/msg/php-fig/-/42VySZHp4s0J.

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

--
http://justinhileman.com

[Matthieu Napoli]

Furthermore, quoting from the repo's README:

To propose a standards recommendation (PSR):

• fork this repo, create a branch, checkout that branch, add the PSR in proposed/, push the branch to Github, and send a pull request; or,

• create a ticket to start a discussion on Github; or,

• start a conversation on the mailing list.

I think this is misleading because tickets on github will get you nowhere (everything happens on the ML)

And +1 to adding a CONTRIBUTING.md

[Ryan Parman]

Great ideas.

I also think it would be useful to include the relevant discussion links that led to the decisions. Collecting these links would be the responsibility of the person driving the discussion/motion.

For example, the discussions which led to PSR-3:

* https://groups.google.com/d/topic/php-fig/yL_wDyiT6GY/discussion[1-25-false]

* https://groups.google.com/d/topic/php-fig/eAeeONMGH8g/discussion[1-25-false]

* https://groups.google.com/d/topic/php-fig/r85O6ucEBWE/discussion[1-25-false]

* https://groups.google.com/d/topic/php-fig/d0yPC7jWPAE/discussion[1-25-false]

Perhaps these could go into a "See Also" or "Pre-vote Discussion" errata section. Essentially, the primary discussions starting with the proposal and ending with the vote which accepted the PSR.

(PSR-1/2 would start with the first discussion, include the failed vote, the split, and the new vote for each one.)

Providing this context to those who are genuinely interested in learning could really help.

On Feb 26, 2013, at 12:52 AM, justin <jus...@justinhileman.info> wrote:

Adding a CONTRIBUTING.md file to the repo would probably help with this, since it adds a yellow notice to the top of the "new issue" and "new pull request" forms:

<image.png>

--j

[Andrew Eddie]

In terms of public relations, I think it's extremely unhelpful that the reply is becoming "if you don't like PSR-2, just ignore it", even from voting members. What are we trying to say? PSR-2 is set in stone until the age where AI's write our software? Only someone who sits on the "average" line will count?

I would hope that this group chooses to be a little more progressive than ratifying what most people do (standard by survey, anyone can do that?). In my view it would be far better to strive to see how we can bring the PHP community closer together. Are there ways that we can bring eZ, Drupal, Joomla and others over the line with PSR-2 by introducing some flexibility? Or was the vote the vote and we don't give a flying fig (pun intended) about it anymore.

Like it or not, there are people looking at the PSR's seriously and it's causing tensions within vendor communities. You don't have to bow to everyone's demands, by all means ignore those that are rude and indignant (and that's sugar coating it), but people should feel they are able to have a say and that the voting members take their responsibilities seriously and listen to them.

Regards,
Andrew Eddie

[Andrew Eddie]

Seems like I have my answer.

https://github.com/php-fig/fig-standards/pull/35#issuecomment-14140528

Regards,
Andrew Eddie

[Jordi Boggiano]

I don't have much time here, nor do I want to spend much time discussing
this, but here are my two cents.

The only way I think we can get out of this mess for good is having a
new PSR which is PSR-2 with tabs.

Then everyone will be able to pick between PSR-2 and PSR-N as the coding
style they want to recommend. Either being fine by us, as long as people
remain consistent within their own project I don't see why anyone would
give a damn which of the two they use?

Can someone that cares about tabs push this forward or am I not making
any sense here?

Cheers

--
Jordi Boggiano
@seldaek - http://nelm.io/jordi

[Lukas Kahwe Smith]

we did deal with this. the solution was to split of pieces into a storage PSR, this the creation of PSR-2. this stuff is hard enough as is. I think this so who were in favor probably didn't see any improve lent possible by trying to innovate. In the end CS is 80% arbitrary, maybe even more so for all the things we split off into PSR-2.

there were the following options:
- drop everything that went into PSR-2 entirely
- make everything optional
- ratify it as it was in the end

IMHO the first 2 options didn't make sense. there are enough existing projects that were able tipi adopt it. there are plenty of new projects that benefit from the added details. the second option would just be a smoke screen. a standard that makes everything optional is just giving the illusion of a standard.

now I do not have a problem with competing/overlapping PSRs if enough people think they also want to create a CS with tabs or whatever. that being said IMHO with all due respect we have more exciting stuff to work on.

regards
Lukas

Andrew Eddie <mamb...@gmail.com> wrote:

In terms of public relations, I think it's extremely unhelpful that the reply is becoming "if you don't like PSR-2, just ignore it", even from voting members. What are we trying to say? PSR-2 is set in stone until the age where AI's write our software? Only someone who sits on the "average" line will count?

I would hope that this group chooses to be a little more progressive than ratifying what most people do (standard by survey, anyone can do that?). In my view it would be far better to strive to see how we can bring the PHP community closer together. Are there ways that we can bring eZ, Drupal, Joomla and others over the line with PSR-2 by introducing some flexibility? Or was the vote the vote and we don't give a flying fig (pun intended) about it anymore.

Like it or not, there are people looking at the PSR's seriously and it's causing tensions within vendor communities. You don't have to bow to everyone's demands, by all means ignore those that are rude and indignant (and that's sugar coating it), but people should feel they are able to have a say and that the voting members take their responsibilities seriously and listen to them.

Regards,
Andrew Eddie

--

[Lukas Kahwe Smith]

I think if enough people think it makes sense more power to them. or they can just say we are compliant with PSR-2 but with tabs. problem solved.

regards
Lukas

Jordi Boggiano <j.bog...@seld.be> wrote:

[Jordi Boggiano]

On 26.02.2013 22:43, Lukas Kahwe Smith wrote:
> I think if enough people think it makes sense more power to them. or they can just say we are compliant with PSR-2 but with tabs. problem solved.

That's like saying we are compliant but we aren't. It's as confusing as
the "every optional" option you just mentioned in your previous mail.

But since it seems the tabs really are the main point of disagreement
(the rest of the spec really has no argumentation possible, it's pretty
much arbitrary decisions), I think a PSR-2-TAB-EDITION would make sense.

[Florin Razvan Patan]

Would it make sens just to amend the current PSR2 to say 4 spaces or 1 tab with 4 sppaces width? Or similar. That way we could finally finish this out and focus on so many other things that need more energy :)

[David Zülke]

THE WIDTH OF TABS DOES NOT MATTER. That's what most people in favor of spaces don't even understand. You use tabs for indent and spaces for alignment, and then your code always looks tidy, whether your tab width is 2 or 4 or 8 or 16 spaces.

[David Zülke]

While we're at it, we could re-number the PSRs so PSR-0 is the index of PSRs like Python does it (and like I suggested from the very beginning). And introduce informational and standards PSRs and make the coding style ones "informational".

One can always dream, right?

[Andreas Möller]

> Can someone that cares about tabs push this forward or am I not making
> any sense here?

Does anyone actually know anyone using tabs?


Best,

Andreas

[Andreas Möller]

> THE WIDTH OF TABS DOES NOT MATTER. That's what most people in favor of spaces don't even understand. You use tabs for indent and spaces for alignment, and then your code always looks tidy, whether your tab width is 2 or 4 or 8 or 16 spaces.

Mixing tabs and spaces is a big PITA, and no, you just shouldn't do it.

If you need to indent and space out for alignment, you've got other issues. Deal with them first.


Best,

Andreas

[Andreas Möller]

> But since it seems the tabs really are the main point of disagreement
> (the rest of the spec really has no argumentation possible, it's pretty
> much arbitrary decisions), I think a PSR-2-TAB-EDITION would make sense.

I disagree.

For people who want to use tabs, go ahead and use them and be happy with it. But it's not PSR-compliant.


Best,

Andreas

[Tim Otten]

On Feb 26, 2013, at 4:28 PM, Andrew Eddie wrote:

In terms of public relations, I think it's extremely unhelpful that the reply is becoming "if you don't like PSR-2, just ignore it", even from voting members. What are we trying to say? PSR-2 is set in stone until the age where AI's write our software? Only someone who sits on the "average" line will count?

+1

The attitude of "if you don't like it, ignore it" is unhelpful and unnecessary. The group made its recommendations after rigorous deliberations -- showcase all the insight that went into the recommendation. Communicate the merits of the recommendation. Use an official FAQ or white-paper or report or wiki or blog post or bibliography or whatever -- but somehow publicize a cogent, detailed argument in support of each PSR. It demonstrates respect for oneself and one's audience.

I would hope that this group chooses to be a little more progressive than ratifying what most people do (standard by survey, anyone can do that?). In my view it would be far better to strive to see how we can bring the PHP community closer together. Are there ways that we can bring eZ, Drupal, Joomla and others over the line with PSR-2 by introducing some flexibility? Or was the vote the vote and we don't give a flying fig (pun intended) about it anymore.

Like it or not, there are people looking at the PSR's seriously and it's causing tensions within vendor communities. You don't have to bow to everyone's demands, by all means ignore those that are rude and indignant (and that's sugar coating it), but people should feel they are able to have a say and that the voting members take their responsibilities seriously and listen to them.

Regards,
Andrew Eddie

[Jordi Boggiano]

Same as was said to the tabs fans, if you don't like tabs don't use
them, but please don't piss on the others and don't try to argue with
their choice. Let's leave it at to each his own.

> For people who want to use tabs, go ahead and use them and be happy with it. But it's not PSR-compliant.

Why? We picked one because it was representing the majority of the
projects, but now we end up with half the projects ignoring the whole
thing because of the indenting rule. By having a new PSR we would allow
everyone to follow the same spec, yet choose about the indenting they
want to use. Right now we throw people out and they end up having to
make up their own standards.

[Florin Patan]

I've submitted this PR https://github.com/php-fig/fig-standards/pull/91 in order to change the current PSR-2 and stop all this drama.

Since I'm not a member of PHP-FIG, I ask one to champion this and propose it to voting.

If there's anything else to fix on this, let me know or send a PR.

Best regards,

Florin

[Patrick Mulvey]

If we're going to discuss the relative merits of tabs and spaces, I suggest moving the conversation to a new thread in the CS mailing list.

[David Zülke]

$foo = array(
"bar" => "baz",
"trololo" => "ohai",
);

Tabs for indent, spaces for alignment, code looks proper no matter the tab size, problem solved.

And as an added benefit, it's more accessible, because users with impaired vision or dyslexia can crank up the tab size to something that's more comfortable to them in relation to font size and/or line spacing.

But why would you care, you've been busy diagnosing issues I apparently have.

David

[Larry E. Masters]

I've submitted this PR https://github.com/php-fig/fig-standards/pull/91 in order to change the current PSR-2 and stop all this drama.

Since I'm not a member of PHP-FIG, I ask one to champion this and propose it to voting.

If there's anything else to fix on this, let me know or send a PR.

I have brought it up for vote. Lets end discussion and move on. Simple...

--

Larry E. Masters

Founder CakePHP

[Andrew Eddie]

On 27 February 2013 08:07, Florin Patan <flori...@gmail.com> wrote:

I've submitted this PR https://github.com/php-fig/fig-standards/pull/91 in order to change the current PSR-2 and stop all this drama.

Since I'm not a member of PHP-FIG, I ask one to champion this and propose it to voting.

If there's anything else to fix on this, let me know or send a PR.

Florin, I'm happy to run with it (I have some other smalls tweaks to PSR-2 I'd like to see as well), as long as it's going to be taken seriously by the group. Makes me wonder if change is even possible when members start trolling their own discussions ...

But, assuming I'm not wasting my time, as a matter of process, what happens here? Is the PSR just amended (do we semver it to 2.1?) or do we cancel PSR-2 and make a new PSR-4? I think my preference would be to use semver but it's not a hill I want to die on.

Thanks in advance.

Regards,

Andrew Eddie

[Florin Patan]

Thankfully Larry Masters, opened the voting poll for this, thank you Larry!

I know it's about majority, at least almost always, but in this case I do believe that the minority should be equally treated as well.

If the only make or break point for PSR-2 is the tabs vs spaces, I don't see why the majority would want to impose such a thing that's causing more pain in the rear that problems solved.

Please, all voting members, approve this so that FIG can move on to better things, the folks using the PSR-2 can use it forward and those that would like tabs be happy and have tabs and be able to use PSR-2 in their projects.

Best regards,

Florin

[Andreas Möller]

> Same as was said to the tabs fans, if you don't like tabs don't use
> them, but please don't piss on the others and don't try to argue with
> their choice. Let's leave it at to each his own.

Exactly. If you don't agree with a recommendation, go and use your own. That's what's being said all the time, and I'm totally fine with it.

However, it took a while to get these through, and I don't see any reason to water them down.

The only person that ever came up with an explanation for using tabs, that is, an explanation you can't argue with, was someone who had visibility issues.

>> For people who want to use tabs, go ahead and use them and be happy with it. But it's not PSR-compliant.

Because that's not what the recommendations say.

> Why? We picked one because it was representing the majority of the
> projects, but now we end up with half the projects ignoring the whole
> thing because of the indenting rule. By having a new PSR we would allow
> everyone to follow the same spec, yet choose about the indenting they
> want to use. Right now we throw people out and they end up having to
> make up their own standards.

Why? They could just as well use the aforementioned recommendations, except for using tabs instead of spaces.

What will be next?

And then?

"Hey, it it works, it's PSR-compliant!"


Best,

Andreas

[Jeremy Mikola]

On Tuesday, February 26, 2013 4:54:21 PM UTC-5, David Zülke wrote:

THE WIDTH OF TABS DOES NOT MATTER.

This line has been on my mind since I read through the thread last night. PSR-2 also has a line (directly after the directive to use spaces) that says:

There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less.

I'm not sure what the difference between hard and soft limits are, but if tab widths are completely up to the user, how can these limits be universally acknowledged? Perhaps that's not a problem since there "must not be a hard limit", but it makes the 120 and 80 character suggestions irrelevant. Just something to bear in mind if we go the route Jordi suggested and create a mirror PSR for tabs (I think the line quoted above will either need to be tossed or reworded quite a bit).

[Andrew Eddie]

On 27 February 2013 08:42, Jeremy Mikola <jmi...@gmail.com> wrote:

There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less.

That's something I've already queried but there are only two people bothering to watch the CS list (oh the irony). Given a chance, there may be an opportunity to clean that up as well.

Regards,

Andrew Eddie 

[Andreas Möller]

> Tabs for indent, spaces for alignment, code looks proper no matter the tab size, problem solved.

Depends on what your definition of proper is.

Mixing tabs and spaces causes more problems than it solves.

I don't see what problem you are solving when aligning.


Andreas

[Andrew Eddie]

Guys, can we at least abide by one decision, that that's to keep the detail of CS discussions on the CS list?

Regards,
Andrew Eddie

[Andreas Möller]

> Guys, can we at least abide by one decision, that that's to keep the detail of CS discussions on the CS list?

Doesn't seem like there's anything going on there, to be honest.


Andreas

[Paul Jones]

On Feb 26, 2013, at 5:04 PM, Andreas Möller wrote:

>
>> Guys, can we at least abide by one decision, that that's to keep the detail of CS discussions on the CS list?
>
> Doesn't seem like there's anything going on there, to be honest.

Ladies and gentlemen,

If you are interested in coding style discussions, please join the CS group here:

https://groups.google.com/forum/#!topic/php-fig-cs/


-- pmj

[Andrew Eddie]

On 27 February 2013 09:07, Paul Jones <pmjo...@gmail.com> wrote:

Ladies and gentlemen,

If you are interested in coding style discussions, please join the CS group here:

https://groups.google.com/forum/#!topic/php-fig-cs/

Or this link if the above doesn't work for you:

https://groups.google.com/forum/#!forum/php-fig-cs 

Regards,

Andrew Eddie

[Jason Judge]

Where is the CS list? I'm "here", and I can't see a way "there". It is kind of easy to get lost here with lists here and there, pull requests and discussions seemingly all over the place.

[Andrew Eddie]

On 27 February 2013 10:09, Jason Judge <jason...@consil.co.uk> wrote:

Where is the CS list? I'm "here", and I can't see a way "there". It is kind of easy to get lost here with lists here and there, pull requests and discussions seemingly all over the place.

[Jason Judge]

Thanks. I wasn't trying to be funny about that, and I guess it is difficult when using Google Groups, as you have no control over the menus and navigation.

[Andrew Eddie]

On 27 February 2013 10:47, Jason Judge <jason...@consil.co.uk> wrote:

Thanks. I wasn't trying to be funny about that, and I guess it is difficult when using Google Groups, as you have no control over the menus and navigation.

No problem. Been there, done that, ripped the t-shirt in frustration.

Regards,

Andrew Eddie 

[Paul Jones]

I suddenly have this image of Andrew Eddie "Hulking out" in front of his keyboard.


-- pmj

[Andrew Eddie]

On 27 February 2013 10:58, Paul Jones <pmjo...@gmail.com> wrote:

I suddenly have this image of Andrew Eddie "Hulking out" in front of his keyboard.

Heh, it's a common problem in Australia :P

Regards,
Andrew Eddie

[Ryan McCue]

Andreas M�ller wrote:
> Why? They could just as well use the aforementioned recommendations, except for using tabs instead of spaces.

There's some sort of notion with certain developers that if you're not
PSR compliant, you're an idiot/your project is worthless/etc. I've
looked into changing my code personally to fit PSR-1 and PSR-2 but
haven't done so yet, and yet I get berated for not doing so.

SimplePie, e.g., is mostly compliant (excluding some `var` declarations
and missing visibility declarations for backwards compatibility), but
uses tabs instead of spaces. I don't plan on switching to spaces any
time soon, but I'd be happy to fix the majority of the rest up. I don't
see it as a big issue though.

Even more insane are the people that recommend changing huge codebases
simply to be compliant. Take for example WordPress, where we had an
issue filed that wanted us to change to PSR-2. WordPress has an
established coding standard already, and we have nothing to gain from
changing. It would be a huge change that would touch every part of
WordPress (tabs -> spaces, { -> \n{, etc) so the pain much outweighs the
gain). Yet, people still debate with me on the "merits" of switching.

I agree with Ryan Parman that it should be clarified that these are
recommendations, not standards. If I want to adhere to them in my work,
that's my choice, and deviating from it is not an "evil" thing.

(Apologies if this is a little incoherent, I'm low on sleep and short on
time.)
--
Ryan McCue
<http://ryanmccue.info/>

[Andreas Möller]

> There's some sort of notion with certain developers that if you're not
> PSR compliant, you're an idiot/your project is worthless/etc. I've
> looked into changing my code personally to fit PSR-1 and PSR-2 but
> haven't done so yet, and yet I get berated for not doing so.

Well, one can still be an idiot, regardless of whether code is PSR-compliant or not.

> SimplePie, e.g., is mostly compliant (excluding some `var` declarations
> and missing visibility declarations for backwards compatibility), but
> uses tabs instead of spaces. I don't plan on switching to spaces any
> time soon, but I'd be happy to fix the majority of the rest up. I don't
> see it as a big issue though.

That's ok for you, I guess. And it might be ok for people using your code. It might not be ok for people seeking libraries that are PSR-compliant.

> Even more insane are the people that recommend changing huge codebases
> simply to be compliant. Take for example WordPress, where we had an
> issue filed that wanted us to change to PSR-2. WordPress has an
> established coding standard already, and we have nothing to gain from
> changing. It would be a huge change that would touch every part of
> WordPress (tabs -> spaces, { -> \n{, etc) so the pain much outweighs the
> gain). Yet, people still debate with me on the "merits" of switching.

WordPress, as far as I know, has grown from blogging into a CMS. Personally, I wouldn't call it a framework. I know people working for big ventures that use it for building their web applications. I wouldn't.

I'd recognize it as goodwill, if a project underwent changes to become PSR-compliant.

Your project doesn't? I'm unlikely to use it if there are PSR-compliant alternatives.

And that's the point!

> I agree with Ryan Parman that it should be clarified that these are
> recommendations, not standards. If I want to adhere to them in my work,
> that's my choice, and deviating from it is not an "evil" thing.

That's already clarified in the name of the group.

> (Apologies if this is a little incoherent, I'm low on sleep and short on
> time.)

Best,

Andreas

[Ryan McCue]

Andreas M�ller wrote:
> WordPress, as far as I know, has grown from blogging into a CMS. Personally, I wouldn't call it a framework. I know people working for big ventures that use it for building their web applications. I wouldn't.

I'm not saying it's a framework (it's not, IMO), but rather pointing out
that it's seen as a sign of lower quality that it doesn't follow PSRs.

(Aside: WordPress isn't great quality in terms of code. There are tonnes
of legacy and badly written functions, plus downright stupid conventions
in places. Rewriting everything to follow PSR recommendations wouldn't
change anything there.)

> Your project doesn't? I'm unlikely to use it if there are PSR-compliant alternatives.

This is exactly what I mean. Unless you're actually contributing changes
back to me, what does it matter?

Being PSR compliant is *not* an indication of quality, it's merely an
indication that the author chose to follow the recommendations.

What this mindset of "compliance = quality" essentially says is that
even if a project has a high level of usage and reasonably high standard
of quality coding, the fact that it uses tabs over spaces is somehow
relevant to whether someone should use it (not contribute back, but
merely use it).

----

Let's take an example, again from my own projects. Requests [0] is a
HTTP client that I've been developing for quite a while now. Unlike
Guzzle [1], it doesn't follow PSR-1 or PSR-2.

* Guzzle is object-oriented, whereas Requests uses objects but the main
request API is via a static method on a container class.

* Guzzle is based around using REST APIs; Requests is just a HTTP client.

* Guzzle requires PHP 5.3+; Requests requires PHP 5.2+

As an end user, whether or not Requests/Guzzle follows PSR-1/PSR-2 makes
no difference [*] to me unless I'm contributing back to the project.

[*]: The only thing that may affect me is whether the method names I'm
calling are semiCamelCased or underscore_cased. Typically, I'm going to
be reading the documentation on how to use this thing anyway. That said,
I'm probably going to change Requests to use semiCamelCased methods for
interoperability reasons.

[0]: http://requests.ryanmccue.info/
[1]: http://guzzlephp.org/

[Drak]

On 27 February 2013 07:22, Andreas Möller <a...@localheinz.com> wrote:

> Even more insane are the people that recommend changing huge codebases

> simply to be compliant. Take for example WordPress, where we had an
> issue filed that wanted us to change to PSR-2. WordPress has an
> established coding standard already, and we have nothing to gain from
> changing. It would be a huge change that would touch every part of
> WordPress (tabs -> spaces, { -> \n{, etc) so the pain much outweighs the
> gain). Yet, people still debate with me on the "merits" of switching.

That's simply not true. It's just a single command to convert, made even easier with https://github.com/fabpot/PHP-CS-Fixer

Regards,

Drak

[Andreas Möller]

That's simply not true. It's just a single command to convert, made even easier with https://github.com/fabpot/PHP-CS-Fixer

Given this, the discussion should stop here, I guess. 

Best,

Andreas

[Andrew Eddie]

On 27 February 2013 20:24, Andreas Möller <a...@localheinz.com> wrote:

That's simply not true. It's just a single command to convert, made even easier with https://github.com/fabpot/PHP-CS-Fixer

Given this, the discussion should stop here, I guess. 

(facepalm)

Regards,

Andrew Eddie

[Jason Judge]

That may deal with the mechanics of changing a single file, or many files, but there is really a lot more involved in switching the formatting of an entire project. Even without the resistance of developers, there is metadata in comments that not be processed correctly, many conditional statements that would need {brackets] added to their single-statement actions, etc.

The code may be a lot neater and easier to maintain afterwards, but don't underestimate the pain in the process of getting there, with so many tens of thousands of users and developers not seeking any surprises on the next update.

-- Jason

[Andreas Möller]

> That may deal with the mechanics of changing a single file, or many files, but there is really a lot more involved in switching the formatting of an entire project. Even without the resistance of developers, there is metadata in comments that not be processed correctly, many conditional statements that would need {brackets] added to their single-statement actions, etc.
>
> The code may be a lot neater and easier to maintain afterwards, but don't underestimate the pain in the process of getting there, with so many tens of thousands of users and developers not seeking any surprises on the next update.

The pain is going to be even bigger further down the road.


Best,

Andreas

[Andreas Möller]

> But since it seems the tabs really are the main point of disagreement
> (the rest of the spec really has no argumentation possible, it's pretty
> much arbitrary decisions), I think a PSR-2-TAB-EDITION would make sense.

Jordi, we've not had these discussions just for some tab-obsessed coders to water the results down later, just because they don't seem to get it.


Best,

Andreas

[Drak]

My sentiment exactly - this is NOT useful. We discussed it to death, we decided on spaces - let's please move on. Quasi compromise just for the sake of making peace it not going to work and will open up the next religious debate on braces and so on forever.

Regards,

Drak

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Amy Stephen]

The debate needs to be whether the cost of fending off a religious war like spaces - vs- tabs is worth the value of consistency.

Nothing else matters.

[Andreas Möller]

> The debate needs to be whether the cost of fending off a religious war like spaces - vs- tabs is worth the value of consistency.
>
> Nothing else matters.

To be honest - that's what I felt this debate was all about. Consistency and respect towards the PHP-FIG body, process and decisions.


Best,

Andreas

[Amy Stephen]

This. Especially the last sentence.

There is a lot of good talk on deciding how this should be done in the future. But for now, if there is no rule in the bylaws, it can be handled exactly as Florin is saying.

If that's not ideal for the long run, amend the bylaws to clarify and firm up the process. But for now, in my opinion, this approach is really as "valid" as any.

FIG-PSR can evolve. Nothing wrong with that.

My 2 cents.

On Tuesday, February 26, 2013 3:50:05 PM UTC-6, Florin Patan wrote:

Would it make sens just to amend the current PSR2 to say 4 spaces or 1 tab with 4 sppaces width? Or similar. That way we could finally finish this out and focus on so many other things that need more energy :)

On Feb 26, 2013 11:43 PM, "Lukas Kahwe Smith" <sm...@pooteeweet.org> wrote:

I think if enough people think it makes sense more power to them. or they can just say we are compliant with PSR-2 but with tabs. problem solved.

regards
Lukas

Jordi Boggiano <j.bog...@seld.be> wrote:

>I don't have much time here, nor do I want to spend much time discussing
>this, but here are my two cents.
>
>The only way I think we can get out of this mess for good is having a
>new PSR which is PSR-2 with tabs.
>
>Then everyone will be able to pick between PSR-2 and PSR-N as the coding
>style they want to recommend. Either being fine by us, as long as people
>remain consistent within their own project I don't see why anyone would
>give a damn which of the two they use?
>
>Can someone that cares about tabs push this forward or am I not making
>any sense here?
>
>Cheers
>
>--
>Jordi Boggiano
>@seldaek - http://nelm.io/jordi

[Amy Stephen]

@AndrewEddie - With respect, adding more changes to the mix, beyond dealing with Tabs -vs- Spaces just makes it much harder. IMO, keep it separate, for many it's already feeling like the walls are going to fall around us.

@Andreas - there is a lot of frustration, makes sense, I was responding to a sense that people are "blaming" those who wanted tabs with "taking advantage" of the situation and on the other side, those who "got their way" seem unwilling to consider a change. IMO, the debate the not about which is better, but rather knowing this is a religious war issue, and knowing there is no answer, does this body wish to support that specific guideline. (And, try not to turn on one another in the membership.)

[Andrew Eddie]

On 1 March 2013 22:44, Amy Stephen <amyst...@gmail.com> wrote:

@AndrewEddie - With respect, adding more changes to the mix, beyond dealing with Tabs -vs- Spaces just makes it much harder. IMO, keep it separate, for many it's already feeling like the walls are going to fall around us.

I'm sorry, did I say something?

Regards,
Andrew Eddie

 

[Amy Stephen]

Referring to the additional small changes to PSR-2 you are recommending. I think it could cause an implosion to do more than deal w tabs-and-spaces (although I'm not even certain that'll happen).

[Andrew Eddie]

On 1 March 2013 22:52, Amy Stephen <amyst...@gmail.com> wrote:

Referring to the additional small changes to PSR-2 you are recommending. I think it could cause an implosion to do more than deal w tabs-and-spaces (although I'm not even certain that'll happen).

That would be a discussion to continue on the CS list and those comments were (feels like?) days ago now. At the moment I'm really only interested in expending any remaining energy I have getting the PSR process right. Otherwise, my only remaining interest in PSR-2 is to design a "Voted against PSR-2 and proud of it" t-shirt (I think I'd be able to sell a few), plus follow Larry's advice and just forget the stupid thing even exists. I actually feel quite liberated reaching this state of elevated consciousness :)

Regards,

Andrew Eddie

[Andreas Möller]

That would be a discussion to continue on the CS list and those comments were (feels like?) days ago now. At the moment I'm really only interested in expending any remaining energy I have getting the PSR process right. Otherwise, my only remaining interest in PSR-2 is to design a "Voted against PSR-2 and proud of it" t-shirt (I think I'd be able to sell a few), plus follow Larry's advice and just forget the stupid thing even exists. I actually feel quite liberated reaching this state of elevated consciousness :)

The negative attitude is not necessary, really.

Andreas

[Andrew Eddie]

On 1 March 2013 23:03, Andreas Möller <a...@localheinz.com> wrote:

The negative attitude is not necessary, really.

I apologise - it's late and Amy and I go way back. I'm content to accept we've reach a stalemate and move on. Moving on.

Regards,

Andrew Eddie

[Amy Stephen]

Andrew and I are fine.  Like the t-shirt idea. I really like that he's seeing PSR-2 as more viable. Just worried about the group and heads exploding, there's a lot of frustration, so my comment was made in that light, just to keep it as simple as possible. =)

I can see how my comment seemed out of place given that passed. I'm combing thru the treads to find good ideas on structure. 2-3 days is almost a lifetime for this topic. And, I get it now that this discussion really did move to the CS forum. Made it more confusing still.

[Andrew Eddie]

On 1 March 2013 23:30, Amy Stephen <amyst...@gmail.com> wrote:

I really like that he's seeing PSR-2 as more viable.

Not viable for me at all, but if it is for you, I'm ok with that (our CI server though, may not be so understanding).

Regards,

Andrew Eddie 

[Amy Stephen]

Ok, sorry Andrew. I have not read the CS threads. Misunderstood. Sad if that means the t-shirt is out. But, moving on!

To be honest, I am hearing that most projects have a "flavor" of PSR2 but that no one is completely adopting it. I have no idea if that is true or not but it's possible you are complying as closely as anyone else. Not sure.

But, I've read enough for today. I'm picking up on the tension and it's starting to color how I read things (and not favorably). Time to code. =)

[Larry E. Masters]

On Fri, Mar 1, 2013 at 8:02 AM, Amy Stephen <amyst...@gmail.com> wrote:

Ok, sorry Andrew. I have not read the CS threads. Misunderstood. Sad if that means the t-shirt is out. But, moving on!

To be honest, I am hearing that most projects have a "flavor" of PSR2 but that no one is completely adopting it. I have no idea if that is true or not but it's possible you are complying as closely as anyone else. Not sure.

I believe it is true.

Can we all accept that style of code is personal and has nothing to do with a language like PHP which as we all know does not even parse the white space in a file. Why is it that there is so much debate on how other people format their code, which you as another project more than likely will not modify or maintain. Let each project go with tabs, spaces, brackets whatever they want and get this group focused on interop again.

--

Larry E. Masters

Founder CakePHP