# PHP FIG fig-standards: The PSR Specification Repository for PHP Framework Interoperability > PHP FIG fig-standards is the canonical repository for PHP Standard Recommendations, the specifications that let code from different PHP frameworks work together through shared interfaces. It is primarily a governance and documentation artifact, maintained by voting representatives from major PHP projects. **php-fig/fig-standards** — Standards either proposed or approved by the Framework Interop Group - Repository: https://github.com/php-fig/fig-standards - Website: http://www.php-fig.org/ - Stars: 12,516 · Forks: 2,791 - Language: Unknown - License: NOASSERTION - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/php-fig-fig-standards ## What PHP FIG Is and the Problem It Addresses PHP has a large ecosystem of frameworks that historically defined their own interfaces for common tasks such as logging, HTTP messaging, and dependency injection. Code written for one framework could not easily be reused in another because the contracts differed. The PHP Framework Interoperability Group (PHP FIG) exists to address that. It brings together representatives from major PHP projects to agree on minimal shared specifications. The README is explicit about the audience: "Our main audience is each other." PHP FIG does not produce libraries or implementations. It produces specification documents, the PHP Standard Recommendations, that framework and library authors can then implement. When multiple frameworks implement the same PSR, code that depends on the PSR interface works across all of them without modification. ## The fig-standards Repository Structure The repository is a documentation store. The top-level directories are accepted/ and proposed/. The accepted/ folder holds PSRs that have completed the review and voting process and are considered stable specifications. The proposed/ folder holds drafts under active discussion. Additional files include PSR.md, which describes the PSR workflow in detail, and PER.md, which covers PHP Evolving Recommendations, a separate track for specifications that can change over time rather than being frozen on acceptance. The bylaws/ directory contains the governance rules of the group, and personnel.md lists current voting members. There are no code files, no binaries, and no build system. The repository is purely a set of Markdown specification documents. The homepage at https://www.php-fig.org/ provides a rendered version of the specifications with better navigation than the raw GitHub view. ## How to Read and Navigate the fig-standards Repository The most direct way to use fig-standards is to browse the accepted/ directory on GitHub or clone the repository locally for offline reference: For contributors, the README describes the submission process: fork the repository, create a branch, add the new PSR document to proposed/, push the branch, and open a pull request. A key constraint is that GitHub is not the discussion venue. The README states that all discussion about a PSR happens on the mailing list at groups.google.com/group/php-fig, that issues filed on GitHub are rarely monitored, and that pull requests are likely to be missed unless accompanied by a message to the mailing list. Opening a PR and waiting for a response without contacting the mailing list is described as unlikely to produce any result. Voting membership requires sending an email to the mailing list with a subject line in the format "Membership Request: {your_name} ({project_name})" and including the name and a link to the project you represent. Current members then vote on the request. Non-members can participate in mailing list discussions without being voters. ## What the Accepted PSRs Cover The accepted/ directory contains the specifications that have completed the group's process. Common examples from the history of the project include specifications for autoloading, logging interfaces, HTTP message interfaces, HTTP client interfaces, and container interfaces, though the README does not enumerate them individually. Each PSR defines a minimal interface without dictating implementation. The proposed/ directory represents work in progress. Drafts in that folder may never advance to acceptance; the process requires sustained interest from the mailing list community, not just the initial proposal author. Because the primary audience is framework maintainers talking to each other, proposals that address problems only relevant to one framework's architecture tend not to gather the consensus needed for acceptance. ## Where PHP FIG Standards Have Limits PHP FIG specifications are intentionally minimal. They define the shape of an interface and its expected behavior, but they do not specify performance characteristics, error handling strategies beyond interface contracts, or implementation details. A PSR HTTP client interface specifies what a compliant client accepts and returns; it says nothing about connection pooling, retry behavior, or timeout defaults. The governance process is slow by design. Consensus among framework representatives from projects with different priorities takes time. The README warns that issues and PRs without corresponding mailing list threads will be ignored. For teams that need a fast-moving specification, this process is a real constraint. The license situation is marked NOASSERTION in the repository metadata. The repository contains separate LICENSE-MIT.md and LICENSE-CC.md files, which suggests the specifications may use Creative Commons licensing while code samples use MIT, but the README does not make this explicit. PHP FIG does not enforce adoption. A framework can ignore any PSR it chooses. The group has no authority over PHP itself or over any project that does not send a representative to vote. ## PSR-Based Interoperability vs Framework-Specific Contracts The alternative to PSRs is framework-native contract packages. Laravel, for example, ships an illuminate/contracts package that defines the interfaces used internally across the Laravel ecosystem. These contracts are more numerous and more opinionated than PSRs: they cover things like queue drivers, cache stores, and notification channels with Laravel-specific assumptions baked in. The difference in approach is scope. PSRs aim for the minimum interface that multiple projects can agree on, which makes them adoptable across frameworks but leaves implementation decisions entirely to each project. Framework-native contracts can be richer and more prescriptive, which is useful within their ecosystem but creates coupling when code outside that ecosystem tries to consume them. A logging library that implements PSR-3 can be dropped into Symfony, Laravel, or any other PSR-3 consumer. A library that depends on the illuminate/contracts logger interface works cleanly only in Laravel. ## Maintenance and Governance The last push to the repository was on 2026-07-03. The group continues to operate with its mailing list as the primary discussion venue. The bylaws/ directory and the personnel.md file track the governance structure and current voting members. Because the specifications in accepted/ are frozen after acceptance, the ongoing maintenance cost for consumers is low. Upgrading a library from PSR-3 to a hypothetical newer logging PSR would be a deliberate migration, not an automatic upgrade. The PER track, documented in PER.md, is specifically designed for recommendations that do need to evolve over time, which separates stable specifications from living ones. ## Conclusion PHP framework library authors who need to make their code work alongside packages from other projects should check whether accepted PSRs cover their interfaces before writing custom abstractions. Application developers rarely interact with fig-standards directly: the PSRs they care about are already implemented in popular frameworks. The mailing list is the correct channel for any discussion about existing or proposed specifications; GitHub issues in this repository are rarely monitored. ## FAQ ### What is PHP FIG and what does it produce? PHP FIG is the PHP Framework Interoperability Group, a collection of representatives from major PHP projects. It produces PHP Standard Recommendations (PSRs), which are minimal interface specifications that framework and library authors implement to make their code interoperable. ### How does a PSR move from proposed to accepted in fig-standards? A PSR begins as a document in the proposed/ directory submitted via pull request. All substantive discussion happens on the PHP FIG mailing list. Advancement requires consensus among voting members; the README states that pull requests and GitHub issues are rarely monitored without a corresponding mailing list thread. ### Do I need to be a PHP FIG voting member to use PSR specifications? No. The accepted PSRs are public documents that anyone can implement. Voting membership is only required to participate in the formal approval process. Non-members can participate in mailing list discussions without voting rights. ## Sources - [Issues](https://github.com/php-fig/fig-standards/issues) - [php-fig/fig-standards on GitHub](https://github.com/php-fig/fig-standards) - [Project website](http://www.php-fig.org/) - [README](https://github.com/php-fig/fig-standards/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/php-fig-fig-standards