FIG 3.0 is a huge rewrite of the bylaws, structure and process of the FIG and you can read the full draft here. In the meantime, here is an attempt to explain it in a less than 3 minute read with three diagrams.

The current structure of the FIG; The PSR Core Team being the formally defined people involved in a spec.

Current problems

Everyone has equal say on FIG PSRs, no matter their expertise or their project’s relevance in the PSR’s problem space There are lots of clever awesome people involved in the FIG who are not project representatives Member projects find it difficult to engage in everything going on in the FIG There is an ongoing question if the FIG produces PSRs for member projects or for the wider community; especially when the wider community pays it so much attention due to its de-facto status as ‘the php standards body’.

Splitting up of responsibilities; old to new structure

What’s changing: Structure

The structure of the FIG is changing and will be comprised of these four elements:

PSR Working Groups

Doing what: Actually working on the spec. They also have the main vote on if the spec is ready for approval, essentially the technical sign-off part of the current acceptance vote.

Who: Consists of the Editor (Can be anyone just as per the status quo), core committee representative (sponsor) representatives from member projects with relevance and problem space experts

Doing what: Actually working on the spec. They also have the main vote on if the spec is ready for approval, essentially the technical sign-off part of the current acceptance vote. Who: Consists of the Editor (Can be anyone just as per the status quo), core committee representative (sponsor) representatives from member projects with relevance and problem space experts Core Committee

Doing what: They hold the entrance votes and final acceptance vote. These votes are to see if the FIG wants to consider this problem for a PSR, and to have oversight of Working Groups and make sure working groups have all relevant stakeholders have their interests represented within them. Their final acceptance vote is on the quality of the spec, ensuring consistency throughout the FIG, ensuring it meets the FIG’s overall direction and aims, making sure stakeholders interests were represented, and the competence of the working group.

Who: 12 people who are elected by the member projects and active PHP FIG contributors

Doing what: They hold the entrance votes and final acceptance vote. These votes are to see if the FIG wants to consider this problem for a PSR, and to have oversight of Working Groups and make sure working groups have all relevant stakeholders have their interests represented within them. Their final acceptance vote is on the quality of the spec, ensuring consistency throughout the FIG, ensuring it meets the FIG’s overall direction and aims, making sure stakeholders interests were represented, and the competence of the working group. Who: 12 people who are elected by the member projects and active PHP FIG contributors Member Projects

Doing what: Continuing to act as a base for the FIG’s relevance in the PHP ecosystem, promoting activities of the FIG, having a vote in Secretary/CC elections and the way the FIG is run, having a guaranteed place on any Working Groups relevant to their project.

Who: Current member projects and new member projects, which can be any project with a significant stake in the FIG’s activities, but not necessarily a PHP library.

Doing what: Continuing to act as a base for the FIG’s relevance in the PHP ecosystem, promoting activities of the FIG, having a vote in Secretary/CC elections and the way the FIG is run, having a guaranteed place on any Working Groups relevant to their project. Who: Current member projects and new member projects, which can be any project with a significant stake in the FIG’s activities, but not necessarily a PHP library. Secretaries

Doing what: Exactly the same as present

Who: Same as present, Core Committee Members, Project Representatives and PSR Editors hold votes.

What’s changing: Workflow

As a result of these changes to the structure, the workflow changes a bit to ensure the working group, those with relevance to the spec, vote on the technical details of the spec, instead of the whole FIG.

Old and new FIG workflow

Mission Statement

We’ve also developed a mission statement, which is important, so I’ll put it here without comment:

The PHP Framework Interoperability Group (PHP-FIG) aims to advance the PHP ecosystem and promote good standards by bringing together projects and people to collaborate. It develops and publicises standards, informed by real-world experience as well as research and experimentation by itself and others, to form PHP Standard Recommendations (PSRs).

Other things have changed too e.g. votes have change a bit too (for a CC vote to pass votes they require a 2/3 majority and quorums for member project votes have been removed) but you’ll have to read the full bylaw changes for all the details.

Feedback and comments are most welcome on our mailing list topic here.

If you have any questions, please direct them to the mailing list here or have a chat with myself (MichaelC) or Larry (Crell) in #phpfig on irc.freenode.net.