The PHP Framework Interoperability Group (The 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), PHP Evolving Recommendations (PERs), and Auxiliary Resources (ARs).
The PHP FIG member projects are known, publicly available PHP projects or significant PHP stakeholder organizations that have shown an interest in supporting the FIG's mission and work. Member Projects must be released projects with known production deployments, not aspirational projects. Member Projects are not required to implement any particular PSR, although are expected to give relevant PSRs due consideration.
A project that exists solely as an extension or plugin of another project is not eligible. However, projects may leverage code, libraries, or frameworks from other projects without being disqualified. In cases where that distinction is unclear Project Representatives should use their best judgment to implement the spirit of this clause.
An application for membership by a project must include a current Project Representative or Core Committee member as a sponsor, the name of the proposed Project Representative, and a description of the project and its relevance to the FIG. The application once posted must be given a discussion period of at least two weeks. Once that period has passed, the sponsoring Representative may call for a Membership Vote. If it passes, the project is recognized as a Member Project with the stated Project Representative. If it does not, a project may reapply at any time if a sponsor may still be found.
A Member Project may resign from the PHP FIG in writing to an official FIG public channel. Once such a statement is published and the resignation is confirmed by a secretary, a PHP project immediately ceases to be a Member Project.
A former Member Project may reapply for membership at any future date.
The votes of all Member Projects are cast by Project Representatives who have been authorised to do so by the Member Project. Each Project Representative is chosen solely by a Member Project and their selection is not subject to the approval of the PHP FIG. A Project Representative may be replaced by the Member Project which they represent at any time.
A Member Project may not have more than one Project Representative at a time. No individual may represent more than one project at a time.
A Project Representative may temporarily confer their voting rights or Working Group eligibility onto another individual who is authorised by the Member Project which they represent. This conferral must be notified to the PHP FIG by the current Project Representative, and must state the name of the temporary Project Representative and the period of time for which their temporary voting rights or eligibility will remain valid. All voting rights will automatically return to the original Project Representative at the end of the period of time stated.
If, in the judgement of the PHP FIG, a Project Representative is acting inappropriately and to the detriment of the PHP FIG's ability to meet its objectives, any member of the Core Committee may call an Expulsion Vote to request a replacement Project Representative or to expel the Member Project where replacing a Project Representative is not possible. In these instances the Member Project/Project Representative concerned may not vote. If a member project is expelled it may reapply for membership after a minimum of one year. If a project representative is voted to be replaced, they may not return to represent the project they represented at the time of the vote, or any other project, indefinitely.
A Project Representative may also simultaneously serve as a Core Committee member, PSR Editor or Working Group member but not as a Secretary.
The Core Committee is a twelve (12) member board of individuals recognized for their technical skill and expertise. The Core Committee is responsible for final decisions regarding what specifications FIG will consider and those that are approved. The Core Committee is responsible for ensuring a high level of quality and consistency amongst all published specifications, and that all relevant perspectives and use cases are given due consideration.
Core Committee members are not permitted to also be a Secretary. A Project Representative is permitted but not required to also serve as a member of the Core Committee, however, Core Committee members are expected to consider the impact of their actions on the PHP ecosystem as a whole when acting in their capacity as a Core Committee member
Core Committee members are expected to take an active interest in all topics brought before FIG.
The primary responsibility of a FIG Secretary is to serve as an impartial administrator of the FIG. They serve at the member projects and core committee's pleasure but act as independent and impartial adjudicators. FIG Secretaries also represent the FIG as a whole to the general community and public on matters relating to the FIG's activities.
Whilst there are a number of defined functions below but they should also perform other duties as required. As the role has continuity (in that there will always be a post holder) and redundancy (There are a number of post holders in case of the absence of one) it can be ensured that responsibilities assigned to the secretary will always be completed and therefore administrative responsibilities such as vote management should always be assigned to the FIG Secretary.
All FIG Secretaries are expected to remain impartial and professional when acting in an official capacity as Secretary and should also remain aware that even when not acting in an official capacity, their actions reflect back on the PHP FIG and the FIG must not be brought into disrepute.
In order to ensure impartiality, Secretaries may not concurrently serve as a Project Representative, Core Committee Member, or Editor of a PSR. They may, however, be a member of a Working Group. Secretaries must also publicly declare all conflicts of interest for example if they are participating in a working group or are a core team member of a Member Project.
There are a number of defined functions that the FIG Secretaries are expected to complete but they may also, within their remit defined in the above overarching role, perform other duties as necessary.
** Should any bylaw clarification by challenged or objected to by three or more project representatives or core committee members it must go to a vote. If between Secretaries consensus cannot be found on a clarification, it must go to a full vote.
FIG Secretaries will be given access to the GitHub organisation as "Owners" and full (admin) access to anything relating to official website, marketing and communication mediums including but not limited to the domain, Twitter, IRC channel, packagist.org packages and mailing list in order to allow them to complete their duties and ensure that FIG mediums are managed by representatives elected by the PHP FIG.
Also, whilst not full members themselves, they have the ability to start any vote, but not cast any votes. However it should be noted that any vote started by one FIG Secretary must be managed and tallied by a different secretary to ensure impartiality.
The majority of the PHP FIG's work is carried out by Working Groups, under the guidance and support of the Core Committee. Members of a Working Group are expected to be actively engaged in the Working Group's efforts.
Every Working Group has a single Editor, who is responsible for the smooth operation of the Working Group's mission and has final authority on the group's output. Editors are appointed by the Core Committee. Editors are responsible for managing the development of the Working Group's efforts; for representing the Working Group in discussions with the rest of the PHP FIG; for coordinating other contributors; and for working with other members of the Working Group and Core Committee as appropriate to see an effort through the appropriate process. Any individual may be an Editor, provided they are not also a Secretary. If the Editor of a proposal is missing for more than 45 days without notice then the Core Committee may agree upon a new Editor. The Editor is the final authority on the output of a Working Group's efforts, unless otherwise noted.
Members of the general public may apply to join the Working Group at any time, subject to the approval of the Editor, in their judgment, the applicant's experience and perspective would be particularly valuable to the development of the Working Group's efforts. A Working Group member may be removed at any time by the Editor if, in their judgment, the individual has become inactive for more than 30 days or if the individual is disruptive to the smooth functioning of the Working Group.
Project Representatives or a proxy they specify may apply to join the Working Group at any time, unless objected to by the Editor if, in their judgment, the applicant has little value to offer the process and/or would be disruptive to the smooth functioning of the Working Group.
An individual may be the Editor for more than one Working Group simultaneously.
A Full Working Group consists of an Editor, a Sponsor, and at least three other individuals. A Sponsor must be a member of the Core Committee. In a Full Working Group, the Editor and Sponsor share membership management responsibilities.
An individual may be the Sponsor of more than one Working Group simultaneously.
Multiple other Core Committee members may also be on the working group if they wish.
A Limited Working Group consists of an Editor and at least two other individuals. No Sponsor is required. Any individual may be the Editor or member of a Limited Working Group, with the exception that the Editor may not also be a Secretary.
Working Groups are created by an Entrance Vote of the Core Committee. The Entrance Vote includes the appointment of an Editor and, if applicable, the Sponsor.
The Editor and, if applicable, the Sponsor may at any time notify the Core Committee that a given Working Group's task is complete. At that point the Working Group is dissolved, by Implicit Approval. If necessary, a Decision Vote to appoint a new Editor may be held.
The Editor or Sponsor of a Working Group may step down at any time by informing the Core Committee via the mailing list. If the departing individual specifies an intended replacement from the Working Group membership, that individual will assume the vacant role immediately, by Implicit Approval. If necessary, a Decision Vote to appoint a new Editor or Sponsor may be held following a suitable nomination period.
Should a Working Group be missing an Editor for 60 days; be missing a Sponsor for 60 days; have insufficient active members for 60 days; or show no signs of activity for six months, then the Core Committee may hold a Decision Vote to name a new Editor or Sponsor, following a suitable nomination process. One of the options in that Decision Vote must be to dissolve the Working Group. If no suitable candidates for Editor or Sponsor may be found, then the Working Group is automatically dissolved.
If a Working Group is dissolved, a new Working Group covering the same scope may be formed at a later date through a new Entrance Vote.
The Secretaries will ensure that the Working Group is provided with necessary resources to support their efforts, such as a dedicated GitHub repository, mailing list, chat room, or similar such tools.
The Core Committee is ultimately responsible for all artifacts produced by the PHP FIG. However, in the case of artifacts that are intended to change over time, the Core Committee may delegate that responsibility to a Maintainer for one or more related artifacts.
Evolving artifacts follow Semantic Versioning. If it is unclear if a given change would qualify as a bugfix vs a minor release, the Maintainer will assume minor release.
The Editor of a Working Group is automatically the Maintainer of that Working Group's effort and output.
The Maintainer of a given artifact is appointed by the Core Committee by Approval Vote. Once a given artifact is created, the Maintainer may step down and name a replacement Maintainer at any time with Implicit Approval. If necessary, a Decision vote to appoint a new Maintainer may be held following a suitable nomination period.
The Secretaries will ensure that the Maintainer has the necessary access and resources to develop the artifact, such as access to a GitHub repository, mailing list, chat room, or similar such tools.
The PHP FIG produces three primary forms of output artifact that are subject to established workflow processes. This list is not exhaustive of the activity or publication that the PHP FIG may engage in.