Top posting because I will not touch on every point but do want to make the context available if desired.
I found Paul's statement about doing it as an interop project valid, though instead of "should" I would have used "could" or "might benefit". At the end of the day we indeed can do whatever we wish in terms of how to mature our proposals and I also find it entirely legitimate to propose approaches For example for the security PSR I decided to create a new mailinglist. Overall this discussion seems more like a power struggle over FIGs direction than a productive way to move PSR-13 forward. But not my call to make :) regards, Lukas > On 05 Sep 2016, at 17:35, Paul Jones <[email protected]> wrote: > > Hi Larry, > > This is a *fascinating* response. Since you saw fit to bring up these other > topics in this thread, I feel it's reasonable responding to them inline here, > even though they may not all fit the nominal thread topic. > > >> On Sep 1, 2016, at 14:14, Larry Garfield <[email protected]> wrote: >> >> On 09/01/2016 01:50 PM, Paul Jones wrote: >>> All, >>> >>> On consideration, this strikes me as a perfect example of something that >>> should be created as a *-interop project prior to being accepted. That will >>> help "shake out" any problems revealed by real-world use, especially use by >>> people not participating in the creation of the PSR. >> >> On consideration, forcing it to be an "outside group" from FIG first would >> add absolutely no value whatsoever to the process or the spec. > > I disagree. It adds a great deal of value to the process *and* to the spec. > It helps make sure the spec has some real-world use before it is finalized. > It provides a "shake-out" period during which people not involved in the > building of the spec can test the spec and find previously unexpected > weaknesses. I opine, in hindsight, that PSR-6 and PSR-7 would have benefitted > from such a trial. > > >> It being under the FIG name in no way prevents or discourages anyone from >> "trying it out" if they wish, and the Review period (current status) is >> exactly for further "try it out". FIG 3's Review period includes an >> explicit requirement for it. > > The neat thing is that you can do it *right now* without waiting for FIG 3 > (which may or may not pass). If it's valuable enough to do it in FIG 3, > perhaps it's valuable enough to try it as a *-interop group. If it's not > valuable enough to do it as a *-interop group, perhaps it does not fit in FIG > 3. > > >> Paul, given your clear and stated desire to keep FIG limited to its 2009 >> definition > > And you and Michael (and perhaps others) have a clear and stated desire to > depart from its founding vision. (/me shrugs) > > Anyway, "limited" is a funny word here. By way of analogy, one could say > that "2+2" is "limited" to its original definition as "4". > > No, instead of keeping the FIG "limited to" its founding vision, I would say > keeping the FIG "loyal to" its founding vision (or perhaps "constant to"). > Any changes to the FIG should be incremental perfections of that founding > vision, not substantial departures as you wish to effect. > > > >> (despite your own work on innovative specs) > > I am flattered that you think (I presume) PSR-1, 2, and 4 are "innovative." 1 > and 2 were essentially the results of research and collation across all the > member projects, and 4 was more a refinement on 0 than an innovation. > > This proposal, though, appears to have no pre-existing basis across a wide > range of member projects, and would definitely benefit from seeing some real > use before being categorized as a "standards recommendation." > > >> I really do not know how to interpret your desire to "split the baby" by >> disbanding FIG in practice if not in name. > > I'm not sure what you find hard to interpret. You want to depart from the > original mission to follow one of your own making; I, on the other hand, > think perhaps that means the FIG's time is done. If it is *not* done, it > should continue on its existing mission, rather be co-opted for other > purposes. > > >> "You must work elsewhere first" (aka, independent interop groups) as a >> policy is effectively the same thing as just disbanding FIG outright. > > That's an interesting insight; I wonder if it's true. > > > -- > > Paul M. Jones > http://paul-m-jones.com > > > > -- > 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/28D3F822-47D5-4CAE-BA4B-2965041414EB%40gmail.com. > For more options, visit https://groups.google.com/d/optout. -- 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/52CB7E05-D574-45B2-841F-6D1A77409A4E%40pooteeweet.org. For more options, visit https://groups.google.com/d/optout.
