Adam, I know I don't chime in much here on the message boards, but I wanted to drop in and say hello, not necessarily in an official capacity but just as a developer in the community who's been a long-time follower of the FIG and the PSR standards.
I very much understand the feeling of being up against a monolithic entity where it seems hard to get a word in edgewise or get your foot in the door. A lot of us feel this way when contributing to projects larger than our own, and for me personally, the fear of getting a negative response is what has kept me from submitting many contributions upstream to the projects my own software depends on. That feeling is real and valid, and it's imperative for the larger institutions to do what they can to remain approachable despite their size and momentum. In that context, there's nothing at all wrong with submitting ideas to the group here. Your ideas aren't without precedent, either, since I've seen numerous implementers of the PSR standards lump them together into singular libraries that cover multiple standards at once or extend the standards to be easier to use in their own context. By all accounts, even if your repositories didn't wind up as FIG standards themselves, they could continue to exist as standalone code and would likely be useful to a number of people looking to implement the combined standards in a friendly way. I also agree with Michelle in that it is unfortunate you were met with a response that you felt patronized your contributions. It's important that any interactions with participants in the FIG process be respectful and professional. By that same token, however, I'm not sure that messages like: > Larry, if two others here would second and third your opinion, I will explain why you are wrong. ...convey that level of respectfulness or professionalism either. I think the friction you're feeling with the FIG group doesn't stem from the content of your suggestions themselves, but rather the manner in which you presented them, which was in the form of a GitHub organization named "PHP-SG" with standards that presented as numbered "PSR"s. What does "PHP-SG" stand for? Absent any clarifying information on my side, and given the organization's only contents are these new "PSR" standards, I'd have to assume it stands for something like "PHP Standards Group". So, you've submitted your ideas here through an organization that may or may not imply its own status as a standards group, using the same terminology the FIG uses for its own recommendations, which have been refined and polished through group collaboration into their final forms. Surely you see the reason for any pushback you're feeling here. I know your response thus far has been that the phrase "PSR" is a generic one and that your own "PSRs" aren't popular enough from an SEO perspective to compete with the official ones. To the second point, I think most of the folks here would argue that it isn't your project's relative popularity that is the problem, but rather the precedent that is set when anyone who proposes an idea to the PHP-FIG spins up their own organization, creates repositories and assigns their own FIG numbers to their own code. This would be an immensely confusing mess in very short order, and would leave a hundred repositories scattered across GitHub at varying stages of completion or stability that are all named "PSR-something". Even if developers weren't likely to find those repositories first, the idea that they would find them at all, and then associate them with the same process that the existing PSRs they're familiar with have gone through, is cause for concern. To your point that the phrase "PSR" is generic, I would be inclined to agree if there was any prior art whatsoever that suggested that was the case. If you ask people from all around the PHP community what a PSR is, I would wager that *all* of the ones who know the term would direct you to one of the PHP-FIG standards. The PHP core team uses a different name for their own proposals, and none of the popular frameworks out there (even the ones who don't necessarily adhere to the PSR standards) have made their own standards and called them "PSRs". This is basically a first, so that's why you're seeing such a strong pushback on the concept, because nobody involved wants to set the precedent that you can make your own PSRs when submitting ideas to the FIG, or in general. So, really the long and short of it here is it's all in the naming. If you can understand where the FIG is coming from in that regard, then we may be able to move forward in a productive way. - Buster Neece On Saturday, July 10, 2021 at 3:07:58 PM UTC-5 cap...@gmail.com wrote: > Will anyone else second Larry? > > Hi Michelle, > > Because this is a first, I will address your points. > >> >> I have read through some of this long discussion, and in essence, I >> agree with Larry thay using “PSR” in the PHP community for a standard that >> is not a FIG standard is harmful to the community and devalues the work of >> FIG. >> >> My PSRs literally rely on FIG PSRs and refer to them in the > documentation. How are my prototypes going to hurt the community when > almost none of the PHP community knows about them? When they are designed > not to conflict? How do my PSRs, that pay reverence to the existing PSRs > by extending them, devalue FIG PSRs? > > >> We have been around for a long time; when PHP developers see “PSR” they >> will look it up at FIG, not find it; and get confused. Let’s not confuse >> our wonderful community. >> > > The idea that google will choose to show my PSRs over FIG's PSRs is kind > of absurd. And, the case you present is also kind of absurd since I refer > directly to the FIG PSRs in the documentation, and anyone arriving at my > PSRs would be directed to FIG PSRs if that is what they were looking for. > And like I already said, I'm perfectly willing to add a header "Not a FIG > PSR" if desired. > > >> I’m sorry Adam that you felt that the communication was patronizing. That >> is perhaps something that we can look into. >> > > Don't worry about it - it is truly something you can not fix. > > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/b0ecc8b4-d24c-4c38-a3ce-480435c78874n%40googlegroups.com.