Hi!
> Here is a scenario that I think is quite likely to occur in FIG 3.0. > Assuming Editor A and Sponsor B dislike working with interop group member > C... It would then be possible to eliminate C from the working group as A + > B could block the entry [given the current version of the rules which I > mentioned above as being a "political wall"], even if C has a very vested > interest in the PSR and could conceivably be a very import member of it. > > First of all, I would argue that this is not the case in FIG 3.0. Under that proposal, the core committee should be stepping in at the acceptance vote (if not sooner) and send the proposal back as it hasn't considered all the stakeholders. Secondly, how would this be prevented in an interop group? Seeing as an interop group doesn't actually have any oversight, refusing to cooperate with someone could just as easily (I'd argue even more easily) happen there? > > [Context psr-15] Regardless of which of the many approaches should be >> standardized, many of the most popular implementations were using >> approaches that were full of holes. >> > > I would recommend that you accept it, and guide the community to making > another PSR that betters the current one.... IE PSR-X that extends PSR-7. > > Please understand that when the community has an existing implementation, > changing that implementation has significant cost. > > 1) Businesses use our software > 2) If the implementations change then we must fix them and issue new > versions [usually major new versions] > 3) The cost is real of changing these things... It can be measured in > dollars. > > Without keeping these things in mind, you are just simply going to lose > developers that follow these standards.... > So, instead of creating a new standard, let's call it PSR-N, you suggest first creating a PSR-N-prime, which basically is just the FIG rubber stamp on one of the existing, problematic implementations, and then create PSR-N as an extension (or perhaps a successor) of PSR-N-prime? (Please do correct me if I have misunderstood you) While that makes it easy for one of the implementations to implement PSR-N-prime, how would it make it easier on anyone implementing PSR-N? Also, if PSR-N-prime is created with known problems, and people know that there is an upcoming PSR-N fixing these problems, why would anyone implement PSR-N-prime? Even if there isn't an upcoming PSR-N, any standard with known problems is going to face difficulty getting adopted, because other implementations won't want to introduce problems they haven't had before. Best regards, Magnus Nordlander -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAE1QaySkGJJ5%2BcDLkQPRN-nPtMRT96S796DFeQXcxp6ExOHW1Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
