Alternative to FIG 3.0 - Is it time to call FIG complete?

[Joe Ferguson]

Is it time to call FIG complete?

As someone who feels like FIG 3.0 is a step in the right direction, and can empathize with those against it, I'd like to offer an observation:

Maybe it's time to call FIG complete. FIG accomplished it's primary goals (Bringing frameworks together to build interoperable packages / standards).

Now FIG is digging into areas that don't fit frameworks and is struggling to find it's identity - as if it's lost. I don't think FIG is lost, I think FIG is fighting to stay relevant when the mission has been accomplished.

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.

--

- Joe Ferguson
JoeFerguson.me
MemphisPHP.org

[Alessandro Pellizzari]

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.

[Joe Ferguson]

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.

> --
> 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/ea9ae2fc-ccad-6326-8c27-a4c9fde77cc2%40amiran.it.
> For more options, visit https://groups.google.com/d/optout.

[Phil Sturgeon]

I could certainly see this working out. 

The FIG 3.0 is a big set of changes, aiming to make this group into a formal standards body for the entire PHP community, which is a fundamental shift from what it has been in the past.

Seeing as FIG 3.0 has a new mission statement, a new concept of Working Groups, and sets itself up to not repeat many of the same mistakes as it has with things in the past (sup Cache!) I think making a brand new organization to transition into for FIG 3.0 would be a solid way to reflect that. 

FIG 2.0 was just a "lets make a couple of bylaws for how we do stuff so we're not just totally pulling this out of our backside", and it was a big step forward, but essentially the same thing. FIG 3.0 is quite a bit different, and a new name would reflect that intentional difference. 

A fresh new start. New ideas, new people, new structure, new goals, same standards with great new stuff to come. :D

I'd definitely not want to see the FIG and this new group running along at the same time. Lots of people tried to make their own little group and they fizzled out in minutes. This would probably need a 2/3rd majority, but either way it would become the new group and people would need to get on board.

[Larry Garfield]

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

[Paul Dragoonis]

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.

[GeeH]

I don't feel that questioning the person who opened the topic is conducive to a topic that deserves discussion. Please keep comments on topic and not personal.

G

[Glenn Eggleton]

If FIG is the standards body why has the FIG not formally changed it's name?

[Samantha Quiñones]

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. 

--S

[Paul Dragoonis]

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.

[Phil Sturgeon]

On Tuesday, August 9, 2016 at 4:17:04 PM UTC-4, Glenn Eggleton wrote:

If FIG is the standards body why has the FIG not formally changed it's name?

Sorry for double, but let me take this one!

Glenn: The FIG is not currently a standards body, but the goals of FIG 3.0 is moving to become one. Seeing as it is becoming a new thing, Joe is suggesting a name change to reflect that, along with the structural changes + mission statement changes.

Does that clear it up?

[Paul Jones]

Hi all,

> On Aug 9, 2016, at 11:54, Larry Garfield <la...@garfieldtech.com> wrote:
>
> 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.

To be clear, those changes were not the result of "evolution" in any natural sense. Those changes are the result of "people writing specific rules with specific goals in mind" (i.e., "creationism"). I assert that those creations have not always been for the better.

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

I think "broke down" qualifies as an overstatement.

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.

Larry probably remembers the writing of the bylaw, since he was part of it, as was I. Here's one related link:

https://groups.google.com/forum/#!msg/php-fig/qHOrincccWk/rra3DpRD9f4J

That's not "breaking down" so much as "someone pushing a change." I recall being mostly OK with the state of the PSR process before that, but memories do fade.


--

Paul M. Jones
http://paul-m-jones.com

[Brian Teeman]

Reading this it feels like I am stuck in a time loop

[Navarr Barnier]

I agree on the principal, but disagree on actually moving forward with a new name (and website? And mailing list?).

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.

[Michael Dy]

I agree with the idea proposed. I think that FIG needs to continue in some form, but the path it's currently on isn't going to work. Without going into the politics of the group from an observational perspective, continuing on the current path seems like it'll lead to an implosion.

More than one member organisation has left in the past several months, stating that they've achieved all they feel they can with the group.

Rebirth with a new set of goals (and probably with a baseline for conduct, 3.0 mindset etc.) will be a much better going forward in my opinion.

[Alessandro Pellizzari]

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'd like to see much less burocracy.

I think FIG should become some kind of hub for PSRs, but also that a
-interop group should present itself to FIG in its infancy or before
beginning the works, both to inform FIG it's working on standardising
something and to inform the community at large, if they want to contribute.

And then periodically inform of progress on the standard definition.

What I would NOT like to see is a -interop group working in the dark for
months and then coming here asking for a badge of approval (a PSR
number) on something already decided.

An idea could be to have a thin infrastructure defining:

1- when and how a -interop group should present the project to FIG
2- when and how a -interop group should give updates
3- how and who will vote on the final proposal when -interop asks for it

And a set of guidelines for the -interop group to adopt while discussing
the standard (could be similar to the current guidelines).

Bye.

[Glenn Eggleton]

Hey Phil:

Yep :) That clears it up.

I'm fine with FIG transitioning into a standards body. 

So why don't the members of FIG try and figure out a way to transition it?

I realize FIG 3.0 is a large part of it... but I don't think 3.0 covers enough to be called a "Standards Body".

I guess this would likely be the focus of the new secretaries.

[Joe Ferguson]

Hello all,

I'd like to clarify a few things based on responses and conversations I've had one on one with people outside the mailing list since posting the original message in this thread.

PHP needs a group making decisions on best practices for users. That has been FIG for a long time just because of the nature of PHP not having an official standards body. My comment is that maybe its time PHP get a standards body, led by the people who want to see FIG 3.0 happen. Let your work in FIG stand on it's own. PSRs aren't going anywhere. Start a Standards Body Group that adopts the work you've done here and picks up all the currently in progress PSRs and continues working on them. Close FIG down since it's work as a Framework Interoperability Group has been completed.

This would be a perfect time to start fresh, get your bearings, and sort your stuff out with all the lessons learned from FIG. I would rather see this than people oppose FIG 3.0 and it being shoehorned in.

If you take away absolutely nothing else from my comments: FIG 3.0 is such a shift that it warrants the consideration of a new organization with leadership based on the people doing the work to make things happen in FIG.

Paul D. & Larry:

I was not trying to say that FIG is dying/dead I'm well aware of everything FIG has going on. Probably more aware than a few member project representatives. I was also not trying to discredit any contributions to FIG by anyone, especially you two gentlemen.

On Wed, Aug 10, 2016 at 4:58 AM, Alessandro Pellizzari <al...@amiran.it> wrote:

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 am absolutely *not* saying FIG or *any* Standards Body should replace internals. Internals is it's own demon and I do not wish to disturb that beast in this conversation.

 

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.

What I (and others against FIG 3.0) are commenting is that FIG 3.0 is a big departure and instead of transitioning FIG into a Standards Body, that it should become a new organization and stand on it's own while adopting FIG PSRs (As mentioned in the original post)

 

[Phil Sturgeon]

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.

It had nothing to do with impatience, the bylaws were created for the reasons linked to in the post you kindly linked to. Great reference.

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

 

The first vote was canceled due to a trivial non-impacting code change, which was reverted shortly after. The second was a completely intentional cancellation because the existing PSR-4 document was an awfully overcomplicated mess which nobody was particularly happy with, and multiple members gave it a shaky +1 but said they were not confident in it. It was thereafter replaced by "Beau's PSR-0 + tweaks" alternative PSR-4 document, at the initial suggestion of Anthony, and supported by a large number of the group.

We built the workflow bylaw mid PSR-4 because it was stuck in the mud, arguing about alternative proposals, but once in place the workflow bylaw gave everyone the ability to focus on one implementation at a time. The workflow bylaw gave us more time to review the document, field opinions, explore the potential of alternatives but keep working on one at a time, and was the absolute opposite of impatience on anyones part, especially not mine. Getting the bylaw in took a huge amount of work from Larry and myself, and a few other contributors. Thanks to everyone involved with that.

Lets not pretend that less rules = better. Slapping out half-baked standards because they look ok to the person writing them and a couple of others is not how a standards body is meant to work, and I think everyone knows that.

The only choice is: does the FIG want to become a proper standards body or not. Work that out. :)

[Adam Culp]

Joe,

Thanks for bringing this up in it's own thread, it is needed. I have voiced a similar concern a couple of times but was pretty much overlooked or, similar to what has happened in this thread, discounted by some.

https://groups.google.com/d/msg/php-fig/e9qZue8nZXM/J2biNBc3DgAJ

https://groups.google.com/d/msg/php-fig/h3wrQePdzfc/jkw9LmvDDgAJ

I don't believe the FIG is done, but I do think there needs to be a separate body for some of the things that have little to do with INTEROPERABILITY, which is SUPPOSED to be the goals of this group.

How we do that...I don't know. But I think as I said previously:

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.

Regards,

Adam Culp

IBMiToolkit

On Tuesday, August 9, 2016 at 11:38:23 AM UTC-4, Joe Ferguson wrote:

[Paul Jones]

Dear Voting Members,

I have posted my thoughts on this subject in two parts:

- <http://paul-m-jones.com/archives/6384>
- <http://paul-m-jones.com/archives/6389>

I apologize for the length. If we feel it's appropriate, I can copy them here or into a new thread so they become a formal part of the FIG record.

In short, I feel a motion to disband the FIG is an idea worth pursuing.

[Joshua Drake]

Hello,

A mark of a mature project is incremental improvement. I can certainly empathize with those that are tired of all the "mess" but in the end, it will be a positive thing. Instead of trying to shut things down or start a new project, the members should introduce incremental, positive changes through the voting mechanism. That is how it works folks. We don't take our balls and go home. We objectively assess the rules and change them as the PROJECT and MEMBERS require.

JD

[Alessandro Pellizzari]

On 18/08/2016 16:32, Paul Jones wrote:

> In short, I feel a motion to disband the FIG is an idea worth pursuing.

I disagree.

The best thing to do, IMO, is to call a vote:

Do you want the FIG structure to be changed towards a working-groups
one, with contributions extended to non-members?

(You can formulate it in another way, generic enough to allow a
discussion around the "3.0 form", but with at least a view of the target)

Those who don't agree with the result will be free to leave and create
another group if they wish.

Bye.

[Lukas Kahwe Smith]

> On 18 Aug 2016, at 17:32, Paul Jones <pmjo...@gmail.com> wrote:
>
> Dear Voting Members,
>
> I have posted my thoughts on this subject in two parts:
>
> - <http://paul-m-jones.com/archives/6384>
> - <http://paul-m-jones.com/archives/6389>
>
> I apologize for the length. If we feel it's appropriate, I can copy them here or into a new thread so they become a formal part of the FIG record.
>
> In short, I feel a motion to disband the FIG is an idea worth pursuing.

tl;dr:
Disbanding FIG seems like a scorched earth approach.
ie. if I cannot have what I want, I rather destroy it while I can, so nothing new can evolve out of what exists today.

---

In a previous email you have stated that it would somehow be wrong for FIG to evolve from its original structure as it would give that new structure “illegitimately” gained standing in the community. Yet FIG has already evolved and most projects and organizations evolve. This is quite a normal thing.

Also while there are discussions and different opinions in regards to the direction. It seems that aside from you Paul, most people that suggested doing FIG 3.0 as a separate organization suggested this because they expected severe opposition from people within FIG that want to keep FIG as is. Now if this opposition in the end is just fighting so that a potential FIG 3.0 has to start from scratch then this to me is the definition of scorched earth.

Now of course no decision has been made in regards to adopting FIG 3.0 in its current proposed or changed form. But if you would rather see FIG die, than evolve into FIG 3.0 then I think this is a very sad approach.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org

[Paul Jones]

All,

> On Aug 18, 2016, at 12:39, Alessandro Pellizzari <al...@amiran.it> wrote:
>
> Those who don't agree with the result will be free to leave and create another group if they wish.

Indeed -- the proponents of FIG 3.0 are free to leave *right now* and create another group if they wish. (The "founding" vision has the better case for a prior claim, and thus there is no reasonable way to request its exit.)

On Aug 18, 2016, at 13:57, Lukas Kahwe Smith <sm...@pooteeweet.org> wrote:

> But if you would rather see FIG die, than evolve into FIG 3.0 then I think this is a very sad approach.

Perhaps it is already dead; a zombie, if you will, walking around seeking brains. Joe Ferguson has already presented a similar idea, noting that FIG seems to be casting about for something to do. If that's the case (and I think the case is supportable) then the best thing to do is recognize it, and act on that recognition to disband the group. Let a new group rise in its absence, if one really is needed.

Further, the FIG 3.0 proposal is not an "evolution" in any meaningful sense. It is not a marginal change to make a small adaptation. It is a deliberate "re-creation." And while I think the FIG 3.0 proposal might be fine for a *different* group, it is not fine as an approach for *this* group to follow. If the FIG really is dead, then FIG 3.0 is not a resuscitation, but a possession.

[Woody Gilk]

I think Paul is probably right here, in so far as FIG itself no longer seems to be useful. Though I disagree with Paul's reasoning as to why FIG is in its current state, the end result is the same: FIG has served its purpose and should be archived.

--
Woody Gilk
http://about.me/shadowhand

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

[Christopher Pitt]

FIG has served its purpose and should be archived.

You mean aside from the ongoing PSR work? The 10 or so PSRs, approved by vote, to be worked on? Seems a bit premature to say FIG is purposeless and/or useless...

[Joe Ferguson]

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 period

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

[Korvin Szanto]

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 period

New 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

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

 

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.

Definitely agree here, FIG is not much without the people that make it happen and those people need whatever extra time they have to be devoted to the most current organization instead of being split unnecessarily.

 

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

[Joe Ferguson]

On Monday, August 29, 2016 at 10:20:53 AM UTC-5, Korvin Szanto wrote:

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 period

New 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

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

A clean slate. Green fields. Adopt the the work that FIG has completed and start fresh with fresh and old faces with a new mission statement. FIG 3.0 is a major refactor where the points I've tried to make in this thread are 1: Maybe it's time to call FIG complete and 2: FIG is still active, but the work it's doing doesn't really seem to fit the "Framework" portion of the mission. 3: A new organization solves many problems.

[Lukas Kahwe Smith]

tl;dr

the bulk of the community doesn’t care about our by-laws, they are about PSRs, so to the community “disbanding” FIG will just be confusion about why suddenly PSRs would live on another site/github repo ..

> A clean slate. Green fields. Adopt the the work that FIG has completed and start fresh with fresh and old faces with a new mission statement. FIG 3.0 is a major refactor where the points I've tried to make in this thread are 1: Maybe it's time to call FIG complete and 2: FIG is still active, but the work it's doing doesn't really seem to fit the "Framework" portion of the mission. 3: A new organization solves many problems.


"it's time to call FIG complete"

actually I very much disagree. saying this would imply that there isn’t anything that could sensibly be done based on the old mission statement, let alone any new mission statement.

also from the “community” perspective the difference between FIG 1.0, 2.0 and 3.0 don’t matter much. the evolution away from "just” framework to more was one driven by the community more so than by us I would say. as such arguing that 3.0 is for some reason a too big a change seems entirely arbitrary and will lead to confusion in the community which will affect thousands of developers.

the issues regarding the definition of who we are and how to proceed are, if they are even so fundamental, only on this mailing list and maybe some reddit threads. but the general community isn’t pondering our mission statements, they are looking at the PSRs that come out and not how they were crafted.

[Paul Jones]

> On Aug 28, 2016, at 17:01, Christopher Pitt <cgp...@gmail.com> wrote:
>
>> FIG has served its purpose and should be archived.
>
> You mean aside from the ongoing PSR work? The 10 or so PSRs, approved by vote, to be worked on? Seems a bit premature to say FIG is purposeless and/or useless...

"Ongoing" is true, but fails to capture the entirety of the situation, perhaps misleadingly so. Let's take a look at those 10 or so PSRs, roughly from what I will call "arguably least-active" to "arguably most-active".

- I think we can dispense with "8 Huggable Interface" as "a funny idea at the time" that should probably be withdrawn without vote.

- Regarding the following PSRs, I do not recall much recent activity on this list; perhaps they are being actively discussed elsewhere? Some are new; others are years old.

- 5 PHPDoc Standard
- 9 Security Advisories
- 10 Security Reporting Process
- 14 Event Manager
- 16 Simple Cache

(Incidentally, each of these seems like a very good candidate for a *-interop project.)

- The following started as PSR drafts, and have since also become *-interop projects.

- 15 HTTP Middlewares
- 17 HTTP Factories

- There has been a welcome surge of recent activity on "11 Container Interface". Interestingly enough, it is already a *-interop project.

That leaves "12 Extended Coding Style Guide". In my opinion, that ought to be delayed until there are more in-the-field examples to draw from. (It might or might not make a good *-interop project.) However, there does seem to be regular activity on this list regarding it.

So, to say that there is ongoing work on 10 or so PSRs is true in the sense that there has been activity in the past, and we may expect activity in the future. But it is not true in the sense that there is continuing, recent, and regular (not even monthly!) activity on them all. I think only 11, 15, and 17 (and perhaps 12) meet that criteria; of those four, three are already *-interop projects, and I think would thrive even in the absence of the FIG.

[Larry Garfield]

Is there a reason you excluded PSR-13, which recently entered Review stage?

--Larry Garfield

[Woody Gilk]

On Mon, Aug 29, 2016 at 5:06 PM, Paul Jones <pmjo...@gmail.com> wrote:

- The following started as PSR drafts, and have since also become *-interop projects.

    - 15 HTTP Middlewares
    - 17 HTTP Factories

To be clear, the reason for creating http-interop was to allow experimentation with the draft interfaces to see if they would work in Real World Projects. Depending on how ongoing discussions (FIG-3.0 among them) play out, http-interop would be folded back into FIG later in the process.

[Paul Jones]

> On Aug 29, 2016, at 17:37, Larry Garfield <la...@garfieldtech.com> wrote:
>
> Is there a reason you excluded PSR-13, which recently entered Review stage?

My bad -- I regret the oversight.

To update the PSR listing:

"- PSR-13 has seen continuing, recent, and regular activity. As a side note, this too would be an excellent *-interop project."

And to update the conclusion:

"I think only 11, 13, 15, and 17 (and perhaps 12) meet that criteria; of those five, three are already *-interop projects, and I think would thrive even in the absence of the FIG. PSR-13 might or might not thrive as a *-interop; making it one would be a good test to see how widely it is actually needed."

[Christopher Pitt]

Also skipped the async stuff (event loops and promises), which are also *-interop projects. My point was less about things that are *-interop and more all these things having started as projects under the FIG banner, with their natural conclusion set for the same. 

[Paul Jones]

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.


* * *

> On Aug 29, 2016, at 10:39, Lukas Kahwe Smith <sm...@pooteeweet.org> wrote:
>
> the bulk of the community doesn’t care about our by-laws, they are about PSRs, so to the community “disbanding” FIG will just be confusion about why suddenly PSRs would live on another site/github repo ..

I see no reason why they would live on another site or Github repo. Perhaps I was insufficiently explicit earlier. To be more clear: I would expect the sites and repos to continue to exist where they are now, kept in place without significant or substantial changes, by the archivist(s). Their purpose is to maintain the PSRs as they are, and to keep the FIG- and PSR-related names occupied so they cannot be used by later actors.

I agree about the importance of bylaws vs PSRs: the real value of this organization is expressed in its productive output (PSRs) not in its bylaws (which serve no useful purpose outside the group, and perhaps not that much of a useful purpose inside the group).


* * *

> On Aug 29, 2016, at 17:51, Christopher Pitt <cgp...@gmail.com> wrote:
>
> Also skipped the async stuff (event loops and promises), which are also *-interop projects.

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). If you can link to the one you think I skipped, I'll be happy to remedy.

> My point was less about things that are *-interop and more all these things having started as projects under the FIG banner, with their natural conclusion set for the same.

I think you presume too much. For example, that there is a "natural conclusion" to something being started as a "draft"; there is no guarantee that they will ever finish as "accepted" PSRs, or that they cannot ever be withdrawn, or otherwise disposed of by some means. Some early PSRs (notably 4, but others too) transitioned from one process to another; transitioning to some other as-yet undetermined process would not be out of line.

[Christopher Pitt]

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

You know I don't mean event manager. Though, to be frank, I think it would be better not to bring the final standards and implementations back to FIG.  

[Korvin Szanto]

Hi Paul,

Thanks for the replies to my comments,

On Mon, Sep 5, 2016 at 9:19 AM Paul Jones <pmjo...@gmail.com> wrote:

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.

To me this would mean that an individual or a small group of individuals would dictate vision and mission for the rest of us, why would we want this?

  

- It can curate its membership, bringing in only the people and projects that adhere to its vision (and keeping out those who do not)

This reads to me: "It can exclude more people" which sounds like a negative

  

- It can establish any organizational structure (hierarchical or otherwise) from the outset, without having to worry about precedent or prior expectations

This reads to me: "It can dictate structure instead of voting in structure" which sounds like another negative

  

- It can have any code of conduct it wants as part of its foundational structure.

 

How is this excluded in the FIG 3.0 proposal? We could have a CoC as part of the foundational structure there too if we want.

- Whatever negative baggage is perceived as being part of the FIG is dropped.

I think the PHP community - especially those that pay attention to the FIG - deserve a little more credit. I don't think it matters to those who have disdain for the fig whether it breaks down and reforms or whether it forms into a new group, they will still consider it a continuation of the FIG because it's full of the FIG members.

 

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

Is this something you wanted a serious response for?

 

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

I think this distinction matters to only a few while anyone paying attention will obviously realize that this is a continuation of the FIG regardless of the course of action. Especially considering we're trying to plan it here in the FIG mailing list.

Best wishes,

Korvin