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 <la...@garfieldtech.com> 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 php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. 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.
