The membership of the PHP Framework Interoperability Group (PHP-FIG) is comprised of Member Projects. This bylaw defines the rules and rights of membership.


Member Project
Any PHP project with voting rights admitted to PHP-FIG after submitting an application to the PHP-FIG mailing list under the Member Application procedure described in this bylaw.
Voting Representative
Any individual granted the right to cast votes on behalf of a Member Project.

Membership List

The current Member Projects in PHP-FIG will be listed at the following URL:

This list must also indicate the names of the current Voting Representative for each Member Project. This list must be updated for any change in the composition of Member Projects or Voting Representatives.

Membership Application

To cast votes on PHP-FIG proposals, it is required that a PHP project apply to become a Member Project. This application may be submitted by any individual who is authorised by the PHP project in question to do so.

The application must be emailed to the main php-fig mailing list and is restricted to one application per email. In order to be considered, all applications must be sponsored in advance by at least one existing Voting Representative.

The subject of the email must follow the following format:

Membership Request: {$your_name} ({$project_name})

The body of the email should provide details of the PHP project applying for membership including its name, URL, the name of the proposed Voting Representative, the name of the Voting Representative sponsor and any other details that the individual applying on behalf of the PHP project believes are necessary to include.

There must be a minimum two week period from the membership request being made before voting can begin to allow for necessary discussions.

The membership application can then be voted upon by the existing Member Projects in accordance with the Voting Protocol bylaw. PHP-FIG must perform checks to ensure that each application is valid and authorised by the PHP project that the applicant claims to act on behalf of. Once voting has completed and if the application has been deemed accepted, the PHP project will become a Member Project with immediate effect.

There are no restrictions on the number of times a PHP project may apply to become a Member Project.

Voting Representatives

The votes of all Member Projects are cast by Voting Representatives who have been authorised to do so by the Member Project. Each Voting Representative is chosen solely by a Member Project and their selection is not subject to the approval of PHP-FIG. A Voting Representative may be replaced by the Member Project which they represent at any time.

To prevent illegal or erroneous voting, the Voting Representative must be confirmed by the Member Project to be authorised to act in such a capacity by sending an email to the main php-fig mailing list. This email may be combined with a Member Application if the applicant has sufficient authority. The other Member Projects may seek such confirmation at any time during the Voting Representative’s term.

A Member Project may not have more than one Voting Representative at a time.

A Voting Representative may temporarily confer their voting rights onto another individual who is authorised by the Member Project which they represent. This conferral must be notified to PHP-FIG by the current Voting Representative by sending an email to the main php-fig mailing list. This email must state the name of the temporary Voting Representative and the period of time for which their temporary voting rights will remain valid. All voting rights will automatically return to the original Voting Representative at the end of the period of time stated in this email. All dates noted should reference a timezone. Where a timezone is not referenced, Coordinated Universal Time (UTC) will be assumed.

If, in the judgement of PHP-FIG, a Voting Representative is acting inappropriately and to the detriment of PHP-FIG’s ability to meet its objectives, a vote may be taken to request a replacement Voting Representative, or to expel the Member Project where replacing a Voting Representative is not possible.

The expulsion of a Voting Representative requires a vote in accordance with the Voting Protocol bylaw, with the exception that said Voting Representative will not have the ability to vote in their expulsion.

Resignation Of Member Projects

A Member Project may resign from PHP-FIG in writing to the main php-fig mailing list or by stating their intention to do so on another official public channel. Once such a statement is published, a PHP project immediately ceases to be a Member Project.

A former Member Project may reapply for membership at any future date.

Expulsion Of Member Projects

A Member Project may be expelled from PHP-FIG if, in the judgement of PHP-FIG, that Member Project has not casted votes in three consecutive voting calls or all voting calls over a period no less than six months whichever constitutes the greater period of time. It is the responsibility of Member Projects to ensure that they are actively represented by a Voting Representative.

A Member Project may also be expelled if their Voting Representative is subject to a replacement request from PHP-FIG but a suitable replacement is not available.

The expulsion of a Member Project requires a vote in accordance with the Voting Protocol bylaw, with the exception that the Voting Representative for said Member Project will not have the ability to vote.

FIG Secretary

Overarching role

The primary responsibility of the FIG Secretary is to serve as an impartial administrator of the FIG. They serve at the member projects pleasure but act as independent and impartial adjudicators. FIG Secretaries will 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.

Defined functions

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 above, perform other duties as nessasary.

  • Keeping the website, twitter and other marketing mediums up-to-date
  • GitHub organization administration
  • Tallying votes
  • Tracking member project activity, and marking projects as inactive
  • Ensuring bylaws are being followed
  • Clarifying any interpretation of bylaw text (If there is lack of consensus between FIG Secretaries then it must be put to a full vote according to the standard Voting Protocol bylaw).
  • Ensure that relevant marketing mediums (e.g. Twitter and Facebook) are kept professional, up to date and impartial.
  • Moderate discussions on github, the mailing list and IRC channels to ensure that an appropriate environment is maintained
  • Should there be a FIG meeting at a conference or other ad hoc gathering any Secretary in attendance should take notes to report back to the mailing list.

Access and Abilities

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 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 (just as any member project), 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.


Secretaries serve a two year term and the three secretaries votes are staggered eight months apart. One secretary is elected in January of even numbered years, one secretary is elected in August of even numbered years, and one secretary is voted upon in May of odd numbered years. For example there would be elections in January 2018, August 2018 and May 2019.

In the special case of the first election of secretaries, the three secretaries will be selected using Single Transferable Vote (Using the Droop Quota and Hare Counting Method). The first candidate to achieve enough votes will serve a term until the following January, the second candidate to achieve enough votes will serve a term until the following August and the third candidate to achieve enough votes will serve a term until the following May. If two or three candidates achieve enough votes at the same time then whoever achieved the higher number of first place votes will serve the longer term, and in the event that they achieved the same number of second place votes, then it shall be done on the number of second place votes and so on.

If more than one secretary is nominated and only one secretary is being elected we use Instant-Runoff Voting. Where only one candidate is nominated then instead of Instant Runoff the standard Voting Protocol will be used.

Once voted in, Secretaries are then in post until such a time as they resign, are removed by a vote of no confidence or until the end of their term.

On the last Sunday in one of the above mentioned months, the term finishes for the existing secretary and the voted upon secretary (who may be the same individual) will take up post. Any secretaries who are still eligible may re-stand for election as a secretary at this time. The vote for the new secretaries must be started no earlier than the first Sunday in the month and conclude at least one day before the previous secretaries leave post. The vote will be performed by the most recently elected secretary. The mailing list topic must be titled ‘[Vote] PHP FIG Secretary {MONTH} {YEAR}’.

Secretaries must be nominated/proposed by an existing PHP FIG representative or FIG Secretary to be considered in the vote by an email to the mailing list. People who wish to stand as secretary may seek proposers in any way they see fit (An email to the mailing list appealing or individual contact with FIG Members). In a situation where no secretary is elected, the other secretaries in post may use their discretion as to how to proceed (for example a second vote).

Any member project may call a vote of no confidence in a FIG Secretary where, if the majority (according to the Voting Protocol bylaw) vote in favour of their dismissal, they will be removed with immediate effect. The recording and tallying of votes in this instance is to be managed by another secretary together with the member project who called the vote. A vote of no confidence must be preceeded by a one-week discussion on the mailing list.

In the event of a resignation of a FIG Secretary or a vote of no confidence, they shall be removed with immediate effect and an existing FIG Secretary should commence a vote for a new secretary according to the aforementioned protocols. In the event of a resignation a special election will be performed following a similar procedure to regular elections under the administration of the remaining FIG Secretaries. The newly elected secretary would serve the remainder of the term that the outgoing secretary would have completed.

Eligibility Criteria:

The role should be filled by three people (working together to ensure impartiality in all matters and continuous availability) at any one time and those individuals must not be: * Project Representatives of a Member Project * An Editor of a PSR that is in Draft phase

If during a secretary’s term they become ineligible they must resign.