PSR-2 and tab

[Lukas Kahwe Smith]

Hello,

I feel the discussion around PSR-2 is hurting us. It is hurting us because of all the negativity and sheer traffic this is creating. I believe that the vocal minority that is causing this (note not everybody that is preferring tabs over spaces is taking part in this) has decided its more important to get tabs into a PSR than it is to allow this group to main productive. I hope they are doing this because they actually believe that tabs are so radically important that they would rather see the PSR process grind to a halt than allow this wrong to continue. Or they are more concerned with getting their preferences "standardized" or "recommended" just because. We will never know and obviously this is not a homogenous group and there are also people in that mix that just want to hand a compromise in the hopes that things can then calm down again. I tried to swallow all of this down, but could not get myself to not add this paragraph to this email. I guess this shows that I was well cannot just move on and not risk poisoning more. I just feel like people are risking the PSR process for close to no benefit (even if you are convinced that tabs are better than spaces).

Now I see a couple ways to continue:
1) do nothing
2) create a new PSR that copies PSR-2 and makes tabs optional allowed as well (see PR #91) and deprecates PSR-2
3) create a new PSR that copies PSR-2 and makes tabs optional allowed as well (see PR #91) that merely references PSR-2
4) create a new PSR that copies PSR-2 and mandates tabs over spaces (see PR #91) and deprecates PSR-2

Note that I am saying "create a new PSR that copies PSR-2" here while we do not yet have a by-law to update PSR's. I am largely in agreement with PR #93 on this topic which says that updates that change a PSR require a new PSR. But depending on if we f.e. go with updating a PSR by using a minor version (ie. 2.1) the above would need to be adjusted. I have seen no indication that the previous majority for spaces has changed their mind. Then again there have been several new members voted in since then. But even then by the proposed by-law in #93 there would be no way to drop a previous PSR aside from deprecating it, so "dropping spaces" in this context would be 4).

While discussing this I would urge the pro tab proponents to think hard if having to say "PSR-2 with tabs" is so horrible that it warrants this huge debate which in the end risks that any PSR we discussed at infinity where there are two decently acceptable directions and one is chosen in order to make the PSR less vague and more explicit. Essentially I am asking if the willingness to compromise that seems to be expected of those that are fine with PSR-2 as is, couldn't also be applied to yourself and swallow this one down if you agree that this discussion is damaging the process itself.

Otherwise I do ask you, the tabs must be included in a PSR camp, with proposing a new PSR with the changes you want. However please do this using the proper channels following the process of the PSR by-laws. Then once there is a vote I then also hope that you accept whatever results come out of this. The same applies to the camp that would prefer the PSR-2 to just remain as is.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org

[Jordi Boggiano]

Heya,

> Now I see a couple ways to continue: 1) do nothing 2) create a new
> PSR that copies PSR-2 and makes tabs optional allowed as well (see
> PR #91) and deprecates PSR-2 3) create a new PSR that copies PSR-2
> and makes tabs optional allowed as well (see PR #91) that merely
> references PSR-2 4) create a new PSR that copies PSR-2 and mandates
> tabs over spaces (see PR #91) and deprecates PSR-2

What's so bad about:

5) create a new PSR that copies PSR-2 and mandates tabs over spaces
and *coexists with PSR-2*

> While discussing this I would urge the pro tab proponents to think
> hard if having to say "PSR-2 with tabs"

IMO as long as people have to do that, they'll keep coming to
complain. It's gonna be new people every time, but it won't stop.

The other alternative is to write a clear document somewhere
explaining how those decisions were taken, acknowledging that they
don't fit everyone's view but that we won't change them so it's
pointless to argue. If creating a new PSR is out of the question, then
that might help deter further flamewars, or at last keep them out of
our backyard.

Cheers

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

[Lukas Smith]

On Feb 27, 2013, at 10:16 , Jordi Boggiano <j.bog...@seld.be> wrote:

> Heya,
>
>> Now I see a couple ways to continue: 1) do nothing 2) create a new
>> PSR that copies PSR-2 and makes tabs optional allowed as well (see
>> PR #91) and deprecates PSR-2 3) create a new PSR that copies PSR-2
>> and makes tabs optional allowed as well (see PR #91) that merely
>> references PSR-2 4) create a new PSR that copies PSR-2 and mandates
>> tabs over spaces (see PR #91) and deprecates PSR-2
>
> What's so bad about:
>
> 5) create a new PSR that copies PSR-2 and mandates tabs over spaces
> and *coexists with PSR-2*

sure .. fine too as a variation of 3).

>> While discussing this I would urge the pro tab proponents to think
>> hard if having to say "PSR-2 with tabs"
>
> IMO as long as people have to do that, they'll keep coming to
> complain. It's gonna be new people every time, but it won't stop.

sure .. in general i worry if its ever going to stop either way. people will complain that its confusing to have 2 recommended PSRs that are mostly the same etc.

tabs vs. spaces is an age old debate, so maybe its special enough to get special treatment .. or its just special enough to fuck up our process if we give in to it, because from then on there is a precedent for people to keep jammering on about anything without realizing that they can always just do minor variations of PSRs for their own purposes.

> The other alternative is to write a clear document somewhere
> explaining how those decisions were taken, acknowledging that they
> don't fit everyone's view but that we won't change them so it's
> pointless to argue. If creating a new PSR is out of the question, then
> that might help deter further flamewars, or at last keep them out of
> our backyard.

well i have been suggesting that we do a better job at documenting how we get to a PSR and providing an FAQ once its passed.

regards,
Lukas

[Paul Jones]

On Feb 27, 2013, at 2:39 AM, Lukas Kahwe Smith wrote:

> I feel the discussion around PSR-2 is hurting us.

They hurt us only to the extent we let them.

> We will never know and obviously this is not a homogenous group and there are also people in that mix that just want to hand a compromise in the hopes that things can then calm down again.

Things might calm down again, but it sets the stage for the next mob cry for an amendment, maybe for braces.

> Now I see a couple ways to continue:
> 1) do nothing
> 2) create a new PSR that copies PSR-2 and makes tabs optional allowed as well (see PR #91) and deprecates PSR-2
> 3) create a new PSR that copies PSR-2 and makes tabs optional allowed as well (see PR #91) that merely references PSR-2
> 4) create a new PSR that copies PSR-2 and mandates tabs over spaces (see PR #91) and deprecates PSR-2

4) Encourage the complainers to start their own group and publish their own recommendations. If they want to be the Judean People's Front, let them.


-- pmj

[Larry Garfield]

But this is the People's Front of Judea!

Really though, I have to agree. Passing a PSR-4 = PSR-2 + Tabs is just
begging for a PSR-5 that is PSR-2 + inline braces, and a PSR-6 that is
PSR-2 + inline braces and only 2-space indents, ad nausem.

PSR-2 contains almost exclusively bikeshed bait. And, I should note,
only passed FIG by a small margin. I don't know how exactly we're going
to prevent this or future flairups. But I agree with Paul that a "fine,
PSR-2-with-tabs gets its own name" won't solve anything, and may just
invite more flaming.

--Larry Garfield

[guilher...@gmail.com]

To me what we have as PSR-1 and PSR-2 is more than enough from what we need to move forward with other PSRs.

If we require a change because we haven't caught a given required CS, we publish a new one later and outdate the previous to accommodate OUR required changes.

I constantly get the feeling that people want us to add/modify/remove every single piece so they can be in conform with PSR-X, but in reality what we have done is just a normalization of different projects, so we could release our PSR interfaces, example code, etc and nothing else. OUR standards for OUR recommendations. We don't need to discuss or update anything unless we have a true need to.

That said, I still support the group and surely will be more active. Otherwise, I wouldn't consider myself being active here for too long.

Cheers,

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group - Coding Style" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig-cs+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Guilherme Blanco
MSN: guilher...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

[Andrew Eddie]

On Thursday, 28 February 2013 11:12:52 UTC+10, Larry Garfield wrote:

But this is the People's Front of Judea!

Really though, I have to agree.  Passing a PSR-4 = PSR-2 + Tabs is just
begging for a PSR-5 that is PSR-2 + inline braces, and a PSR-6 that is
PSR-2 + inline braces and only 2-space indents, ad nausem.

PSR-2 contains almost exclusively bikeshed bait.  And, I should note,
only passed FIG by a small margin.  I don't know how exactly we're going
to prevent this or future flairups.  But I agree with Paul that a "fine,
PSR-2-with-tabs gets its own name" won't solve anything, and may just
invite more flaming.

It would seem the only logical answer is to retract PSR-2. Leave code style to the individual vendors to duke it out. There is no real way to make it better, but leaving it in play perpetuates division in the community.

Regards,

Andrew Eddie

[Andreas Möller]

> It would seem the only logical answer is to retract PSR-2.

Why?

The only logical answer for those who don't like it is to ignore it. This is already happening, and it works fine for those that do. It doesn't work fine for those that feel they *have* to use it.

If PSR-2 is retracted, I don't see much use for this group anymore.

> Leave code style to the individual vendors to duke it out. There is no real way to make it better, but leaving it in play perpetuates division in the community.

It's all been said before.

Just stop.


Andreas

[Andrew Eddie]

On 28 February 2013 14:38, Andreas Möller <a...@localheinz.com> wrote:

> It would seem the only logical answer is to retract PSR-2.

The only logical answer for those who don't like it is to ignore it. This is already happening, and it works fine for those that do. It doesn't work fine for those that feel they *have* to use it.

If PSR-2 is retracted, I don't see much use for this group anymore.

I'm sorry you feel that way.

Regards,

Andrew Eddie

[Paul Jones]

On Feb 27, 2013, at 10:30 PM, Andrew Eddie wrote:

> It would seem the only logical answer is to retract PSR-2.

Not at all. We set up the rules for passing PSRs, held the discussion, split it up, voted on two separate measures, and both passed. If a vocal subgroup of the community at large don't like one individual recommendation within the entirety of the PSR, I fail to see how that's a reason to scrap it entirely.


-- pmj

[Ryan Parman]

PSR-2 is insignificant. PSRs 0 & 3 are significantly more important.

Andreas, if you're really that bent about PSR-2, then I'm honestly not sure what else to say to you.

This reminds me of the old maxim: "You can be right, or you can be married. But you can't be both." Do we want to defend PSR-2 at the cost of the community-at-large? Or are we willing to make a small concession to help things settle down?

Placing "right" and "wrong" aside, I believe there is only one mature answer.

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group - Coding Style" group.

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig-cs+...@googlegroups.com.

[Andrew Eddie]

So the members that voted -1 on PSR-2 just have to suck eggs? It's not exactly possible to distance myself from the PSR-2 decision and remain a member. Do you really want people to work together on things or does it come down to "the vote passed on my side of the fence, I don't care"?

Regards,

Andrew Eddie 

[Andreas Möller]

PSR-2 is insignificant. PSRs 0 & 3 are significantly more important.

That's an opinion, not a fact. 

Andreas, if you're really that bent about PSR-2, then I'm honestly not sure what else to say to you.

I like PSR-2 very much - and there are reasons for it. 

I don't think the group should bend because of some pressure to amend or retract PSR-2. That's the danger I see in this discussion. 

That's all to it. 

This reminds me of the old maxim: "You can be right, or you can be married. But you can't be both." Do we want to defend PSR-2 at the cost of the community-at-large? Or are we willing to make a small concession to help things settle down?

In your opinion, how small or big should that concession be, then?

Placing "right" and "wrong" aside, I believe there is only one mature answer.

Sure!

The accepted PSRs are recommendations, and you are free to follow them - or not. The mature answer would be to see that you as a coder have got this choice. 

Best,

Andreas

[Andrew Eddie]

On 28 February 2013 14:58, Andreas Möller <a...@localheinz.com> wrote:

To be honest, I don't know what your problem is, but since you are one of the guys who has strongly been involved in the late discussions about amending PSR-2, I'm just wondering what your intention is?

My practice is to try to listen to "the mob" even when some people are being idiots. There's always a grain of reason in there someone and it behoves leaders in the community to try and listen for it. That's what my 10 years in the Open Source community has taught me.

 

As it seems, Joomla does not officially say anything about PSR, but rather seems to suggest using PEAR, but tabs.

If this has worked fine for you, why do you bother bringing up the tabs-over-spaces debate again?

Because we are moving to break up an distribute our framework via composer to be more consumable by the wider PHP community. PSR-2 suddenly becomes a bigger deal.

 

I've been - albeit non-voting - member of this group since early last year and have followed the discussions and I admire the professionalism applied in the process of arriving at these standards. A lot of effort has been put into it, and into the mechanics of the voting process. A lot of research has been done, and the voting members have agreed on passing these standards.

If you've been there, you should know.

Um, actually, I was. Paul, to his credit, listened to myself and Evert and ended up splitting PSR-1 into two parts. I have no problem with PSR-0 and 1 for the record. 

 

The debate about tabs or other aspects of PSRs dividing the community could go on forever. In my opinion - and I reckon I am not the only one - it should just stop.

It will never stop, that's the point. The only way to make it stop for us, is to remove the PSR. Trust me, these things go in cycles. In 6 months, this will repeat itself, and again, and again, and again.

Regards,

Andrew Eddie 

[Paul Jones]

On Feb 27, 2013, at 11:02 PM, Andrew Eddie wrote:

> So the members that voted -1 on PSR-2 just have to suck eggs? It's not exactly possible to distance myself from the PSR-2 decision and remain a member. Do you really want people to work together on things or does it come down to "the vote passed on my side of the fence, I don't care"?

By way of reminder, we *did* work together. We held a survey and discussed it for, literally, months. I had no side of the fence; it didn't matter to me if it was tabs or spaces. There's no significant benefit to either spaces or tabs; the benefit is that we all use the same thing.


-- pmj

[Ryan Parman]

Point thoroughly missed.

It's become clear that Paul Jones and Andreas Möller are unabashedly on one side, while Andrew Eddie and I are unabashedly on the other. IIRC, Paul Jones was the author of PSR-1 and PSR-2.

I have every intention of not adopting PSR-2, and I understand that's my prerogative. But this "Give me PSR-2 or give me death" attitude does nothing to build-up the idea of consensus, which I thought our group was attempting to promote.

That's what I take issue with. It's not PSR-2... it's the attitude.

[Andreas Möller]

> Because we are moving to break up an distribute our framework via composer to be more consumable by the wider PHP community. PSR-2 suddenly becomes a bigger deal.

So your intention is to weaken the recommendation so you can say your code follows it?


Best,

Andreas

[Ryan Parman]

On Feb 27, 2013, at 9:15 PM, Andreas Möller <a...@localheinz.com> wrote:

> So your intention is to weaken the recommendation so you can say your code follows it?

Weaken? No.

Insisting you're right, with no room for adaptation is the problem.

[Paul Jones]

On Feb 27, 2013, at 11:15 PM, Ryan Parman wrote:

> It's become clear that Paul Jones and Andreas Möller are unabashedly on one side, while Andrew Eddie and I are unabashedly on the other. IIRC, Paul Jones was the author of PSR-1 and PSR-2.

Respectfully, your recollection is incorrect. I shepherded it through the process, but: Klaus Silveira made the initial proposal, I and others incorporated input/comments/criticism from all; Amy Stephen suggested a survey to help give some idea as to how many projects held to which parts of the standard, which we performed and analyzed to determine what the majority were doing on each point; Evert Pot and others suggested a split (which I opposed at the time); and after the split, and yet more discussion, the two measures passed a vote held by predetermined rules.

> I have every intention of not adopting PSR-2, and I understand that's my prerogative.

It is indeed.

> But this "Give me PSR-2 or give me death" attitude does nothing to build-up the idea of consensus, which I thought our group was attempting to promote.

The group exists to find commonalities between member projects and codify those commonalities.


-- pmj

[Paul Jones]

There is no "right" here. Spaces or tabs, makes no difference to me, as long as we all use the same thing. A supermajority of projects surveyed used 4-space indents, so that's what went in.


-- pmj

[Andreas Möller]

> Insisting you're right, with no room for adaptation is the problem.

I only happen to be "right" because PHP-FIG arrived at a recommendation for a coding style that very closely reflects what I prefer.

Five years ago, it would have been tabs for me as well.

So, it's just that I respect the recommendations - because they are based on empirical data and on a voting process that every voting member agreed with. I respect them because I respect the group and the voting body.

Also, they make a lot of sense and aren't just something that's based on personal preference.


Best,

Andreas

[Paul Jones]

On Feb 27, 2013, at 11:25 PM, Andreas Möller wrote:

> Five years ago, it would have been tabs for me as well.

10 years ago for me, the same. (Wow that's been a while.) Back then I switched my from my personal style to conform with a group, and I realized that the style itself doesn't matter, what matters is that the rules are shared. Hell, I still use tabs today in one of my work codebases (it has a different history than the others). Switching back and forth sucks. Tabs or spaces, it doesn't matter which one gets used, as long as we all use the same thing.



-- pmj

[Andrew Eddie]

On 28 February 2013 15:33, Paul Jones <pmjo...@gmail.com> wrote:

Tabs or spaces, it doesn't matter which one gets used, as long as we all use the same thing.

"We" being the entire PHP community?

Regards,

Andrew Eddie 

[Paul Jones]

"We" being this group; which does not now, nor do I expect it ever to, fully represent every person who has used, does use, or will use, PHP.



-- pmj

[Andrew Eddie]

On 28 February 2013 15:42, Paul Jones <pmjo...@gmail.com> wrote:

"We" being this group; which does not now, nor do I expect it ever to, fully represent every person who has used, does use, or will use, PHP.

That's reasonable for issues of interoperability ("we" all need to play nice if we are consuming each others code). It's a pipe dream for issues of style. Just wait until we get to the DocBlock standard - I will enjoy that.

Regards,

Andrew Eddie

[Andreas Möller]

> 10 years ago for me, the same. (Wow that's been a while.) Back then I switched my from my personal style to conform with a group, and I realized that the style itself doesn't matter, what matters is that the rules are shared.

That's how I found out about PHP-FIG in the beginning of last year - because I was looking for a coding guideline that has found or will find wide adoption, as part of a best practices approach.

> Hell, I still use tabs today in one of my work codebases (it has a different history than the others). Switching back and forth sucks. Tabs or spaces, it doesn't matter which one gets used, as long as we all use the same thing.

True.

And that's why I take a strong stance towards PSR-2.


Best,

Andreas

[Lukas Kahwe Smith]

On Feb 28, 2013, at 6:15 , Ryan Parman <ry...@ryanparman.com> wrote:

> Point thoroughly missed.
>
> It's become clear that Paul Jones and Andreas Möller are unabashedly on one side, while Andrew Eddie and I are unabashedly on the other. IIRC, Paul Jones was the author of PSR-1 and PSR-2.
>
> I have every intention of not adopting PSR-2, and I understand that's my prerogative. But this "Give me PSR-2 or give me death" attitude does nothing to build-up the idea of consensus, which I thought our group was attempting to promote.
>
> That's what I take issue with. It's not PSR-2... it's the attitude.

I think if you look at the discussion its clear that there are more people somewhere in the middle. So please do not make this a black and white battle.
Where I think more people will make it a black and white topic is when suddenly a majority vote isnt good enough anymore. Because if we start to question that, then I fear we will never ever pass anything anymore because 100% consensus is simply unrealistic.

Furthermore PSRs are not a law everyone must follow. There is no PSR police, there is no PSR hit squad. This is imho a very fundamental aspect of this group. If we are now going to say we need to purge a passed PSR, then we are saying that having this PSR creates an obligation to implement or why else would be purge it? There was obviously a point in time where a majority of members felt it made sense, so if nothing else it makes sense to keep it for historical purposes.

Now as new members join, as new information appears, at time we the majorities will change. At this point it might indeed make sense to deprecate a PSR in favor of a new one. This thread in part wanted to see if there really needs to be a new PSR and how it should look like. Again discussing that you want PSR-2 purged from history is imho the wrong direction to take this thread.

But whatever happens in the end .. no change or change, I urge the other side to stay humble and accept this (until they sufficiently sure that new evidence/members have again changed the majorities). Furthermore I also urge all parties to keep an eye on the greater good. We still have a lot of ground to cover and so everyone should really ask themselves if minor details should really get such disproportionate attention or not, especially since there is indeed the chance to supersede a PSR at a later point. Additionally the fact that even if you stay humble that others (new people that learn about PSRs at a later point f.e.) will not is not an excuse. The more people that behave reasonably on the FIG list, the more we will establish a behavior model that will help us greatly in staying productive. Most people do not want to appear as raving lunatics, but I think passion has gotten the best of most people on this list, giving the impression that behaving like a raving lunatic is actually the expected behavior pattern.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org

[Larry Garfield]

I voted -1 on PSR-2 on behalf of Drupal, and after it passed promptly ignored it.  Any time someone asks if Drupal will be moving to it, I usually laugh politely.  I don't taste any eggs. :-)

--Larry Garfield

[James Watts]

I feel the discussion around PSR-2 is hurting us.

I'm glad somebody has finally noticed. Until now it seemed like no one had realized there was a questioning of the validity of a recommendation regarding interoperability, which claims that one method of indentation "MUST" be used over another.

I believe that the vocal minority that is causing this

I consider myself a member of that vocal minority, but not because I prefer tabs over spaces (I've given my reasons here - https://github.com/php-fig/fig-standards/pull/35#issuecomment-14138174), but because allowing this to ever happen at all makes the FIG seem either bogus or biased. I know it was put to a vote, but in my opinion, this topic should have never been on the agenda from the start. There are, as various people have claimed, more important issues to be dealing with.

they actually believe that tabs are so radically important

Not really, I just personally don't want a recommendation dictating I choose one or the other. It makes zero difference to interoperability, the objective of this group, and I have not heard any arguments to the contrary.

I just feel like people are risking the PSR process for close to no benefit

Not at all, admitting to this mistake and correcting it would be a sign of the FIG's maturity, as well as respect for those in the community who see no reason in losing their preference for tabs, and in the process, blocking their ability to fully adopt a recommendation.

we do not yet have a by-law to update PSR's

I think I'll pass on commenting here, as I'm not sure if this is true or not. I surely hope it isn't, especially if you really want people to take you seriously as a group proposing recommendations that impact the PHP community. The process of creating the proposals is as important as the final recommendations themselves.

I have seen no indication that the previous majority for spaces has changed their mind

I think the discussion persists because few have seen the "real" problem: there never should have been a preference for either, only the requirement of consistency, i.e., ONLY use spaces OR tabs, but NOT both. That is the rectification I would suggest be made.

"PSR-2 with tabs" is so horrible that it warrants this huge debate

I agree that it would be an equally biased rectification, with the only objective of switching camps, and would only cater to allowing others to propose further rectifications due to personal preference. As I stated before, I would suggest that the preference be removed all together.

there are two decently acceptable directions and one is chosen in order to make the PSR less vague and more explicit.

No, I don't agree. There were 2 directions that should have never been discussed at all. And regarding the idea of this PSR being less vague, I'd recommend that you read the points of ambiguity still existing in the current recommendation - https://github.com/php-fig/fig-standards/pull/35#issuecomment-14172135

this discussion is damaging the process itself.

I don't agree with this either, the way I see it this discussion is bringing to light that the FIG made a mistake recommending PSR-2, which has put the community into a ridiculous debate of spaces vs tabs. The "damage" comes from this group's continued reluctance to rectify the issue, instead just digging in and claiming "hey, it's just a recommendation, ignore it". Glad to know that some of you stand so wholeheartedly by your proposals that you openly suggest people ignore them.

I'm a part of the minority fomenting this debate, not because I wish to die in the name of tabs, but instead to illustrate that this group should make a rectification, to demonstrate it's interest in the "greater good" of the community. I stand by the FIG's other proposals/objectives, and support the cause. As I've said elsewhere, I highly respect everything the group is doing, and I commend the effort and resolve to make the PSR proposals a reality. I just find it extremely hard to turn a blind eye to this issue in particular.

As stated many times before by others, this is a recommendation, and can be ignored. But it would be a testament to the group's ability to write a decent proposal if all could accept it without any unnecessary barrier to entry, especially if it falls upon personal preference. I would also call out that some are using the PSRs as a claim to standards compliance, and using this PSR specifically to one-up on other projects which prefer to not update their entire repo to replace tabs for spaces. This is not healthy for the community at large. And it's certainly not healthy for the FIG if people are advertising that they don't support a PSR because of it's nature.

In summary, my point would be that PSR-2 should never have happened at all. It has no validity in a group of recommendations aimed at interoperability. But, what's done is done, so the only option I could suggest is to rectify the situation by amending this PSR (use ONLY spaces OR tabs for indentation, but NOT both). I think that retracting the PSR all together, or creating another PSR to mirror problematic points in the current one, would be bad directions to take.

Lukas, my apologies for picking on your post.

Thanks

On Wednesday, February 27, 2013 9:39:29 AM UTC+1, Lukas Kahwe Smith wrote:

Hello,

I feel the discussion around PSR-2 is hurting us. It is hurting us because of all the negativity and sheer traffic this is creating. I believe that the vocal minority that is causing this (note not everybody that is preferring tabs over spaces is taking part in this) has decided its more important to get tabs into a PSR than it is to allow this group to main productive. I hope they are doing this because they actually believe that tabs are so radically important that they would rather see the PSR process grind to a halt than allow this wrong to continue. Or they are more concerned with getting their preferences "standardized" or "recommended" just because. We will never know and obviously this is not a homogenous group and there are also people in that mix that just want to hand a compromise in the hopes that things can then calm down again. I tried to swallow all of this down, but could not get myself to not add this paragraph to this email. I guess this shows that I was well cannot just move on and not risk poisoning more. I just feel like people are risking the PSR process for close to no benefit (even if you are convinced that tabs are better than spaces).

Now I see a couple ways to continue:
1) do nothing
2) create a new PSR that copies PSR-2 and makes tabs optional allowed as well (see PR #91) and deprecates PSR-2
3) create a new PSR that copies PSR-2 and makes tabs optional allowed as well (see PR #91) that merely references PSR-2
4) create a new PSR that copies PSR-2 and mandates tabs over spaces (see PR #91) and deprecates PSR-2

Note that I am saying "create a new PSR that copies PSR-2" here while we do not yet have a by-law to update PSR's. I am largely in agreement with PR #93 on this topic which says that updates that change a PSR require a new PSR. But depending on if we f.e. go with updating a PSR by using a minor version (ie. 2.1) the above would need to be adjusted. I have seen no indication that the previous majority for spaces has changed their mind. Then again there have been several new members voted in since then. But even then by the proposed by-law in #93 there would be no way to drop a previous PSR aside from deprecating it, so "dropping spaces" in this context would be 4).

While discussing this I would urge the pro tab proponents to think hard if having to say "PSR-2 with tabs" is so horrible that it warrants this huge debate which in the end risks that any PSR we discussed at infinity where there are two decently acceptable directions and one is chosen in order to make the PSR less vague and more explicit. Essentially I am asking if the willingness to compromise that seems to be expected of those that are fine with PSR-2 as is, couldn't also be applied to yourself and swallow this one down if you agree that this discussion is damaging the process itself.

Otherwise I do ask you, the tabs must be included in a PSR camp, with proposing a new PSR with the changes you want. However please do this using the proper channels following the process of the PSR by-laws. Then once there is a vote I then also hope that you accept whatever results come out of this. The same applies to the camp that would prefer the PSR-2 to just remain as is.

[Paul Jones]

On Mar 1, 2013, at 7:00 PM, James Watts wrote:

> In summary, my point would be that PSR-2 should never have happened at all.

A majority of the voting members disagreed with you.



-- pmj

[Andrew Eddie]

And some of would say "we told you this would happen". Neither this nor your comment, though, is particularly helpful.

I suggest we park any discussion on PSR-2 until we ratify the PSR process. In my view, PSR-2 is what it is and if it can be reclassified to an "informational" status (like some of us asked for in the first place!), it would certainly satisfy any concerns I have.

Regards,

Andrew Eddie

[Paul Jones]

On Mar 1, 2013, at 8:42 PM, Andrew Eddie wrote:

> On 2 March 2013 11:19, Paul Jones <pmjo...@gmail.com> wrote:
>
>> On Mar 1, 2013, at 7:00 PM, James Watts wrote:
>
>>> In summary, my point would be that PSR-2 should never have happened at all.
>
>> A majority of the voting members disagreed with you.
>
> And some of would say "we told you this would happen".

I don't recall disagreeing that there would be some people unable to stomach the idea of using spaces instead of tabs (or vice versa). I must admit I am unmoved by such protestations, seeing as how it matters so little; what matters is using the same thing, not the particular thing being used.


-- pmj

[Andrew Eddie]

On 2 March 2013 11:49, Paul Jones <pmjo...@gmail.com> wrote:

what matters is using the same thing, not the particular thing being used.

If you mean that it's important that we share the goal to align with interoperability standards like PSR-0,1 and 3, I agree (at least in principle and obviously where applicable). That said, I'm hesitant to be dogmatic about it and look down on a voting member that, for example, doesn't cater for PSR-3 in their framework because it jsut doesn't work for them.

But for something like PSR-2, which is about preference and not interoperability, it's not as important that we voting members all use the same thing, and we shouldn't even care. I think the important thing is that voting members should adopt "a" standard in this regard, but whether it's PSR-2 or some hybrid is the our own project's business.

If that's what you mean, then we are on the same page.

Regards,

Andrew Eddie

[Amy Stephen]

OK, you guys blew it. You took a topic that had no good answer, that there is no real benefit except to stop this type of discussion, and you turned it into a dual. Now, there is no logical way out. You are alpha males and if you lose, it's going to harm your involvement in the group. You backed one another in a corner. Someone has to win and someone has to lose and that does not work for alpha males.

• There is no good solution.
• There is no bad solution.
• There is no rule in place (yet) that says you can't change PSR-2 and add the "or use tabs, but do spaces or tabs but never both" and leave the name the same.
• This decision has very little consequence, either way.
• It only takes one of you to raise a PR for a vote.
• This process is harming this group.

So, have some fun with it. We need a hunger games of sorts. We need a coin toss. We need a video game to the death. Something that has nothing to do with this question. Something that doesn't force one alpha male to submit to the other.

The easiest approach is the coin toss.

• Get on Skype together.
• Someone share their screen.
• Figure out which side is heads and which side is tails.
• Go http://cgi.cs.duke.edu/~des/vct/vct.cgi
• Three out of five wins.
• Hopefully, you'll each have a beer and find maybe it wasn't so bad, maybe you like something in one another.
  

Some of you projects have worked together. Some projects are just joining the fold. Do what you can to encourage that, make it easy.

Whomever wins the coin toss gets to decide if Florin's PR is scheduled for a vote, or not. No additional changes are allowed his proposal. It will continue to be named PSR-2. There is no reason to announce how disfunctional this has become. It can say "Amended" - who cares?

https://github.com/php-fig/fig-standards/pull/91

Be done with it. Please do not try to think if this is a logical solution, it's not. At this point, there is pretty much no way you guys can come to an agreement and if one of you "caves" that person will struggle with his future involvement in this group.

If you strongly disagree, think this is a stupid idea and now you want to tell me why - then - yes, I'm talking about YOU. You are an alpha male. And while that is why you are an amazing leader. Right now, you suck and you are killing this project. Cut it out.

Flip the fucking coin. Move on. Figuring out how to manuever past this without making anyone lose will empower this effort.

[Andrew Eddie]

On 2 March 2013 15:13, Amy Stephen <amyst...@gmail.com> wrote:

OK, you guys blew it.

That's a matter of perspective.

 

You took a topic that had no good answer, that there is no real benefit except to stop this type of discussion, and you turned it into a dual.

That would be "duel" but you are reading something into the conversation that isn't there. We've been here before Amy ...

 

Now, there is no logical way out. You are alpha males and if you lose, it's going to harm your involvement in the group. You backed one another in a corner. Someone has to win and someone has to lose and that does not work for alpha males. 

Please leave sexist stereotypification out of it. 

For what it's worth, I would not, now, support PR#91 regardless of how the PSR business rules turn out. PSR-2 does in fact capture the commonalities among projects - it had a goal and achieved it. It's not wrong - it does not need to be changed. Any argument I had previously for changing it was faulty and I hereby retract them (read: I cave - go figure!). However, the bylaws don't require PSR's to be binding so in the case of PSR-2 I will cherry-pick what I can, ignore the rest and be satisfied with that position until such time as market forces pressure me to reconsider that position.

The one mistake I made in this whole process is thinking we SHOULD be making everyone happy and covering all bases. Unilateral consensus is not a goal here - at best we are aiming for the 67th percentile/middle ground (sounds hauntingly familiar, doesn't it Amy). I released myself from this burden and am rather the better for it. It won't happen again.

One final thing. Not that I have any moderator authority at all, but out of some sense of civil decency, watch your language. The vulgarities have no place here and you've been warned about this on the Joomla lists before.

Regards,

Andrew Eddie

[Amy Stephen]

"Alpha Male Syndrome" is not a sexist stereotype. It is a real condition that is studied in science with baboons, in academic settings, health industries, discussed in business journals, leading newspapers worldwide. There is a lot written on it. While it's considered far more typical in men then women, it's not exclusive to men.

There is plenty written on women who have alpha male syndrome. Alpha Male Syndrome in women, 2006, New York Times, http://www.nytimes.com/2006/09/24/business/yourmoney/24lunch.html?pagewanted=all&_r=0

The reason it is studied so much is that this is condition is found most frequently in our leaders. All kind of leaders, visionaries, commanders, strategies, executors. Just like you guys*. [* is an acceptable cross-gender word to mean people, folks, human beings, saying it *should not* land your picture on cover of the Geek Feminist Wiki.].

Bringing leaders together is not always productive. Like this has been. Too many insults hurled, too much blaming, too much debate over what is right or wrong, a focus on rules, rules that do not even exist most of the time, a quest and push for the top banana.

If you cannot look at the dynamics in this group and see the alpha male syndrome at work and creating problems, it is just going to make it that much more difficult to resolve.

You need to leverage it, not deny it. Each of you are leaders. You are used to setting course for your own communities. To getting the adoring respect from your communities. Here, you are thrust together as peers, equals, and the period of open source time you are entering is unclear, it looks very much like the beginning of a huge merger, converging of projects. You are discussing how to define the rules so your work is interchangeable. Your communities are counting on you.

The fact that you are all here, discussing it, is the part that is what is pretty amazing. The fact that you are struggling with how to share leadership is not a surprise. Be aware of it. Think about it as you interact. What would turn you off, push you back, make you dig your heals in. How do you like to be treated as a leader. Find ways to help everyone lead in their area of strength.

You're right, Andrew, you and I have been down this road, around the block, up the hill, over the dale, through a lot together. From those experiences, the good and the bad, I have much respect for you. I'm very proud Joomla is part of this. Joomla and Drupal are walking into a group that's already had lots of interaction and working alliances, puts you guys at a little disadvantage but the size of communities you are bringing with you is opportunity for everyone. It's in the best interest of everyone to make certain to give voice to projects as they come in.

Lastly, Andrew, I apologize to you and to anyone else who was offended by the word I used at the end of my post. Out of respect for you, and knowing how much it offends you, I choose to not use the word again in these forums.

Now, do this thing. Make it work as best as you can.

[Larry Garfield]

By only a slim margin.

--Larry Garfield

[Amy Stephen]

There still remains the mysterious disappearance only days before the vote of four well known tab supporters. Not accusing, just saying.

--Larry Garfield

--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group - Coding Style" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig-cs/qVmUgK86YHs/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to php-fig-cs+unsubscribe@googlegroups.com.

[Andrew Eddie]

Larry, I don't agree it was slim. The vote is set at 67% to ensure a better than average majority to accept (which is often quite hard in reality). Imagine that acceptance criteria was 97% in favour. Now let's say that vote passed at 97.2% in favour. It only passed by a "slim" margin but the confidence level that it was a good decision is extremely high. The way I look at it, the two-third vote style is forcing a margin from > 50% to < 66.66%, which would cover "slim" (where I would define "slim" as being the region immediately around 50%, maybe +/- 4%).

You may have a different take but that's how I look at it.

Regards,

Andrew Eddie

[Jason Judge]

On Wednesday, 27 February 2013 09:22:58 UTC, Lukas Kahwe Smith wrote:

... 

sure .. in general i worry if its ever going to stop either way. people will complain that its confusing to have 2 recommended PSRs that are mostly the same etc.

Surely a new PSR would just say, "what PSR-2 says, except that tabs thing" rather than replicating everything.
 

tabs vs. spaces is an age old debate, so maybe its special enough to get special treatment .. or its just special enough to fuck up our process if we give in to it, because from then on there is a precedent for people to keep jammering on about anything without realizing that they can always just do minor variations of PSRs for their own purposes.

If I run a project that has an issue with any aspect of the recommendations, then it is up to me to write a local work procedure or variation, or whatever we want to call it, to make that statement, declare what that project will be doing, and moving on. I personally would have absolutely no problem with that, and have no problem with any other project doing that. The issue people seem to have, is that if they are not 100% compliant, then there project will be seen as inferior, and so they must fight the PSR (to the death, presumably). In the big picture, it really does not matter. As an idea set out for all to use, the PSRs are a great ideal to aim towards, and that is good enough IMO, and does not lesson the importance of the PSRs in any way.

-- Jason

[Amy Stephen]

On Tue, Mar 5, 2013 at 8:58 AM, Jason Judge <jason....@gmail.com> wrote:

The issue people seem to have, is that if they are not 100% compliant, then there project will be seen as inferior, and so they must fight the PSR (to the death, presumably). In the big picture, it really does not matter.

In fact, many of the projects who have proudly adopted the PSR-2 aren't completely following it. They just aren't running around saying "We are PSR-2 compliant, less the bits that bug us." Just try the sniffer stack from various members on PSR-2 compatible code base.

Ideas -

1. Market Andrew's t-shirt idea for a FIG fundraiser, except offer two t-shirts "Proud to have adopted PSR-2 #SpacesR4Ever" and then, the big money maker "Proud to have *not* adopted PSR-2 #TabsR4Ever" The group would make *bucketfuls* of money.

2. Display an FAQ item to show how to remove a sniff from a standard checker. In the example, use the spaces sniff.

3. Add a routine to composer that reformats the source for spaces, on install, if the option is specified in the composer.json (That's PSR-2 compliant.)

4. Do all three, keep de-emphasizing perfection, because, as Jason correctly points out "In the big picture, it really does not matter."


Time and time again we see these situations that seem stupid or silly actually serve a useful purpose of testing the resolve of a group. What has been encouraging is to see involvement in the Cache standard starting to pick up and a group clarifying purpose. In the end, this silly debate has had value.

[Beau Simensen]

The answer that I feel will leave PHP-FIG's credibility intact is to do nothing. We came up with PSR-2 for a reason. We spent a lot of resources getting to where we are now. We already fought these battles. Reopening these issues due to external forces does not send a healthy message about our process or our resolve.

If this literally comes down to a coin toss I think PHP-FIG's credibility will be completely lost. While I can appreciate the idea behind it, I seriously hope this is not actually an option. Why would I ever invest anything further into working with PHP-FIG or using anything that comes from it if this is how serious issues may end up being resolved?

In my eyes, the problem we are facing is not with PSR-2. The problem is identity and messaging. People need to be educated on who we are and what our goals are. We need to make sure that people understand exactly how PSR-X should be interpreted with respect to the PHP community at large. Solidifying our identity and nailing our messaging will take a lot of time and energy. I think we should be putting all of our energy there and table further discussion on what we should do about PSR-2. Once we have our messaging locked down we may find that revisiting PSR-2 in a reactionary manner will not be required. 

I also firmly believe we need to have a policy to never engage in aggressive discussions with those who have not taken the time to get involved with our community. If someone has not taken the time to get involved with the process and to understand why certain things are the way they are I do not think we should pay them any attention when they come demanding we change something.

If we ever decide to move forward with another coding style proposal (either to sit beside, supersede, or amend PSR-2) we should do so at our leisure and because it makes sense for our community, not because outsiders said we made something that they don't like.

[Amy Stephen]

Beau - I agree with almost everything you said, certainly the overall message. My suggestion on a coin toss was indeed serious but only to decide whether or not another a vote would be called to see if members wanted to amend the standard. 

The problem is, there is no rule about changing a standard, although one is being crafted. Those calling for a vote to amend are perfectly within their rights. Those who are frustrated with them for doing so need formed an expectation based on their assumption.

To end the matter without having to force someone to lose, a coin toss can be useful and should not be considered a failure. It a simple way to move forward without someone having to lose and it can be done with humor which builds, instead of tears down a group. 

In the future, when it becomes clear that consensus is not going to be possible, and *most especially* when the issue is of limited significance, it's a good idea for the group to end it quickly - before the nasty accusations begin - and a coin toss is a good way to do it.

[Andrew Eddie]

On 6 March 2013 05:50, Beau Simensen <sime...@gmail.com> wrote:

In my eyes, the problem we are facing is not with PSR-2. The problem is identity and messaging. People need to be educated on who we are and what our goals are. We need to make sure that people understand exactly how PSR-X should be interpreted with respect to the PHP community at large. Solidifying our identity and nailing our messaging will take a lot of time and energy. I think we should be putting all of our energy there and table further discussion on what we should do about PSR-2. Once we have our messaging locked down we may find that revisiting PSR-2 in a reactionary manner will not be required. 

Ok, so lets take a stab on doing that. If we were to write a commentary (ISO jargon) or an FAQ, what would be the pillars of the message we were trying to convey? Would it be something like this:

=====

* PSR-2 is a statistical representation of how most project approach code style most of the time

In other other words, we did a survey of all the member projects and tried to find the line of best fit that would represent the commonalities between projects. It did not, however, mean that every project agreed with every point on that line of best fit.

* PSR-2 was created because we believe in code style standards are important.

The point here is that it is important for individuals and projects to adopt a consistent approach to coding style. Even if you don't adopt PSR-2 strictly, any approach is better than nothing.

* It has been written with strict language so that it is easy for code standard software to codify it.

In other words it's hard to write a code sniffer for a standard when there are lots of options and variables to take into account. In order to write automated tools we had to make the specifications very strict.

* You don't have to use PSR-2, but we do encourage every individual and project to adopt it *as a base* and even modify it as it suits their needs.

In other words we recognise that even though we have found the commonalities, not everyone is going to agree with every point of PSR-2 all of the time.

* PSR-2 doesn't cover everything so we fully expect individuals and projects to extend or have additional requirements on top.

The fact is that the notion of "PSR-2 compliant" is meaningless because projects are more often than not going to have additional requirements with respect to code style. Even though a project might follow PSR-2 to the letter does not mean that someone who only meets PSR-2 in isolation will be able to successful contribute code (because, for example, the project has DocBlock standards, etc).

* There is nothing stopping anyone from writing their own standard.

PSR-2 is just what the FIG came up with. Anyone else can come up with their own standard and encourage adoption throughout the PHP community. Member projects may even modify PSR-2 and you may choose to follow their custom versions. However, the FIG is only going to publish one option officially.

=====

Are those pillars things we can agree on? Are there more?

If we can reach a consensus on the "dot points", then we can move to turning them into natural language FAQ's.

Thoughts?

 

Regards,

Andrew Eddie

[Chuck Burgess]

Those look pretty good to me, Andrew.  Nothing jumps out at me as particularly inconsistent with the other areas of thought that I've seen on the various threads since these discussions began.  Also, I don't pick up much hint of aggressive or defensive posture in any of the points, so I see less risk of aggressive/defensive responses in reply to them.

CRB
about.me/ashnazg

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group - Coding Style" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig-cs+...@googlegroups.com.

[Beau Simensen]

Good start. :) These are all specifically PSR-2 related which is great. We can work on  I'd offer some tweaks.

 * The primary audience of PSR-2 are member projects

We created this for interop purposes between member projects. Even in that, not all member projects are going to be able to implement PSR-2 for their projects.

 * PSR-2 will be used for all code related PSR-X, where X > 2

So for example, PSR-3 will be valid PSR-2. As will any future PSR-X that involves a package containing actual code.

This can also address the criticism I've seen that PSR-0 (specifically the reference implementation embedded int he doc) is not valid PSR-2.

* PSR-2 is a statistical representation of how most project approach code style most of the time

 * PSR-2 is a statistical representation of how the majority of member projects approached code style at the time PSR-2 was created

I think many people would take exception to "most projects ... most of the time" and think we are trying to apply this statement to any PHP project anywhere. In reality, it was a statistical representation of the member projects ... at the time it was created. At some point the majority may shift so it would be good to have the statement not need to be changed as the "balance of power" shifts. :)

* It has been written with strict language so that it is easy for code standard software to codify it.

 * It has been written with strict language with words like MUST, MUST NOT, and REQUIRED because we are following RFC 2119, the same RFC used by many organizations in writing many technical specifications for over a decade

I realize that making things easier for code standard software is an important reason to do it the way we did, but I think that people easily gloss over the RFC 2119 link embedded in PSR-2. More than anything I think that they just take exception to us using ALL CAPS to say they CANT DO WHAT THEY WANT and need to understand that this is a recognized way for specifications to be written. I don't think they will care that it makes phpcs easier. They only care that we are saying things like MUST and REQUIRED.

We can drive this point home by linking people to specifications for common things that use RFC 2119 (Atom for example? http://www.atomenabled.org/developers/syndication/atom-format-spec.php ). Basically, rather than just saying "we did it this way so that phpcs can follow its rules more easily," say, "go look at the wording used by the Atom spec and you'll see that we're really trying to do the right thing here, if you still have a problem with MUST, SHOULD, MAY, go take it up with IETF. Good luck with that. :)"

The point here is to be able to respond to criticism of things like MUST, SHOULD, REQUIRED, etc. with simply "It was written this way because we followed RFC 2119, please see http://php-fig.org/apologetics/psr-2#rfc2119" and it should bring up our bullet point with our description text backing it and leave it at that. People should come away from that understanding the nuances of why we use this terminology in our coding style guide. We should not, individually, try to explain these things to anyone. We should have one way that it is described and not argue it beyond that. If someone visits our clear and concise description of what RFC 2119 is and why it is important and who else is using it and *still* thinks we are "wrong" and should not have MUST SHOULD ETC I don't think we owe them any further explanation and we should not engage in any follow up discussion. Clearly they are in the conversation for some purpose other than to listen to reason.

* You don't have to use PSR-2, but we do encourage every individual and project to adopt it *as a base* and even modify it as it suits their needs.

 * You don't have to use PSR-2 but you can if you want to.

By saying "we do encourage every ..." it sounds like we are actively trying to get people to use it. While this is true to an extent (we do want people to use it!), I think a slightly more passive approach might be nice here and saying that nobody (specifically the reader) has to use it but anyone can use it if they want to.

I split out the part about "as a base" stuff because it didn't look like it fit. I initially thought about making its own bullet point:

 * You are free to use PSR-2 as a base coding style guide for your own projects and customize any aspect of it to your liking.

... but after tweaking it I realized it is a lot like the next bullet point already suggested. :)

 * PSR-2 doesn't cover everything so we fully expect individuals and projects to extend or have additional requirements on top.

So, if we like the wording of what I came up with awesome. Otherwise, we can drop it entirely and just leave the existing one. I kind of like my rewrite of the bullet point, though.

[Andrew Eddie]

On 7 March 2013 02:31, Beau Simensen <sime...@gmail.com> wrote:

Good start. :) These are all specifically PSR-2 related which is great. We can work on  I'd offer some tweaks.

Good comments overall.

 

 * The primary audience of PSR-2 are member projects

We created this for interop purposes between member projects. Even in that, not all member projects are going to be able to implement PSR-2 for their projects.

I really want to stay well clear of what the mission of FIG is supposed to be because there is wild disagreement. I don't agree that the primary audience is "us" so it would be better to leave that hot potato alone.

 

 * PSR-2 will be used for all code related PSR-X, where X > 2

So for example, PSR-3 will be valid PSR-2. As will any future PSR-X that involves a package containing actual code.

This can also address the criticism I've seen that PSR-0 (specifically the reference implementation embedded int he doc) is not valid PSR-2.

Yes, good point. I'd be happy with that.

 

* PSR-2 is a statistical representation of how most project approach code style most of the time

 * PSR-2 is a statistical representation of how the majority of member projects approached code style at the time PSR-2 was created

I think many people would take exception to "most projects ... most of the time" and think we are trying to apply this statement to any PHP project anywhere. In reality, it was a statistical representation of the member projects ... at the time it was created. At some point the majority may shift so it would be good to have the statement not need to be changed as the "balance of power" shifts. :)

Fair point. 

 

* It has been written with strict language so that it is easy for code standard software to codify it.

 * It has been written with strict language with words like MUST, MUST NOT, and REQUIRED because we are following RFC 2119, the same RFC used by many organizations in writing many technical specifications for over a decade

I realize that making things easier for code standard software is an important reason to do it the way we did, but I think that people easily gloss over the RFC 2119 link embedded in PSR-2. More than anything I think that they just take exception to us using ALL CAPS to say they CANT DO WHAT THEY WANT and need to understand that this is a recognized way for specifications to be written. I don't think they will care that it makes phpcs easier. They only care that we are saying things like MUST and REQUIRED.

We can drive this point home by linking people to specifications for common things that use RFC 2119 (Atom for example? http://www.atomenabled.org/developers/syndication/atom-format-spec.php ). Basically, rather than just saying "we did it this way so that phpcs can follow its rules more easily," say, "go look at the wording used by the Atom spec and you'll see that we're really trying to do the right thing here, if you still have a problem with MUST, SHOULD, MAY, go take it up with IETF. Good luck with that. :)"

The point here is to be able to respond to criticism of things like MUST, SHOULD, REQUIRED, etc. with simply "It was written this way because we followed RFC 2119, please see http://php-fig.org/apologetics/psr-2#rfc2119" and it should bring up our bullet point with our description text backing it and leave it at that. People should come away from that understanding the nuances of why we use this terminology in our coding style guide. We should not, individually, try to explain these things to anyone. We should have one way that it is described and not argue it beyond that. If someone visits our clear and concise description of what RFC 2119 is and why it is important and who else is using it and *still* thinks we are "wrong" and should not have MUST SHOULD ETC I don't think we owe them any further explanation and we should not engage in any follow up discussion. Clearly they are in the conversation for some purpose other than to listen to reason.

Ok, I can work with that. Actually, do you want to suggest we include that with the other FAQ change that it being worked on (the "inappropriate edit" thread on the main list)?

 

* You don't have to use PSR-2, but we do encourage every individual and project to adopt it *as a base* and even modify it as it suits their needs.

 * You don't have to use PSR-2 but you can if you want to.

By saying "we do encourage every ..." it sounds like we are actively trying to get people to use it. While this is true to an extent (we do want people to use it!), I think a slightly more passive approach might be nice here and saying that nobody (specifically the reader) has to use it but anyone can use it if they want to.

I split out the part about "as a base" stuff because it didn't look like it fit. I initially thought about making its own bullet point:

 * You are free to use PSR-2 as a base coding style guide for your own projects and customize any aspect of it to your liking.

... but after tweaking it I realized it is a lot like the next bullet point already suggested. :)

 * PSR-2 doesn't cover everything so we fully expect individuals and projects to extend or have additional requirements on top.

So, if we like the wording of what I came up with awesome. Otherwise, we can drop it entirely and just leave the existing one. I kind of like my rewrite of the bullet point, though.

After cascading down, yes, that's fine - we can just use that last point.

Ok, how to move forward? A few options:

1. In the absence of a solid decision otherwise, we could propose an errata to append to PSR-2 and wordsmith the above into a digestible form. I think that discussion has more or less stalled.

2. We could invent a new document type like a "Commentary for PSR-2" which is how you would do it in ISO-land.

3. We could ask for a change to the main FAQ page on the FIG web site.

4. We could ask for a separate new page that covers this material?

I'd prefer the errata way myself because there's nothing here that changes the meaning of PSR-2, and then everything is in the one place. But, if we don't modify PSR-2 directly, it really need to be modified to add the link to wherever we host this information anyway (in which case, I'd still vote to add an errata to do that). 

I'll see if I can find some spare time today to pull the points together in a gist and keep this rolling ahead to some degree anyway.

Regards,

Andrew Eddie

[Beau Simensen]

A gist might be a good place to continue this. :)

Ok, I can work with that. Actually, do you want to suggest we include that with the other FAQ change that it being worked on (the "inappropriate edit" thread on the main list)?

I think this could probably be on the main FAQ if we are likely to use it for most/all of our other specifications. I could propose it in that thread as well. 

2. We could invent a new document type like a "Commentary for PSR-2" which is how you would do it in ISO-land.

I think that might be a good option. It is sorta what I had in mind when I fabricated the example "apologetics/psr-2" link. We probably wouldn't want to use that word but I thought it fit well in the context of PSR-2. :)