The FIG stands for Framework Interoperability Group. The name until recently was “PHP Standards Group” but this was somewhat inaccurate of the intentions of the group.
The idea behind the group is for project representatives to talk about the commonalities between our projects and find ways we can work together. Our main audience is each other, but we’re very aware that the rest of the PHP community is watching. If other folks want to adopt what we’re doing they are welcome to do so, but that is not the aim. Nobody in the group wants to tell you, as a programmer, how to build your application.
PSR stands for PHP Standard Recommendation.
A full breakdown of PSRs can be found in our Index of PHP Standard Recommendations
The group was bootstrapped by a number of framework developers at php|tek in 2009. Since then various other members have applied and been voted in, increasing the size of the group from the first 5 to over 20.
It may not be an “official” PHP group, but if that was the case who would do the appointing? The FIG represents a cross-section of the community, and over time that cross-section will represent a wider selection of projects.
The full list of voting members can be seen here.
No. Becoming a voting member on the PHP-FIG in no way forces a member or project to implement every - or any - accepted PSRs. Projects have to consider backwards-compatibility issues when upgrading and make the changes at the right time, so it is assumed most projects will eventually adopt, but it is not a requirement.
Absolutely. Anybody who subscribes to the Google Group is part of the PHP-FIG. As soon as you subscribe to the mailing list and/or join the IRC channel you are a PHP-FIG Community Member, who can influence standards, make suggestions, give feedback, etc. Only PHP-FIG Voting Members can start or participate in votes, but the discussion and formation stages involve everyone.
If you think that your project would benefit from implementing PSRs and you want to have a say in the development of future standards then you certainly should get involved.
Multiple members can represent a single project, but that project will only get one vote. A member can represent multiple projects, but that member will still only get one vote.
The rules are all described in the Voting Protocol Bylaws.
Every single vote has a number of reasons for and against voting. No explicit guideline or explicit set of rules has been set out. Some vote for everyone, some vote for their friends, some vote for projects with a certain size or reputation. In reality sizes of all projects have been accepted from the large and extremely well known (Zend Framework 2 & Drupal) to the considerably smaller (PyroCMS). If a project you use is not represented they have either not applied, or were not involved enough in discussion prior to submitting their vote that they have not been voted in. They can try again at a later date, of course.
It was quickly discovered that CMS, applications, package developers, etc. have as much to add as the frameworks themselves. The idea is to get a cross-section of the ecosystem and not JUST one specific group of developers. Having the implementors working alongside the people creating packages and the people developing systems with the frameworks are all of equal importance.
Framework developers have a multitude of factors to consider when planning the roadmap for their products and they need to take their community into account when they do this. Factors like features, functionality, style guide, minimum requirements, etc. are all subject to change in any new version and each project makes their own decisions. How they involve their communities in decision making is entirely up to them, not the FIG.
To quote the abstract from RFC 2119:
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.
By following RFC 2119 we can be both more concise in what we are saying as well as more consistent in how we are saying it. Emphasizing words as recommended by RFC 2119 helps ensure that documentation will be read as the authors intended and leaves less room for ambiguity. This ensures that there is a smaller chance that the same text can be interpreted to mean more than one thing.
We are far from alone in using RFC 2119 in writing standards and specifications. The IETF uses it for its own documentation but there are examples of other projects outside of the IETF using RFC 2119 as well. The Atom Syndication Format is a good example of a project adopting RFC 2119 for its own purposes.