Which is it: PHP Standards Recommendations or Framework Interoperability?

[Ralph Schindler]

https://github.com/ralphschindler/fig-standards/blob/proposal-for-group-clarity/proposed/group-clarity.md

Discuss on list? or here: https://github.com/php-fig/fig-standards/pull/76

-ralph

[Lukas Smith]

On Jan 10, 2013, at 20:47 , Ralph Schindler <ralph.s...@gmail.com> wrote:

> https://github.com/ralphschindler/fig-standards/blob/proposal-for-group-clarity/proposed/group-clarity.md
>
> Discuss on list? or here: https://github.com/php-fig/fig-standards/pull/76

i am not exactly sure why you submitted this as a PR to be merged? the way it is formulate "my opinion" it seems more like an email, rather than a document to be ratified. i also do not understand how you use the word "noble" here .. are you saying that PSR-3 is the opposite of noble?

at any rate i dont think that renaming PSR's to FIG's will solve anything. its a 3 letter acronym, they tend to take on lifes of their own. we did have the discussion already on the list when we pondered the namespace and decided to stick with PSR.

regards,
Lukas

[Ralph Schindler]

i am not exactly sure why you submitted this as a PR to be merged? the way it is formulate "my opinion" it seems more like an email, rather than a document to be ratified. i also do not understand how you use the word "noble" here .. are you saying that PSR-3 is the opposite of noble?

It seemed like most dicusssions happened in PR's, so I took it there first.  In any case, it is a proposal to develop a better procedure for accepting things, and how to classify them.

I think PSR-3, as codified as a PHP Standard Recommendation #3 is misguided.  It has little to do with de-facto standard way of doing things, and has more to do with shared code implementations that promotes "framework interoperability"- which I see as two separate things.
 

at any rate i dont think that renaming PSR's to FIG's will solve anything. its a 3 letter acronym, they tend to take on lifes of their own. we did have the discussion already on the list when we pondered the namespace and decided to stick with PSR.

regards,
Lukas

Passing an implementation/interface off as a "standard recommendation" in the same vein as autoloading (PSR-0) and code formatting (PSR-1, PSR-2) detracts from the original goals of the group, which I think is generally understood to be identifying and classifying de-facto standards in the PHP community at large.

Not that there is anything in particular wrong with this particular logger interface, but it is just that: "any particular logger interface".  It is highly subjective and most of the decisions in naming (usage of Interface suffix, usage of Aware convention for DI, usage of nouns for method names) are not addressed by either previous coding style guide.  Therefore, you're choosing one set of non-ratified coding practices and naming over any other given set.  The next few proposals that come in, which are sure to be for caching, authentication, validation/filtering and other cross-cutting concern classes are sure to be different in naming and structure than the LoggerInterface in PSR-3.

In the end, 30 different PSR-#'s that deal with various interfaces and interop issues is going to detract visibility from the ones like PSR0,1,2 where the audience for those is much larger (PHP Community at large vs. those who build frameworks).

-ralph

[Lukas Smith]

On Jan 10, 2013, at 21:15 , Ralph Schindler <ralph.s...@gmail.com> wrote:

> Not that there is anything in particular wrong with this particular logger interface, but it is just that: "any particular logger interface". It is highly subjective and most of the decisions in naming (usage of Interface suffix, usage of Aware convention for DI, usage of nouns for method names) are not addressed by either previous coding style guide. Therefore, you're choosing one set of non-ratified coding practices and naming over any other given set. The next few proposals that come in, which are sure to be for caching, authentication, validation/filtering and other cross-cutting concern classes are sure to be different in naming and structure than the LoggerInterface in PSR-3.
>
> In the end, 30 different PSR-#'s that deal with various interfaces and interop issues is going to detract visibility from the ones like PSR0,1,2 where the audience for those is much larger (PHP Community at large vs. those who build frameworks).

I disagree with several assertions you have made here.

I disagree with the assertion that future proposals will have any let alone significant differences in naming etc. I also disagree that the names etc chosen for this interface were "random" as they were based on existing implementations and collaboration. Finally I disagree that PSR-3 etc such a radically smaller target audience than PSR-0/1/2, especially since PSR-3 was discussed especially as having to goal to make it easier for library authors to provide implementations that can be more easily dropped into other libraries (and frameworks).

regards,
Lukas

[Larry Garfield]

On 1/10/13 2:15 PM, Ralph Schindler wrote:

> I think PSR-3, as codified as a PHP Standard Recommendation #3 is
> misguided. It has little to do with de-facto standard way of doing
> things, and has more to do with shared code implementations that
> promotes "framework interoperability"- which I see as two separate things.
>
>
> at any rate i dont think that renaming PSR's to FIG's will solve
> anything. its a 3 letter acronym, they tend to take on lifes of
> their own. we did have the discussion already on the list when we
> pondered the namespace and decided to stick with PSR.
>
> regards,
> Lukas
>
>
> Passing an implementation/interface off as a "standard recommendation"
> in the same vein as autoloading (PSR-0) and code formatting (PSR-1,
> PSR-2) detracts from the original goals of the group, which I think is
> generally understood to be identifying and classifying de-facto
> standards in the PHP community at large.

Now see, here's the key and fundamental problem I disagree entirely on
every point you just made, right down to the fundamental philosophy. :-)

My understanding of this group has always been to promote
interoperability between projects. The "De facto standard" for the past
15 years has been... no interoperability. That's the problem we're
trying to solve. If all we do is codify "what everyone is doing
anyway", then

1) We'll never actually do anything, because PHP is still largely not
interoperable. Even PSR-0 wasn't already a de facto standard, unless
you consider PEAR and Java to be sufficiently de facto.

2) None of our existing PSRs are valid. PSR-0 wasn't what people were
already doing because namespaces were still very young. PSR-1 is good
best practices, but certainly not universal. PSR-2 was an amalgam of
different standards based on a survey, but nearly every project that has
adopted it has had to change something. PSR-3 is inspired by two
existing systems (Monolog and Drupal), but not something everyone was
using already.

The lack of a de facto standard is the problem to be solved, not simply
documented.

In that light, I would actually flip your statement around. PSR-3 is
what we should be doing, and PSR-2 was and still is an off-topic
distraction. Given that PSR-2 passed by a slim margin and PSR-3 passed
unanimously, I think there is some weight behind that position.

> In the end, 30 different PSR-#'s that deal with various interfaces and
> interop issues is going to detract visibility from the ones like
> PSR0,1,2 where the audience for those is much larger (PHP Community at
> large vs. those who build frameworks).
>
> -ralph

I think that statement misses the key importance of 2012. With the
advent of FIG and, more importantly, Composer, there is not a clear
dividing line between "those fancy framework people" and "the great
unwashed PHP masses". There's absolutely no reason that random Joe
Developer should have to decide between building his work on top of a
big stack (be that stack Zend, Symfony, Drupal, or Cake) and rolling
everything himself. By leveraging the Packagist archive, he can have
his Cake and Log it too. (Sorry, had to!) But that requires not that
Symfony and Zend are on the same page, but that the PHP world in general
is on the same page.

So no, the audience for tabs-vs-spaces standards is not larger than the
audience for "people who want to log things but not have to define their
own logging API". Or, rather, it may have been at one point, but it
either no longer is or won't be for much longer (depending on your POV).

And that change is beneficial for everyone.

--Larry Garfield

[Phil Sturgeon]

>  By leveraging the Packagist archive, he can have his Cake and Log it too.

Larry. You have been voted off the island. :)

But yes, there is no need for any change on this. The PHP-FIG (Framework Interoperability Group) creates PSRs. We're not going to start calling them FIGs because that is ridiculous. A PSR is something (anything) that helps the FIG do their job - of working together.

Let's not start trying to guess which we think are more important than others, unless we want to start making Super-PSR's.

On second thoughts, that sounds awesome. Let's do that.

[guilher...@gmail.com]

My vote is to keep PSR as main namespace and recommendations.

Please guys stop discussing things that are purely cosmetical.

Read JCP.org, they are not creators of Java and they release JSRs. They are also a FIG of Java.

Instead of investing time discussing things that were already released, focus on the future.

Discussions like rename PSR-3 to FIG-1, legitimability of PSR-1/2.... come on... stop kicking the dead horse.

-1 on proposal

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To post to this group, send email to php...@googlegroups.com.
To unsubscribe from this group, send email to php-fig+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/AattwaxoOmgJ.

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

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

[William Durand]

-1 as well. No need to waste our time on this.

PSRs are made by a group to ease interoperability between frameworks/libraries. It's perfectly clear, isn't it?

--

William Durand | http://www.williamdurand.fr

[Lukas Smith]

Hey Ralph,

First up sorry .. somehow your comments on twitter and your PR made me feel like its a conscious or subconscious attempt to detail what people have been working on here. If my tone ended up being too "pissy" I apologize and I would also like to apologize for jumping to such unwarranted conclusions.

At any rate, I was chatting with Larry about your proposal on IRC. And we ended up discussing if there is a lack of a clear vision for FIG/PSR. But looking at php-fig.org imho we have a clear mission statement that encompasses both standardization of existing practices as well as coming up with new standards that enable collaboration:

"What is FIG?

The idea behind the group is for project representatives to talk about the commonalities between our projects and find ways we can work together. Our main audience is each other, but we’re very aware that the rest of the PHP community is watching. If other folks want to adopt what we’re doing they are welcome to do so, but that is not the aim."

So to me this statement gives this group a clear mandate for all that has been done with PSR-0/1/2/3 and what we are discussing as future PSR's with Cache/Http Message etc.

regards,
Lukas

[Ralph Schindler]

So, first, I will apologize as well. The tone of my proposal is probably somewhat inflammatory as I re-read.

 

At any rate, I was chatting with Larry about your proposal on IRC. And we ended up discussing if there is a lack of a clear vision for FIG/PSR. But looking at php-fig.org imho we have a clear mission statement that encompasses both standardization of existing practices as well as coming up with new standards that enable collaboration:

"What is FIG?

The idea behind the group is for project representatives to talk about the commonalities between our projects and find ways we can work together. Our main audience is each other, but we’re very aware that the rest of the PHP community is watching. If other folks want to adopt what we’re doing they are welcome to do so, but that is not the aim."

So to me this statement gives this group a clear mandate for all that has been done with PSR-0/1/2/3 and what we are discussing as future PSR's with Cache/Http Message etc.

I think you're right, with respect to that mission statement PSR-3 is perfectly in line with the group.  I've not read this statement and was completely under the impression the groups was still forming "php standards recommendations" in the spirit of promoting code and package styling, and somewhat touching on interoperability through already existing tools in PHP core today.  IMO, I don't think this is the case anymore, and I was taken aback that the first time I saw this new proposal come in was after the winter break.

I really though there was a line in the sand with respect to promoting best practices in the community and then creating common types/implementations/framework components for general consumption (style vs. tools for interoperability).  I think I am correct in asserting that PSR-3 is subject to far more subjective criticism than any of the PSR-0,1,2.  For example, who decided logging was an OO facility, whats wrong with logging as a procedural/functional entity? Why are the method names nouns? Why is there a particular naming for this new type (Interface suffix)? How will this be versioned? Who decided using types better than duck typing for interoperability between unrelated projects? How will it be distributed? How will projects manage BC?

You might have answers to all those, but keep in mind, those are problems of a framework.  Which mean, by this group shipping code, you've started developing a new framework, or better termed, a meta-framework.  After all, whats going on now in the PR queue and the mailing list is exactly the kind of discussions that happen when you're developing a framework.

There is no doubt that PHP has not evolved by leaps and bounds over the past 3 or so years, I've been watching for over a decade at this point.  My problem is that while PSR-0,1,2 did everyone a ton of good, that is evident in all the php code that is visible in github.

The point of the proposal was to bring clarity to two separate goals.  If this groups wants to be the harbinger of codified de-facto best practices, that's fine.  I just don't think this serves the larger PHP Community as much good when it is lumped in with the initiatives that suit primarily FIG interests, particularly when you call the ratified things "PHP Standards Recommendations".

[Lukas Smith]

On Jan 11, 2013, at 16:46 , Ralph Schindler <ralph.s...@gmail.com> wrote:

> I really though there was a line in the sand with respect to promoting best practices in the community and then creating common types/implementations/framework components for general consumption (style vs. tools for interoperability). I think I am correct in asserting that PSR-3 is subject to far more subjective criticism than any of the PSR-0,1,2. For example, who decided logging was an OO facility, whats wrong with logging as a procedural/functional entity? Why are the method names nouns? Why is there a particular naming for this new type (Interface suffix)? How will this be versioned? Who decided using types better than duck typing for interoperability between unrelated projects? How will it be distributed? How will projects manage BC?

Some of the points you raise where indeed never explicitly discussed. Then again there is no reason why someone could not come up with a PSR for procedural logging etc. The point being that a PSR just defines how enough people in this group agreed something could be done. This however does not lay judgement on any other possible ways to do something.

As for some of the naming aspects etc there was a PR that covered some of the things you mentioned:
https://github.com/php-fig/fig-standards/pull/68

> You might have answers to all those, but keep in mind, those are problems of a framework. Which mean, by this group shipping code, you've started developing a new framework, or better termed, a meta-framework. After all, whats going on now in the PR queue and the mailing list is exactly the kind of discussions that happen when you're developing a framework.

Indeed its a meta-framework of sorts. For now we have however explicitly stayed away from reference implementations. There are some issues that do need more discussions. For example how to be more unit testing framework agnostic. So yeah I do agree that there are still some topics we need to address while we are working to add other things like caching and http messaging etc.

regards,
Lukas

[Amy Stephen]

I think Ralph has a point. Maybe eventually two groups will come out of this? Frankly, I'd be in favor of moving the elements of PSR-1 that support namespacing back into PSR-0 and dropping 1 and 2. Then, fully embrace the FIG and drop the standards aspect, even to the point of rebranding. There could be initial confusion, but it will pass, and clarity will help this get huge.

Projects are well able to make decisions about 4 spaces or a tab given their existing governance systems. It's a turnoff for many, we are hackers, independent spirits, it creates a distraction, in my opinion, and ends up distancing projects from participation. The big value of is in common interfaces, data requirements, and namespacing, etc.

I know it sounds discouraging to change names, etc., but my guess is that doing will send a message that would be well received as a sign of respect for the independence and ability of projects to govern themselves. With that out of the way, the value for projects to participate since doing so extends their work into new space they might not have achieved alone, starts to become crystal clear.

My 2 cents. Thanks for everyone's efforts.

[Lukas Smith]

On Jan 13, 2013, at 8:58 , Amy Stephen <amyst...@gmail.com> wrote:

> I think Ralph has a point. Maybe eventually two groups will come out of this? Frankly, I'd be in favor of moving the elements of PSR-1 that support namespacing back into PSR-0 and dropping 1 and 2. Then, fully embrace the FIG and drop the standards aspect, even to the point of rebranding. There could be initial confusion, but it will pass, and clarity will help this get huge.
>
> Projects are well able to make decisions about 4 spaces or a tab given their existing governance systems. It's a turnoff for many, we are hackers, independent spirits, it creates a distraction, in my opinion, and ends up distancing projects from participation. The big value of is in common interfaces, data requirements, and namespacing, etc.
>
> I know it sounds discouraging to change names, etc., but my guess is that doing will send a message that would be well received as a sign of respect for the independence and ability of projects to govern themselves. With that out of the way, the value for projects to participate since doing so extends their work into new space they might not have achieved alone, starts to become crystal clear.

My interpretation of this response is that you feel like there is some obligation to implement every PSR to be considered a good project. this is not the case at all .. just like RFCs you pick the ones you feel like following. obviously this still means that each PSR should provide value at least to some people. if you dont like PSR-1 or PSR-2 .. dont use them. if you like parts of them, then use them as a basis. honestly while i dont think we should go totally overboard with this, but i dont see a reason why we cannot have competing standards.

f.e. if for some reason PSR-3 simply doesnt work for a viable log implementation and others agree that as a result there is a need for another log PSR, then imho we should allow a competing PSR to be created.

regards,
Lukas

[Amy Stephen]

Lukas -

If there is a competing PSR-3, then something very wrong happened.

As this effort grows, answering the question re: PSR-1 and 2 with "No, we are not compliant with PSR coding standards." could easily have a negative impact. Further, responding why could make a project look insular and stubborn. And, maybe they are, but it can reflect negatively on the quality of their work. I beg to differ with anyone who contends that PSR-1 and 2 compliance is a measure of quality. I'll even produce clear examples, if necessary, of code written to spec, but results in a dropped database, or failure to check access control, exposing what should be private data, and so on.

Better if this group kept the focus much higher so as to *support* projects and encourage the use of good practices, but never cross that line of what is best left to project contributors. I would support, for example, this body defining a standard that defined a set of basic processes, tools, approaches that are considered minimally essential for quality work.  Does your project adopt and publish coding standards? (If not, here are some suggested standards for consideration.) Do developers use an IDE with a standard compliance checking, are unit tests defined? and do these test cover at least 50% of the source? Does the project use a source management system? Do they have a release strategy that is published?

Anyway, not to worry about me and my support, my message to projects is to comply with the PSR standards. Being able to say you are in compliance is a positive. But, I believe there are more important goals for this group.

There really is no right answer to these questions and the debate can be distracting. Perhaps the group could set a policy that the purpose of the group will be reviewed by voting members on an annual basis, revised as needed, and reaffirmed. Those interested in providing comment could be do so in a private manner knowing their thoughts will be shared at the appropriate time. It's not helpful to have to revisit purpose all the time and we're really never going to fully agree.

[Lukas Smith]

On Jan 13, 2013, at 18:53 , Amy Stephen <amyst...@gmail.com> wrote:

> If there is a competing PSR-3, then something very wrong happened.

i dont envision a necessity to do this very often at all .. but the HTTP spec has seen updates, competing/overlapping specs etc.

> As this effort grows, answering the question re: PSR-1 and 2 with "No, we are not compliant with PSR coding standards." could easily have a negative impact. Further, responding why could make a project look insular and stubborn. And, maybe they are, but it can reflect negatively on the quality of their work. I beg to differ with anyone who contends that PSR-1 and 2 compliance is a measure of quality. I'll even produce clear examples, if necessary, of code written to spec, but results in a dropped database, or failure to check access control, exposing what should be private data, and so on.

I would say that a following a sufficiently complete coding style is a measure of quality. PSR-1/PSR-2 is one option and if you dont have one atm, then probably it would be a good idea to adopt it. if you already have a different well defined CS then its ok to keep using it. it is my understanding that this was the point of view the majority of this group has.

now if some people then decide to label a project that already had its own CS as "insular and stubborn" seems like just another case of someone not knowing or not caring about these realities. not much we can and should do about that except for communicating clearly.

i dont think that communicating clearly is done via a separation of the current PSRs but instead in ensuring that we do not intentionally or unintentionally perpetuate an opinion of labeling any project as "insular and stubborn" if it doesnt follow a PSR if there are historical reasons.

> Better if this group kept the focus much higher so as to *support* projects and encourage the use of good practices, but never cross that line of what is best left to project contributors. I would support, for example, this body defining a standard that defined a set of basic processes, tools, approaches that are considered minimally essential for quality work. Does your project adopt and publish coding standards? (If not, here are some suggested standards for consideration.) Do developers use an IDE with a standard compliance checking, are unit tests defined? and do these test cover at least 50% of the source? Does the project use a source management system? Do they have a release strategy that is published?

the people that have voted in favor of PSR-1 and PSR-2 seem to have disagreed with your POV that the group should not have passed a PSR on coding style. i think at some point its necessary to move on unless suddenly a majority of members decides that indeed PSR-1 and PSR-2 are detrimental to the intention of this group. however i would urge people to stop checking if opinions have changed on a bi-weekly basis.

> Anyway, not to worry about me and my support, my message to projects is to comply with the PSR standards. Being able to say you are in compliance is a positive. But, I believe there are more important goals for this group.
>
> There really is no right answer to these questions and the debate can be distracting. Perhaps the group could set a policy that the purpose of the group will be reviewed by voting members on an annual basis, revised as needed, and reaffirmed. Those interested in providing comment could be do so in a private manner knowing their thoughts will be shared at the appropriate time. It's not helpful to have to revisit purpose all the time and we're really never going to fully agree.

If we all had infinite time this would be a good idea indeed. but i fear this will just lead to regular nit-picking sessions where everybody that hates a detail will attempt to see something changed or revoked. i am not saying that this will be done with malicious intend. we must also realize that especially due to legacy support many of our standards will take years to really trickle down into the main stream of our member projects, let alone outside of it.

if there is indeed something to change, then it should imho be simply done via a superseding PSR.

regards,
Lukas

[Amy Stephen]

Lukas -

I agree following a coding standard promotes quality, that's why I listed it as a good programming practice. Where we perhaps differ (and where, as you correctly point out, the majority of the membership differs with me) is that it might be better to focus at a higher level, encouraging good practices, in order to avoid overshadowing project governance.

My last comment on review was intended as a suggestion that might save time. Judging from the number of threads and blog posts on this very topic, adopting a practice of annual review might save time. That way, with each new forum thread on the topic, a link to the policy could be shared and the debate avoided.

These are just opinions I hold. Food for thought, nothing more.

[Ralph Schindler]

I think enough discussion has likely happened on the matter, could someone in the php-fig organization open up a vote as per the process and finalize this PR?

https://github.com/php-fig/fig-standards/pull/76#issuecomment-14197385

Thanks,
Ralph

[Olekhy Khutoretsky]

hi @all

PSR is a good thing
any art of source code within namespace PSR\* is not

-1 for
PSR that must be presented the source code
(in the world not only Frameworks also other PHP stuff exist)
+1 for
PSI (PHP Standard Interfaces), SPL or any other name for library with examples how made PHP program better and compatible at all

[Pádraic Brady]

Hi all,

As I understand the bylaws, any call to vote requires a sponsoring voting member. In the absence of such a sponsor, PR76 should be closed.

Paddy

[Phil Sturgeon]

This PR has been closed after a really long and relatively fruitless conversation about it all.

I added two extra questions to the FAQ to explain some of it at least:

https://github.com/php-fig/php-fig.github.com/pull/65/files

[Pádraic Brady]

Thanks Phil,

You actually closed before I asked too. Must update my browser view next time :P

Paddy

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative

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

[Amy Stephen]

Ralph -

The way that this was handled *sucked.* I would like to have seen a little recognition of that point. Wouldn't have cost a dime to stand up and say this wasn't handled well. Wouldn't have hurt to admit a mistake in judgement.

Having said that, there is nothing in the bi-laws that guarantees those of us who are not members get a vote on our requests. There was no rule broken. There has been no discussion for a long time. It is perfectly reasonable to close this. No one in the membership wanted to champion it. Had they wanted to do so, it would have happened a long time ago. I believe that also needs to be said.

You also recommended a different naming approach for FIG activity that you felt did not fit under the label of a PHP Standards Recommendation. I appreciate how you acknowledged that there is no real answer to that. Personally, given the PHP native interfaces, I see how PSR can fit those as well. I also have no problem naming them FIG, like you suggested, or PSI, as someone else suggested. But then again, apparently there is something deeply wrong with me because I have absolutely no preference on the tab or space issue, either. No matter how hard I try to pick a side, I can't there, it just seems pointless to me.

In the end, these specifics do not matter but how people are treated when they approach this group and the processes used to consider ideas - do matter. This situation did not serve as a model of how to do it

Ralph - I am sorry for my part in this that created tension that led to your PR to be closed so abruptly. My actions also played apart. I hope you can see this situation for growing pains, like others correctly said, not let it impact how you feel about this initiative. I believe your point was heard, I can see attention on defining focus, I believe you had the impact you hoped for and appreciate your raising the point for consideration.

Thanks. Amy

[Pádraic Brady]

Amy,

Closing the issue was entirely down to the bylaws requiring a voting
member to sponsor a vote so I'm not sure the handling sucked. I've
already made a mental note to ensure that getting to the voting bylaws
and understanding how they impact on non-voting members is clarified
(even I had to dig more than strictly necessary to locate the damn
things!).

Paddy

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative

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

[Amy Stephen]

Nothing was done that failed to meet the standard of the bylaws. 

Adding a process for how items are considered, rejected or accepted could help.

Adding a process for how FAQ items are reviewed by membership, would be recommended.

The voting aspect is clear.

The rules were applied in a fair way and the end result is reasonable.

Personally, I don't believe in code of conduct policies because the problem is seldom a question as to what constitutes reasonable behavior. We really do all kind of know that. Policies tend to end up getting used in the wrong way, create more of a problem than any they solve. I have always believed a single rule "Don't be a jackass (all the time)." ends up helping so much more.

I don't know why things happened the way they did. I believe my involvement had a part in it and I apologized for that. But I do know the way it happened would leave most people  feeling like they were not heard or treated with respect. I think that is unfortunate.

No rule violation. No new rules to write so that it's fixed. We are dealing with human beings here and we don't have unit testing. It's just one of those days where someone walked away very likely feeling as though they had not met up with a friendly Internet neighbor. We've all had that happen, it never feels good. I am sorry for anything I did that contributed to that result.

Hope that helps.

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

To post to this group, send email to php...@googlegroups.com.

[Jordi Boggiano]

Can we all just take a breather and stop posting for a day or so? Enjoy
your week-end, and start moving forward again on Monday with a clear head?

I just can't be arsed to read emails anymore due to the high traffic,
and I feel I'm not the only one.

Note that this does not apply just to this thread.

P.S.: If you don't agree, please feel free to just ignore this, but
don't let this email start yet another debate.

Cheers

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