fig-standards: where PHP proposals are filed, and why a pull request on its own goes nowhere

Every PSR discussion happens on a mailing list, and GitHub is the wrong place to ask

The group states that all discussion regarding a PSR happens on its mailing list, that issues filed in GitHub are rarely monitored, and that pull requests are likely to be missed unless a message about them is sent to the list. It goes further: reviews of a proposed PSR should be conducted on the mailing list rather than through PR comments, for the same reason, and contributors are asked not to file an issue or pull request and walk away, because the expected outcome in that case is that it never gets seen or addressed. That inverts the assumption most people carry into an open source repository, where the pull request list is the queue. The cost falls on whoever wants a standard reviewed, since the work is the email thread and not the diff. A reviewer who does not read the list does not review, so a proposal can sit open on GitHub with nobody against it and still be entirely unexamined.

A proposal enters through proposed/, and nothing in the repository validates it

To propose a PSR you fork this repo, create a branch, check out that branch, add the PSR in proposed/, push the branch to GitHub, and send a pull request; or you create a ticket to start a discussion on GitHub; or you start a conversation on the mailing list. Three doors, and only the third is where review is described as happening. There is no code here to run. The top level holds CODEOWNERS, CONTRIBUTING.md, LICENSE-CC.md, LICENSE-MIT.md, LICENSE.md, PER.md, PSR.md, README.md, bylaws/, personnel.md, accepted/, and proposed/. There are no GitHub releases and no published package, so there is no version to depend on and nothing to install. For a reader, that means adoption is reading a markdown document and agreeing with your team, and the only status signal is which of the two directories the file occupies.

Membership is per project, and one request per thread

You do not need to be a voting member to take part in discussion on the mailing list, so participating and voting are separate privileges. To become a voting member you email the list with the subject line `Membership Request: {$your_name} ({$project_name})`, and the body carries your name, the name of and a link to the project you represent, plus whatever else you judge relevant; current members then vote on the request. Separate membership requests must not be combined into one thread, one request per thread. Two consequences follow. The voting body is defined by represented projects rather than by individuals, so a membership roster reads as a list of projects and the people behind them; the README says the current list of voting members is on the project website. And the README gives no route for a contributor with no project to put forward. The README says what a request contains and that members vote, then stops, without stating how long a vote runs or how a tie resolves.

English only, with translations handed to third parties nobody reviews

All PSRs are written in British English or American English, the choice may vary between specifications but is consistent within any single one, and the FIG does not offer official translations into other languages. External entities are free to translate the specifications in accordance with the license, and that sentence is the entire policy: permission without review. For a reader outside the English speaking PHP community the result is a standard that exists in a language no member maintains, that no member checks against the original when a specification is revised, and whose accuracy you cannot confirm from anything in this repository. The licensing question is not a single file either, since LICENSE.md, LICENSE-MIT.md, and LICENSE-CC.md sit side by side at the top level and the repository's own license field is recorded as unasserted, so anyone translating needs to work out which terms apply before publishing.

The group says adoption from outside is not the aim

The stated idea behind the group is for project representatives to talk about the commonalities between their projects and find ways to work together, and the stated main audience is each other, with an awareness that the rest of the PHP community is watching. People who want to adopt what the group does are welcome to, and the README is explicit that this is not the aim. That candid framing sets a limit worth naming plainly: nothing here obliges your framework to follow a PSR. There is no conformance suite, no test harness, no static analysis rule, and no CI job in this repository, so a PSR is prose that a member wrote and members voted on. For a library author outside the voting membership, choosing to follow one means trusting your own reading of the document, and the only external check available is whether the project that proposed it behaves the way the text says.

A stalled proposal has no documented ending

Documents sit in proposed/ until they are accepted, and the directory listing is where status lives. The README covers how to submit a proposal, where discussion happens, and how to request membership, and it says nothing about what happens when a proposal stalls. The README states no review deadline, no expiry rule for files in proposed/, no way to withdraw one, and no path for moving a document into accepted/ or marking one superseded. The top level does hold bylaws/ and personnel.md, which are the files to read for process, so a reader who needs to know whether a proposal is dead should look there rather than in the submission notes. The practical effect is that the health of the process cannot be read from the repository in one pass, since you have to open each document individually and the only evidence of motion anywhere in the tree is when a file was last touched.

FIG is an acronym this repository has no way to disambiguate

The repository is php-fig/fig-standards, described as standards either proposed or approved by the Framework Interoperability Group, with php-fig.org as its homepage and a master default branch. What you can verify on arrival: every entry at the top level is a document or a directory of documents, the last recorded push is dated 2026-07-03, and the project has no GitHub releases in its history.

Editorial conclusion

Adopt a PSR if you maintain a PHP library and want your conventions to line up with the projects that already ship alongside yours, and accept that the document itself is the entire specification. Do not expect enforcement, tooling, or a compatibility promise from it, because none of that exists in the repository. Before you build a contribution on it, check whether the proposal you care about sits in proposed/ or accepted/, read the license files yourself since the repository asserts no single license, and find the project's current voting members on php-fig.org before you assume a standard has broad support behind it.

Frequently asked questions

Official sources

1. Issues
2. php-fig/fig-standards on GitHub
3. Project website
4. README