Added "Group Clarity" proposal for PSR vs. FIG. #76

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet

No description provided.

Contributor

dongilbert commented Jan 12, 2013

👍 couldn't have said it better. PSR-3, IMO, should be moved to FIG-1, since it really is 100% to do with framework interoperability, rather than PHP Standards.

+
+The current PHP-FIG group are the ambassadors for a movement that has by and
+large been promoted throughout the PHP community. Those standards are promoted
+by Framework members of the PHP-FIG group, but by and large, developers who
@eddieajau

eddieajau Jan 12, 2013

by Framework members of the PHP-FIG group but, by and large, by developers who

jmalloc commented Jan 24, 2013

Definitely agree, this is an worthwhile distinction.

I also think this is an important distinction to make. I tried to raise the point a while ago on the mailing list but it didn't receive much support (although I didn't express my point nearly as eloquently).

I hope the issue gets some more serious consideration this time around.

Contributor

Crell commented Jan 24, 2013

This was discussed on the list, and determined to not split the group or the labeling. It was also determined that a list discussion rather than a PR is the correct way to have this conversation, as doing so here was kind of weird. :-)

olekhy commented Jan 25, 2013

Ups... License will added when all frameworks used and realized this interface (PSR-3 Logger Interface ). NICE WAY...

prolic commented Jan 25, 2013

👍

Contributor

skyzyx commented Feb 27, 2013

I disagree.

Yes, many people have misunderstood our intent. But instead of catering to the misunderstanding, why not just do a better job of clarifying what we do?

I do not plan on closing this PR, and it has been around for nearly 2 months. If there is a group consensus, could you reject this by a vote and close this PR?

I think you'd have more chance of training a kangaroo on its head than getting this passed. PSR-3 is out there and even though I somewhat agree with your perspective, there's no point is trying to move this mountain.

I have no intention to train kangaroos or move mountains. :) This group has a process, and I am simply offering that enough discussion on this matter has happened, and I think there is enough in the PR to bring to a vote ... let people put their vote down, and finalize this matter. I realize it will likely get rejected, but it should also go on record who votes and how.

Contributor

bobthecow commented Feb 27, 2013

Per the group's process, you need to convince a voting member to champion your proposal, or a vote will never happen.

I'm just being realistic and I think you should be too. The PSR-2 debarcle should be a testament to that. I'm not one for giving up, but in this case I think you have far more interesting and fruitful things to be working on.

olekhy commented Feb 27, 2013

+1 @ralphschindler
commit explains that the PSR is not a lib or any art of source code which can be installed or import into project for developing a big useful page writen in PSR way

The bottom line is this PR cannot be merged because it's presenting a case. Nobody is going to entertain voting on a document that's headed "Bring Clarity Of Purpose To The PSR/FIG Group", no matter how well intentioned.

Second, you are also trying to ammend PSR-3. You can't do both in the one PR and it's totally inapproprate to do both in one vote (we don't even have a clue yet as to how to ammend a PSR anyway).

The bottom line is you might as well close this PR because it's not done correctly, not that we quite know what correctly is, and I have my doubts we will know any time soon, but this is not the right way. In all fairness, asking for a vote will just be wasting the time of the voting members. I hope you understand.

olekhy commented Feb 27, 2013

plz don't close

all of them that has written more than 512 characters in a comment are not to act in a position clearly
i hope you understand me

The comments are still visibile even when you close it.

prolic commented Feb 28, 2013

@ralphschindler hit the nail! this PR is definetly worth discussion. Do not close it! Let's bring it to a vote instead.

By the way: PSR-3 is dead before it's born! What kind of framework interoperability do you expect when major frameworks like ZF won't implement this stuff?

olekhy commented Feb 28, 2013

Abusive comment removed.

Contributor

dongilbert commented Feb 28, 2013

Because Framework Interoperability is a bad thing? :facepalm:

On Thu, Feb 28, 2013 at 3:53 AM, Oleksandr notifications@github.com wrote:

fig must die


Reply to this email directly or view it on GitHubhttps://github.com/php-fig/fig-standards/pull/76#issuecomment-14225351
.

prolic commented Feb 28, 2013

@dongilbert No, because it's the wrong way! You can have framework interoperability by using adapter and bridge pattern. There is no need to invent a common interface with minimal functionality. This way you end up with duck typing, to check if the class has the additional features you want, because the minium interface won't be enough at the end.
FIG just will die, no matter what I say and no matter how much the fig tries to invest in the situation. I even fear that PSR-3 can harm the applicalibility of PSR-0, PSR-1 and PSR-2 because now PSR loses its right to exist.

Contributor

skyzyx commented Mar 1, 2013

Does GitHub have a troll filter we can use?

Contributor

AmyStephen commented Mar 1, 2013

@prolic is basically expressing the same point of view that @weierophinney shared in his "On php-fig and Shared Interaces" post.http://www.mwop.net/blog/2012-12-20-on-shared-interfaces.html

I find it interesting, during the log project, I made a similar comment about Adapters, got a very strong response - thought I was way out of line, or something. I'm guessing it's (maybe?) how @ralphschindler might see things?

So, this is our Zend folks, definitely not trolls, members in fact.

We are talking about adding some structure that makes it more clear where input is needed and the status of various activities. It was suggested that this issue figure into that discussion https://groups.google.com/d/msg/php-fig/BIs5ZyqPc1E/zOc4pdvWNcYJ

The question would be since these processes are, indeed, different, how would adapting the structure of how this effort is organized better support both types of activities?

Rob Allen @akrabat made a vague comment that he promised to explain later with beer - I'm wondering if this might have been what he was talking about.

Would you Zend people (and others who agree with this point of view) please join the groups discussion and see - is there something that can be done to help make certain your goals can be achieved with this effort?

Contributor

AmyStephen commented Mar 1, 2013

@olekhy is also Zend, so, let's if we can get this figured out. But, let's use the Google Group to discuss https://groups.google.com/d/msg/php-fig/BIs5ZyqPc1E/zOc4pdvWNcYJ

Contributor

AmyStephen commented Mar 1, 2013

@skyzyx Ryan - I wanted to point out that your comment maybe isn't the way things started. I hope you take to read that shared interfaces post. I think there might be a very basic misunderstanding - it seems that the direction shifted from this direction. So, maybe the opposite of what you are saying? I don't know, just wanted to make you aware and see what your thinking is. Thanks.

Contributor

skyzyx commented Mar 1, 2013

@AmyStephen:

I was referring to @olekhy's comment, which was clearly trolling.

@prolic's comment was borderline trolling, which he (she? I don't know) wrote simply because he disagrees with shared interfaces.

[...] because now PSR loses its right to exist.

But you were right to call me on it. Thank you. All of this recent PSR-2 business has depleted my patience for inflammatory statements.

Having said that, anyone can choose to behave like a troll — member or otherwise. Working on ZF (or any other large project) isn't an exemption from the behavior.

olekhy commented Mar 1, 2013

first SRY at all for my comment and my english.

i say what i means SHORTLY! and that is.

all of things are made clarify and not identical with you were trolling make your eyes open and see real world
sorry for using of DIE yours right i (we) need EXIT from PSR/FIG mix confusing story

me means that the many of people here make only stupid traffic

Contributor

AmyStephen commented Mar 1, 2013

@skyzyx Sorry for the confusion. To be clear, I also thought there was trolling, given the other situation. The comment I linked to of yours is something from earlier and I am starting to think that maybe the Zend people see that point differently, which could explain frustration. The only reason I pointed that out for you was to get your input on that possibility, definitely not to call you out.

I think there is a lot of honest confusion here, given the recent resignation of the Zend member, yes, it's likely there is more frustration than before. Not an excuse, but it might help explain.

@olekhy - I am lucky that we all communicate in my native language because I do not know any other language. I can't imagine how difficult that is. I am sorry for assuming you were trolling. Let's try to get this figured out. =)

Contributor

AmyStephen commented Mar 1, 2013

@skyzyx Ryan - one more comment, @prolic 's comment is a basic recap of the blog post I pointed to earlier.

While this statement here might easily be interpreted to suggest a negative (ex. "You guys suck and don't deserve to exist') which is how I took it.

...because now PSR loses its right to exist.

I believe the point was much more simple and related the issue starter's point that there are two different aims underway. One is standards, as conveyed by the letters PSR, which stand for "PHP Standards Recommendation" and the other is the "FIG" or Framework Integration.

If I am understanding the intended point, the statement is saying that PSR3 is not (in the opinion expressed below) a 'PHP Standards Recommendation', but rather a 'Framework Integration' (group) project. If I am understanding correctly, the author is suggesting that by labeling it as a PSR, the group (FIG-PSR) could "lose the right" to label any of the work a "PSR."

The overall point, if I understand correctly, would be that this work should be separated and the integration projects not labeled as PSR's.

Now, maybe I am wrong on what point the Zend folks are trying to make. It's been hard to figure out. But, we need to understand it, that I think is important.

Contributor

weierophinney commented Mar 1, 2013

So, this is our Zend folks

Please don't make this into a "Zend Framework vs PHP-FIG" argument. Yes, I represented Zend Framework, and yes, many developers from the ZF project have similar views to mine. However, I've also heard these same views (dislike for shared interfaces, desire for separation of standards from interop, etc.) made by others (most of whom choose not to participate in PHP-FIG for these and other reasons).

Address the ideas, not the messengers.

Contributor

AmyStephen commented Mar 1, 2013

@weierophinney To be just as frank as you are, I resent the tone of your comment. I am trying to enable communication that I believe has been misunderstood. There is no implication in my identification of individuals as "Zend" except to show respect and after having reviewed their profiles. Having said that, I appreciate the point and will not make that mistake again. My intent was to help give voice to these concerns, it's fine to not recognize that but the implication that I am isolating the group as a problem, or something, could not be further from the truth. I am trying to help.

prolic commented Mar 1, 2013

First of all, sorry for all who felt attacked by me. This was not my intention, I just don't know english good enough. I am no "Zend folks", I am just an open source developer. I contributed very much to Zend Framework but that is not my only horse, and I don't get payed from Zend Technologies. I am human, just like you.
Perhabs I should better explain the point "PSR is losing the right to exist", because now there is lot of misunderstood discussion around here about that sentence:
The distinction between PHP Standards Recommendation and Framework Interoperability is important. It's not only a valuable distinction but also helps teaching others.
One thing is the bring the developer community to the point, where all source code is formatted the same way which helps you reading it and also contributing it (because you know the style guides already).
A total different thing is, to invent shared interfaces, which is a programming instruction.
How can you teach someone to use PSR-0, PSR-1 or PSR-2 when his main arguments against PSR is the he dislikes the programming instructions and wants to use his own interfaces which provide him with much more functionality and no need for duck typing, to see whether or not the object has the additional features, he is looking for? He might say, that PSR is not suitable for his project, and when PSR and FIG is mixed up, we lose also the applicalibity of PSR-0, 1 & 2 (where PSR-0 is the only one with real wide acceptance, but even there lot's of exceptions). FIG is a different from PSR. So it should be labeled different.

My personal view of point is not important for this situation. I don't even expressed it, yet! If someone wants to know my real opinion on PSR, here you have it, otherwise skip here :-) PSR-0 is great! All projects should be using it. PSR-1 and PSR-2 are nice for frameworks, where you want to have a nice and consistent formatting style. But PSR-1 and PSR-2 are NOT important for php developers. They have no real right to be present, because it's only formatting, which is unimportant for the source code to work. PSR-0 is different, because it has a real rule of thumb: 1 class per file, changing this rule would break lot's of autoloaders, breaking formatting rules will not harm anyone.

@dragoonis or @pmjones could you please close the PR. Thanks in advance.

Contributor

AmyStephen commented Mar 1, 2013

Not yet, please. There is a poll that people should vote on that discusses the focus of the PSR-FIG group and gets into the points raised here Go Vote and we have asked to consider the points raised in this issue for the Workflow Structure. It will not be long and it should be resolved, one way or the other, but it could create unnecessary tension to close it now. Let's keep it open until that time, it won't be long and there is no hurry.

Contributor

AmyStephen commented Mar 1, 2013

@weierophinney Reading your comment, I can see I read a lot in that wasn't there. I'm done now reading all these comments in all these places. Trying to think thru the structure and picking up on tension that would be nice to reduce. That tension starts to get in you and I wrongly projected it on your response. I'm truly sorry. Time to walk away for now.

Contributor

skyzyx commented Mar 1, 2013

@prolic, Thank you for the clarification. That makes a lot more sense.

There is a parallel discussion happening where a similar topic has come up — separating the Normative vs. Informative (aka Current Best Practice vs. Finalized).

https://groups.google.com/forum/?fromgroups=#!topic/php-fig/uMB4B7uZ7FY

It sounds as though many people have similar ideas in this regard. I've proposed a bylaw in an attempt to address this very thing. I think your input would be very valuable in the discussion.

@AmyStephen, I understand better what you're talking about. I hadn't actually clicked in the link before, and had assumed you were calling me on my snark. My bad.

You're right — there seems to be disagreement/disconnect on what the purpose of the group even is in the first place (wha—?!). I think the poll will help us figure out where to go next.

And thank you for shepherding this conversation.

BTW, my position does not necessarily reflect that of the ZF project or community. My position represents the PHP community at large that was, in my opinion, mislead to believing the focus the PSRs way intended for a larger audience than those individuals interested in only "framework interoperability" (which I believe to be a large portion of the PHP community that was following and aware of the existence of PSRs).

Nevertheless, I believe some kind of focus and clarity is required, which I believe the mailing list is attempting to address at current.

Contributor

philsturgeon commented Mar 1, 2013

Another request to close this pull request @pmjones or @dragoonis.

The original goals of the PHP Standard Recommendation group, which then morphed into the Framework Interoperability Group were noble.

The group didn't morph, it was renamed to reflect more accurately the intentions of the group.

  • PSR = PHP Standard Recommendation
  • FIG = The group that makes PHP Standard Recommendations

Thats quite easy.

This has become evident in the pull request queue where most pull request are suggesting an "official way" to write code, in the form of interfaces, shared implementations and the like.

They're all being closed down, because they are nothing to do with this group. I am however using them all for inspiration to write new sections on PHP The Right Way, which is a great place to put this sort of content.

Contributor

AmyStephen commented Mar 1, 2013

@philsturgeon I am confused by your comment and then your 5 vote on the poll. I guess I would have expected you to vote a high value, like a 10. https://groups.google.com/d/msg/php-fig/wNICVGwjE9s/gHFO7swCkIUJ

@ralphschindler Sorry about projecting that on you. Do you think the issue can now be closed? If so, go ahead and do that otherwise, I personally see no hurry or reason someone else should close it right now. I think we are almost there.

Contributor

philsturgeon commented Mar 1, 2013

PSR-2 is something that effects humans (us, on the FIG) and PSR-3 is something that effects code.

All of these things meet the primary goal of the group:

The idea behind the group is for project representatives to talk about the commonalities between our projects and find ways we can work together.

Somebody else said:

Finding commonalities between member projects and codifying them.

That doesn't mean specifically CODE, it means rules which we can all follow to make our code interoperable, and interfaces are a perfect implementation of rules in code.

Anything else is just "This is how you should write good code" which has nothing to do with the FIG at all.

This is all subjective. But ...

Exactly my point, @philsturgeon, calling something a PSR (PHP Standard Recommendation) when the intended audience is only member frameworks is doing a disservice and detracting validity from things like PSR-0-2.

Finding commonalities between member projects and codifying them.

That mission statement came about in June, which was after PSR2. If this is the direction of the group, I feel you guys should change the name of the recs. to from PSRs to FIGs and be done with it. What you have now is misleading, and I feel if you continue using PSR to pass off framework interoperability recommendations, I don't feel I could personally every suggest people follow any recommendations from this group on a wholesale level - and I don't think I am alone in this opinion.

I am not closing this pull request. I suggest the voting members come to consensus before closing this to ensure it at least looks like there is some kind of process in place as opposed to a dictatorial style decision.

Contributor

AmyStephen commented Mar 1, 2013

@ralphschindler I agree and that's underway. I'd be a little unhappy to see it locked down, too.

I have a question for you, though, and I appreciate how you have lead with "this is all subjective" - because in a sense this might be another tab -vs- space thing. ;-)

But, my question is how is the Log Interface really any different than the PHP Interfaces? http://php.net/manual/en/spl.interfaces.php

It's very easy to see that PSR-0, 1, and 2 are PHP Standard Recommendations. It's a little harder to see Interfaces in the same way, except PHP has Interfaces now. Is it possible since it's newer it might take awhile for our thinking to also adjust?

Thoughts on that?

Contributor

philsturgeon commented Mar 1, 2013

@ralphschindler: The website happened after PSR-2 sure, but thats because we didn't get around to it until then. That doesnt mean the purpose is any different, just that the website wasnt up.

Moving on: Naming things is hard.

PHP Standards Group

That was wrong, so it got renamed to:

Framework Interoperability Group

Which started as frameworks but is now CMS, random packages, forum systems and all sorts of other stuff.

Calling them FIGs would be a disservice to non-frameworks.

We should really rename PSR's and the FIG to some new magical name which reflects everything perfectly and doesn't offend anybody, but coming up with that name is going to be impossible. The group turned down my suggestion to call it "The PHP Super Best Friends Club".

Right now I think people are putting WAY too much onus on the name. We're a bunch of general PHP projects, so we've got a fairly generic name for the recommendations we produce.

Contributor

ashnazg commented Mar 1, 2013

To start the brainstorming: PHP Interoperability Group, that presents both
Recommendations (1, 2) and Specifications (0, 3)... ?

CRB
about.me/ashnazg

Are people seriously caring about what this is called? There are way more important things to put your mind to instead of a name... you would think people who work on PHP, probably the most inconsistently named language (in regards to functions, methods, classes etc), would be able to deal with a name not quite being perfect.

Contributor

philsturgeon commented Mar 1, 2013

The PHP Interoperability Group makes it sound like we're trying to integrate with Java.

Contributor

bobthecow commented Mar 1, 2013

"PHP Standards Recommendation" is good enough. The IETF standards are called "Request for Comments" for crying out loud.

Contributor

AmyStephen commented Mar 1, 2013

Guys - the main thing is that people are heard, which means first, try to understand their point of view, and be careful please, not to discount it. I do not see someone trying to create problems but rather someone who like to back this group but has a concern to resolve. I think it's close, given the poll, so, no reason for anyone to panic (said gently.)

Contributor

ashnazg commented Mar 1, 2013

LOL :-) s/PHP/Projects perhaps?

CRB
about.me/ashnazg

On Fri, Mar 1, 2013 at 11:50 AM, Phil Sturgeon notifications@github.comwrote:

The PHP Interoperability Group makes it sound like we're trying to
integrate with Java.


Reply to this email directly or view it on GitHubhttps://github.com/php-fig/fig-standards/pull/76#issuecomment-14301931
.

Contributor

philsturgeon commented Mar 1, 2013

@bobthecow agreed. Also, the name of the group puts the PSR into context.

The "Framework Interoperability Group" are putting together "PHP Standard Recommendations" for how we/they write their PHP.

It's like a local "Neighborhood Watch" putting together a strategy called "Security Guidelines". The FBI and Interpol won't be using those guidelines, and nobody is going to be confused about that. It's all about context.

Contributor

bobthecow commented Mar 1, 2013

@AmyStephen the difference is that when an interface is baked into the PHP standard distribution, it requires no change to the projects dependencies outside of having "just php". When the interface is housed in another framework, in this case, the PSR/FIG framework/meta-framework, you need to somehow import that code (composer, package manager, etc). Not only does that now mean you have an external dependency, but it also means you need to at least have some form of 3rd party code manager as part of your process. With interfaces in PHP itself there is no implication on project dependencies and build processes.

@philsturgeon

Calling them FIGs would be a disservice to non-frameworks.

as per the sites mission, non-frameworks are not your audience

Our main audience is each other, but we’re very aware that the rest of the PHP community is watching.

Contributor

AmyStephen commented Mar 1, 2013

@ralphschindler My point is a little different, when we say PSR, it is saying "PHP Standard Recommendation", with the suggestion, at least, that PHP might adopt it. If such were the case with the Interfaces, then it would be the same thing, is that right? So, instead of bringing the interface in, via Composer, it would be "baked in", as you say, in PHP if they adopted the PSR, and therefore all projects would benefit. In that sense, to me, it could be dubbed a PSR, if you will. Anyway, it's maybe one way to look at it.

I agree with your point, too, that Phil is, maybe without understanding it, making your point about clarity, definition, scope.

Contributor

philsturgeon commented Mar 1, 2013

@ralphschindler what do you mean?

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.

It says "projects"...

Contributor

philsturgeon commented Mar 1, 2013

@AmyStephen PHP itself does not need to implement a logging interface. Why would they?

Logging packages and frameworks that implement logging functionality can require the logging interface - it doesn't need to be in the core and nobody is suggesting that PSR-3 should be in there.

Contributor

AmyStephen commented Mar 1, 2013

In that case, @philsturgeon the question posed is absolutely appropriate, why call it a PHP Standards Recommendation if it's not recommended for adoption by PHP? That is what is being asked here.

I think maybe you're moving too quickly and not really understanding the question -- this isn't about being right, it's about bringing others along. What good is the PSR-FIG group if no one understands the mission or feels pushed out because their questions are considered trivial, or whatever.

Here the part where you described how the thinking of the group changed:

Moving on: Naming things is hard.

PHP Standards Group

That was wrong, so it got renamed to:

Framework Interoperability Group

Which started as frameworks but is now CMS, random packages, forum systems and all sorts of other stuff.

Calling them FIGs would be a disservice to non-frameworks.

See the shifting? That is exactly the point that is raised by @ralphschindler - he is saying "Stop a second. Define the mission clearly. There has been a lot of change. What you call a PSR is no longer destined for PHP, call it something else."

You seem to be saying the same things, but for whatever reason, you aren't acknowledging the point. Not sure I understand other than it seems like you might impatient with it - is that possible? Earlier, I snapped at someone when it was silly to do so. It can happen.

Does that make sense?

Contributor

philsturgeon commented Mar 1, 2013

I see what you're saying, and its not about being right. I'd love to help the whole PHP community understand which is why I dedicated so much time and effort to conversations like this and it's why I put the php-fig.com FAQ together.

Firstly, we're hardly moving quickly. Changing the google mailing list to PHP-FIG happened almost a year ago:

https://groups.google.com/forum/#!searchin/php-fig/new$20name$20group/php-fig/vjiT3hUmmEY/MIIYxQ9swAMJ

Secondly, your assumption that a PSR has to be included in PHP - or is even intended to - is entirely your own. PSR-0 was trying to be baked in because it is autoloading, but we're not trying to bake tabs or spaces into PHP so why would we try to bake a logging PSR or anything else? Nobody said this was the point.

So what is the point? That has been answered a lot of times on the website, and I would like more feedback on this. Again:

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.

This is the goal, and this is what we have been doing. We're sorry the name was wrong initially, but it's a little better now. Maybe the FIG could get a new name to include more than frameworks, but that certainly doesn't seem to be the main issue people are having with names. The issue seems to come from them being called PHP Standard Recommendations.

Now, this name by itself sounds far reaching, but they are made by a group called the Framework Interoperability Group.

As I said above:

The "Framework Interoperability Group" are putting together "PHP Standard Recommendations" for how we/they write their PHP.

It's like a local "Neighborhood Watch" putting together a strategy called "Security Guidelines". The FBI and Interpol won't be using those guidelines, and nobody is going to be confused about that. It's all about context.

The group, who has a fairly clearly explained mission, have put together some guidelines on how they wish to write their PHP, maybe for their projects if they want to, but definitely for any interfaces that the group release.

That's the sum of it.

Contributor

AmyStephen commented Mar 1, 2013

The group is not moving quickly, I am talking your approach, the rapidness of your answers, tossing in a little mocking with the name thing, brushing off points.

Standards groups are notoriously slow because the goal is consensus not a long list of rules that a group with authority made so. The only authority this group gets is based on size of the body in true agreement. Important not to rush these discussions, try to close them, people end up not hearing what is being said. In the end, that impacts participation. These are the things we are hearing these people say.

Now, I am not making any assumptions, and it's not helpful for you to claim that. What I am trying to do is understand the point someone is making, so I use techniques like repeating my understanding of their point, and then waiting for confirmation or different explanation. Nothing I have said in this thread is about what I think is right. Trying to figure out exactly what it will take to resolve this and add more bodies to the group that have agreement.

That's the sum of it for me.

olekhy commented Mar 1, 2013

simple explain

https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md //accepted

    public function error($message, array $context = array());

this one fail unless my $context is an object

WTF LoggerInterface
plz move this one to the wikipedia FCTL

Contributor

AmyStephen commented Mar 1, 2013

@olekhy please avoid inflammatory words, okay? Or the "child to learning" that's mocking, no one hears. Thanks.

Contributor

philsturgeon commented Mar 1, 2013

@olekhy do not derail a valid conversation. Please leave your feedback somewhere more appropriate, like Reddit.

Amy: Then I no longer understand what your point is. I've not brushed off any points, and I actually suggested that name to the group because I'm a fun guy, we have fun. If there is a point I've missed then let me know so this can continue to be a constructive conversation, but I don't see anything I left out in my incredibly descriptive answers above.

As to your point about "rushed decisions", these PSRs took a LONG time to get together. There was a huge amount of discussion about all of them and everyone in the group (and plenty outside of it) had their say. The PHP-FIG can't let the whole PHP community to have their say and it certainly cannot wait until the entire group agrees with everyone else, this is why there is a voting process.

Even trying to work out the suffixes for PSR-3 was a joke, with 100 messages saying "I prefer Loggable" and another 100 saying "I prefer LogInterface". None are right, and at some point you have to say "Ok enough talk, lets have a vote".

The group votes on group matters. The group is an authority on stuff that is important to the group.

But really, I've been answering questions, solving their confusions and explaining misinformation. What else can I do to help? What will make this all stop, so we can get back to trying to work on useful standard interfaces, like the HTTP message standard?

@philsturgeon philsturgeon referenced this pull request in php-fig/php-fig.github.com Mar 1, 2013

Merged

Added two questions to the FAQ #65

Contributor

AmyStephen commented Mar 1, 2013

@philsturgeon First, I know you are working hard. What might help is if you first explain what the point of view is of the poster. What is he saying? How does he see this issue resolved? Then see, does he agree? From there, see if the two of you can agree on a way to resolve his concerns. That'll help, a lot. Get him to voluntarily, without undue pressure or force, close this 2 month+ issue on his own. ;-) (That is humor, nothing more).

Thank you.

Contributor

philsturgeon commented Mar 1, 2013

@AmyStephen this is what I've been trying to do, but your discussion confused the points. I was talking to @ralphschindler about his point of view, then you started replying and I ended up talking to you about yours instead - which I don't understand at all anymore.

Let me talk to @ralphschindler and see if we can't work things out. Ralph, if you have any more questions please let me know, but im pretty sure I've answered everything you've asked.

Contributor

AmyStephen commented Mar 1, 2013

The lady steps aside.

Member

dragoonis commented Mar 1, 2013

Hey,

Since this PR had initial merit but has now turned into a bit of a free for all mailing list type discussion i'm going to close this, there's no real consensus here just people throwing in their own opinions on things.

The point of "The Framework Interop Group produce PHP Standards Recommendations" seemed solid, and is in alignment with what we already do.

@ralphschindler if you're still not happy with the FIG group producing PSR's then please open up something on the mailing list and if/when consensus is met by a vote taking place then we should come back to github and open a new clean PR.

Cheers,
Paul

@dragoonis dragoonis closed this Mar 1, 2013

Member

dragoonis commented Mar 1, 2013

The PR php-fig/php-fig.github.com#65 has been made to improve clarity on some points raised in this PR.

@dragoonis, as per my original comment:

I am not closing this pull request. I suggest the voting members come to consensus before closing this to ensure it at least looks like there is some kind of process in place as opposed to a dictatorial style decision.

I've already brought my issue to the list, I've made the proposed changes in the form of this PR, and I've asked that a voting member initiate a vote. https://groups.google.com/d/msg/php-fig/M3aQOTdCoy0/S6_scoK9OqQJ

I believe I've done enough to demonstrate what I'd consider a very real qualm from the "PHP Community At Large"- which is suppose to be represented according to the FIG index page. In any case, I am checking out of this discussion.

Contributor

AmyStephen commented Mar 1, 2013

There is nothing in the patch that was accepted that even come close to addressing the points raised in this pull request. The last comment made asking the poster if he still had problems with the FIG group producing PSR's also misses the point raised.

If this is how it's done, my continued involvement in PHP-FIG would be a waste of my time. I'm out.

Contributor

bobthecow commented Mar 1, 2013

@AmyStephen there's a lot of noise, and no consensus on process or even purpose and vision for the FIG yet. This probably isn't "how it's done" since we haven't defined how anything's done yet :)

Stick around, let's work through our growing pains together.

Contributor

Seldaek commented Mar 1, 2013

@AmyStephen best thing to do (as I think most are doing, including myself to some extent) is to wait it out a few days, let everyone calm down and the dust settle. Then hopefully we can make sense of it all.

Contributor

padraic commented Mar 1, 2013

With respect to @ralphschindler, unless the PR attracts a sponsor shouldn't the PR be closed once the avenues of discussion have been exhausted? If further discussion is required, there is a mailing list for this purpose. Keeping this open pending votes and further comments is simply extending its life artificially for no good reason.

Contributor

AmyStephen commented Mar 2, 2013

@bobthecow @Seldaek - I appreciate your comments. It means a lot that you bothered to even say anything. I am not a member and I have no rights to decide how things are done. I've been thru a situation where the process integrity was not ensured and it was not fun.

Just to set the record straight on a few points, for my own peace of mind:

I was in this thread on a member's recommendation that we try to see if a little more structure might address Ralph's concerns - I was hoping to help set things up better so that the things that happened next week wouldn't be possible.

It is important to understand @ralphschindler did not start this thread up again, there was a little conflict (unrelated to Ralph) which turned out to be a misunderstanding and language issue. The confusion, which I also thought was trolling, started to dawn on me when I was researching the concern, came across blog posts (linked above), started reading the comments, and then understanding the point. That's when I posted in to explain what I was doing, where people could go to post, and why what was thought to be trolling wasn't.

@padraic - There is nothing in the bi-laws or rules or FAQ items that spell out how a PR is closed. From practice, they are closed when a member feels it should be. There was no rule broken. In terms of standard practice, had it been closed yesterday, when it had sat idle for a couple of months, I would have thought nothing of it.

As you can see, in response to me Ralph indicated he was content to work in the forums, He was not discussing in here.

The discussion which should take place in the mailing list as @padraic correctly points out - was initiated and driven by @philsturgeon until I finally stepped aside and shortly thereafter an FAQ PR was accepted, and this issue was closed.

To tie it together: Phil's forum post from a couple of hours ago as to reasons it was closed.

What was learned

  • Define the process for how issues are rejected or accepted.
  • Define processes for your FAQ changes, too. The FAQs ends up being like "law" so get oversight there too.

What's a little mind blowing is Matthew's comment "Address the ideas, not the messengers." I don't know what happened or why, but I honestly can't look Matthew in the eyes and say these ideas were addressed.

IMO, php-fig is very important to the PHP industry. It should be treated that way. For me, what happened here today fell short.

Contributor

philsturgeon commented Mar 2, 2013

I'm getting way too many emails about all this.

Sent from my iPhone

On Mar 1, 2013, at 8:29 PM, AmyStephen notifications@github.com wrote:

@bobthecow @Seldaek - I appreciate your comments. It means a lot that you bothered to even say anything. I am not a member and I have no rights to decide how things are done. I've been thru a situation where the process integrity was not ensured and it was not fun.

Just to set the record straight on a few points, for my own peace of mind:

I was in this thread on a member's recommendation that we try to see if a little more structure might address Ralph's concerns - I was hoping to help set things up better so that the things that happened next week wouldn't be possible.

It is important to understand @ralphschindler did not start this thread up again, there was a little conflict which turned out to be a misunderstand and language issue which started to dawn on me when I was researching the concern, came across blog posts, started reading the comments, understanding the point. That's when I posted in to explain what I was asked to do, where people should go to post, and why what was thought to be trolling wasn't.

@padraic - There is nothing in the bi-laws or rules or FAQ items that spell out how a PR is closed. From practice, they are closed when a member feels it should be. There was no rule broken. In terms of standard practice, had it been closed yesterday, when it had sat idle for a couple of months, I would have thought nothing of it.

As you can see, in response to me Ralph indicated he was content to work in the forums, He was not discussing in here.

The discussion which should take place in the mailing list as @padraic correctly points out - was initiated and driven by @philsturgeon until I finally stepped aside and shortly thereafter an FAQ PR was accepted, and this issue was closed.

To tie it together: Phil's forum post from a couple of hours ago](https://groups.google.com/d/msg/php-fig/M3aQOTdCoy0/IZhSP888EwUJ) as to reasons it was closed.

What was learned

Define the process for how issues are rejected or accepted.
Define processes for your FAQ changes, too. The FAQs ends up being like "law" so get oversight there too.
What's a little mind blowing is Matthew's comment"Address the ideas, not the messengers." I don't know what happened or why, but I honestly can't honestly look Matthew in the eyes and say these ideas were addressed.

IMO, php-fig is very important to the PHP industry. It should be treated that way. What happened here today fell short.


Reply to this email directly or view it on GitHub.

Contributor

AmyStephen commented Mar 2, 2013

Yea, I know. Tried to get the links right. Apologize to have spammed your email.

dg pushed a commit to php-guidelines/php-guidelines.github.io that referenced this pull request Sep 4, 2014

Added two questions to the FAQ
These questions were asked in php-fig/fig-standards#76 and as any decent programmer knows - any answer asked means the documentation isn't good enough.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment