On 9 Aug 2016 17:54, "Larry Garfield" <la...@garfieldtech.com> wrote:
>
> Given that there's ~9 specs being worked on currently in various stages, the idea that FIG's work is "done" seems completely unsupportable.
>
> FIG is already the de facto PHP Standards Body. That much is very clear; some here don't want to admit that, but that's very clear from the Reddit thread on the subject, talks at conferences, impacts on projects and tooling (PSR-2 preset in PHPStorm?) and general zeitgeist.
>
> As Michael noted previously, if a "new" body were to form one of two things would happen:
>
> 1) FIG would continue, there'd be 2 competing standards bodies, and thus no actual standards. This is the worst possible outcome for interoperability and collaboration.
>
> 2) FIG would die off, either quickly or slowly, and the new group would try to fill its ecological niche. That would be a very messy and complicated process with an ugly, confusing transition period, which benefits no one. The only way to minimize that would be for FIG to actively shut itself down completely as soon as the new group is setup, and publicly say "they're replacing us, kthxbye". Which... would have the same net effect as FIG just evolving, but would be more logistically complicated and confuse a bunch of people needlessly.
>
> FIG isn't "done". It's not "dead." It's just evolving. That's OK. Really! We should be accustomed to this by now. PHP as a language and community is one of the fastest evolving around. PHP has reinvented itself in the last 6-7 years, and FIG has been a part of that. That's something we should be proud of.
>
> But FIG can and should evolve along with PHP. We've done it before. The FIG of 2009 is not at all what we are today. When the entirely cowboy-free-for-all way of working on specs broke down, we changed the process and added more formality. (FIG 2.0, which added the formal Editor, Sponsor, and Coordinator.) It was an improvement. Now, we're still growing and see a need to evolve our structure further. That doesn't mean FIG is "done", just that we're evolving to improve ourselves. In a few years, might the situation have changed further and we need to tack again, with a FIG 4? Quite possibly! And when that time comes we should be prepared to evolve with it.
>
> We, as a community and as FIG, should be looking forwards, how we can continue to help PHP into the future. Not closing up shop because "whelp, autoloading and coding standards are done, peace out."
>
> Closing up shop or turning into just a passive rubber-stamp for people we refuse to let collaborate in our space is short-sighted and ultimately self-defeating.
>
> The fact that there are 9 groups trying to build additional collaborative standards within FIG should be a sign that people do see value in FIG, and we're nowhere close to "done". If anything, it's a sign of a potentially bright future for FIG and PHP, if we approach it properly.
>
> --Larry Garfield
Well said Larry.
Seriously Joe ?
I've been contributing to all iterations of FIG for years now, and I'm not impressed by people wanting to shut it down. Not one bit.
Seriously folks, can we stop feeding the dragon and instead focus on the task at hand ?
Thanks.
>
>
> On 08/09/2016 11:17 AM, Joe Ferguson wrote:
>>
>> By “standards for the language” I mean an official (or as close to official as it can get) Standards for the PHP language. PHP has never (as far as I’m aware) had a Standards Body. FIG is as close as we’ve come. My observation is that FIG 3.0 should skip FIG and become that standards body.
>>
>>> On Aug 9, 2016, at 11:10, Alessandro Pellizzari <al...@amiran.it> wrote:
>>>
>>> On 09/08/2016 16:37, Joe Ferguson wrote:
>>>
>>>> I would rather see FIG marked complete, and those leaders interested in
>>>> moving forward start a new PHP Standards Body that would adopt (not
>>>> claim) the previous PSRs from FIG and begin work on more standards for
>>>> the language, not frameworks or packages.
>>>
>>> I partly agree with what you say, but what do you mean by "standards for the language"? Could you give some examples?
>>>
>>> Bye.
>
>
> --
> 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+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/779690d4-8d55-90d3-2849-013f16947732%40garfieldtech.com.
G
On 9 Aug 2016 9:22 p.m., "Samantha Quiñones" <ieatkil...@gmail.com> wrote:
>
> As Gary said, please let's keep this on-topic and not personal. I advise you to please assume that others are contributing constructively unless it's been shown otherwise.
I want to aplogise for the personal nature of my reply, i didn't mean it like that. I mean nothing personal and was opposing the general idea proposed
>
> --S
>
> --
> 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+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/c91cead9-a79a-419c-a662-de5271fc5d7b%40googlegroups.com.
If FIG is the standards body why has the FIG not formally changed it's name?
I think PHP-FIG is a very well recognized name. If anything like this were to be done it'd be best to just swap from Framework Interoperability Group to "fig".
Very good idea in principal, but at the end of the day it's just bikeshedding that would result in a lot of effort for little to no gain.
On 09/08/2016 17:17, Joe Ferguson wrote:
By “standards for the language” I mean an official (or as close to official as it can get) Standards for the PHP language. PHP has never (as far as I’m aware) had a Standards Body. FIG is as close as we’ve come. My observation is that FIG 3.0 should skip FIG and become that standards body.
If, by this, you mean FIG (or the new standards group) should become an alternative to php-internal (to discuss the future of the language), I disagree. That kind of group should come from php-internal itself.
I think FIG should just broaden its horizon and not think of just frameworks anymore, but I also think it's the way it is already going. We just need to find the correct formula.
Changing the meaning of the acronym would be easier than changing the whole system around it. Just make it recursive: FIG = FIG Interoperability Group and call it done.
I think Paul's idea is not bad, and it's probably very similar to FIG 3.0.
I recall that Phil Sturgeon's impatience got the better of him during the discussions over my work on what would become known as PSR-4, which drove the building of the workflow bylaw.
(I find that somewhat amusing, since Phil was caused the first cancelled vote on that PSR by editing the text under vote, and he himself pulled the vote again a second time later after the workflow bylaw was in place.) So the only thing that "broke down" were some of the participants, not the process.
Let there be a new body created, separated from the FIG, and let them do as they wish. If they adopt PSRs created by the FIG, so be it. If the FIG finds some things in this new org that meet with their mission, so be it.However, and this is important, this new body should work WITH the FIG. Not above it and not as a subordinate. But hand-in-hand to create standards that work both for the projects AND for the community.
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/627B6598-02C1-42EB-B392-024EE90E0B51%40gmail.com.
FIG has served its purpose and should be archived.
For another group to be successful I believe FIG would have to close up shop. Disband sounds like the wrong word to me. I do like "Archive" that Woody mentioned previously.A potential new organization road map for what FIG may need to do & what a new organization would need to do:FIG's agenda:* Formal 2 week discussion to discuss the following points:* Do voting reps want to close up / disband / archive FIG? - If Yes, continue* Allow transfer of all in progress work to any new organization that is willing to pick it up* Set end date for FIG (~4-6 weeks after passing vote closes)* End date allows time for any formal last minute business & lead time for new organization.* Stop opening votes for FIG members to vote on (So that this vote is the last closed vote)* Open 2 week voting periodNew Org Agenda:* Get your ducks in a row asap* Write your bylaws / Figure out who and how your membership works* Formally declare your intentions to FIG voting members* Start talking to everyone currently working on in progress work and inform them of your intentions
IMHO a competing organization to FIG would struggle. I feel like the best path forward in this scenario *requires* FIG to no longer be active.
--
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+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/d0b62cfa-ceda-44bf-8da3-a1c30794ee6a%40googlegroups.com.
On Mon, Aug 29, 2016 at 8:06 AM Joe Ferguson <j...@joeferguson.me> wrote:For another group to be successful I believe FIG would have to close up shop. Disband sounds like the wrong word to me. I do like "Archive" that Woody mentioned previously.A potential new organization road map for what FIG may need to do & what a new organization would need to do:FIG's agenda:* Formal 2 week discussion to discuss the following points:* Do voting reps want to close up / disband / archive FIG? - If Yes, continue* Allow transfer of all in progress work to any new organization that is willing to pick it up* Set end date for FIG (~4-6 weeks after passing vote closes)* End date allows time for any formal last minute business & lead time for new organization.* Stop opening votes for FIG members to vote on (So that this vote is the last closed vote)* Open 2 week voting periodNew Org Agenda:* Get your ducks in a row asap* Write your bylaws / Figure out who and how your membership works* Formally declare your intentions to FIG voting members* Start talking to everyone currently working on in progress work and inform them of your intentionsI just don't see why this is at all necessary, what does this get us other than a new name? To me it seems like this is just a semantic runaround for what old fig will be once fig 3.0 passes. IMO once FIG 3.0 is around for a little bit of time, FIG 2.0 will become just a slide on someones presentation and that's all. What does it matter if that slide says "Gone: Disbanded then remade into FIG 3.0" vs "Gone: Reformed as FIG 3.0"?
- The following started as PSR drafts, and have since also become *-interop projects.
- 15 HTTP Middlewares
- 17 HTTP Factories
I don't see an "async" PSR listed (unless you mean the Event Manager PSR, in which case it was indeed included my original list).
Hi all,
Multiple responses inline.
* * *
> On Aug 29, 2016, at 10:20, Korvin Szanto <korvin...@gmail.com> wrote:
>
> I just don't see why this is at all necessary, what does this get us other than a new name? To me it seems like this is just a semantic runaround for what old fig will be once fig 3.0 passes.
From my original blog post, the benefits (among others) are these:
- As a brand-new organization, it can define its vision and mission without in-group rivalry.
- It can curate its membership, bringing in only the people and projects that adhere to its vision (and keeping out those who do not)
- It can establish any organizational structure (hierarchical or otherwise) from the outset, without having to worry about precedent or prior expectations
- It can have any code of conduct it wants as part of its foundational structure.
- Whatever negative baggage is perceived as being part of the FIG is dropped.
Joe Ferguson paraphrased this as "green fields." (If nothing else, think of the biggest benefit as the ability to exclude that pesky, pernicious, Paul M. Jones without needing a vote to do it.)
> IMO once FIG 3.0 is around for a little bit of time, FIG 2.0 will become just a slide on someones presentation and that's all. What does it matter if that slide says "Gone: Disbanded then remade into FIG 3.0" vs "Gone: Reformed as FIG 3.0"?
The new group (if any arises) will be a new and different creation, with a new and different name. It may resemble the FIG in some ways, but it most definitely will *not* be the same. It will be a break from, not a continuation of, the FIG. As such I don't see why anybody would confuse it with FIG, especially if the new group behaves properly and actively distances itself from FIG and the FIG's PSRs, as it should.