Re: [PRE-VOTE DISCUSSION] Withdraw PSR-8

[Lukas Smith]

> On 10 Sep 2016, at 12:47, Michiel Rook  wrote:
> 
> I'm a bit ambivalent about PSR-8. I voted against it, but I don't think 
> withdrawing it is worth the effort.

same here 

regards,
Lukas

-- 
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/2ACED236-A2DB-43D0-8412-D807AC92F30C%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-13: Link definition interfaces

[Lukas Smith]

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  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  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.

-- 
You received 

Re: Secretary conflict of interest

[Lukas Smith]

> On 12 Aug 2016, at 12:09, Marc Alexander  wrote:
> 
> Just to clarify (also possibly for others), you're proposing to add these two 
> points to the eligibility criteria:
> Contributor to any by-law creation/addition at any phase
> A current contributor to activities influencing the authority of the 
> Secretary role
> The first point is rather clear though it might be helpful to also state that 
> this does not affect the clarification of the interpretation of bylaws as 
> part of the secretaries functions ("Clarifying any interpretation of bylaw 
> text").
> I do however think that the second point is too vague. What are activities 
> influencing the authority of the Secretary role?

I am also not sure if the 2nd point makes sense. In general the acting 
secretaries would have the best understanding of what might need to change and 
what might not work. So not letting then be involved does not make sense. 

I think Adam your concerns relate more to the fact that you didnt like how one 
secretary interpreted the by laws. Rather than your proposed changes 
(especially #2) I think you should just state your case and ensure other people 
are voted in next time. 

regards,
Lukas

-- 
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/5F60CAA5-74F2-4515-B71B-7F33A16A0D95%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.