Jonathan Desrosiers 11:40 am on June 4, 2025  

Criteria for Creating or Migrating Repositories under the WordPress GitHub Organization

With WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. now following an annual release cadence, community-maintained canonical plugins have become even more crucial to the project. Because canonical plugins serve as official first-choice recommendations, they should live under the WordPress organization on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/. However, there are currently no guidelines around what is allowed or prohibited under the project’s GitHub organization. Establishing some clear criteria will help community members understand the requirements and expectations for this.

Core Principles

WordPress should balance experimentation with quality standards and project philosophy. GitHub repositories under WordPress should benefit the community, prevent single points of failure, and ensure open-source accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility).

Before outlining specific criteria, here are the underlying principles that guide these criteria:

  1. Community Ownership: Code that serves the WordPress project should be collectively owned and maintained rather than dependent on individuals.
  2. Responsible Stewardship: Maintainers must commit to responsible management of their repositories.
  3. Quality Assurance: All code under the WordPress umbrella should reflect the project’s commitment to excellence.
  4. Transparency: Clear documentation and communication about repository status and purpose.
  5. Inclusivity: Lowering barriers to contribution while maintaining standards.

Criteria for Inclusion

For a repository to be included in the WordPress GitHub organization, it must meet the following criteria:

Project Documentation and Goals

  • The repository must have a clear problem statement and some roughly outlined goals. This can be in the README.md file or linked to in a Making WordPress blog post.
  • Maintainers should aim to regularly post updates about the project at a cadence that makes sense for the overall level of activity.
  • The repository should have an agreed upon tag on the sponsoring team’s Make blog to easily find all related posts.

Team Sponsorship and Maintenance

  • The repository requires at least one active maintainer under an established Make Contributor team, with multiple maintainers encouraged for continuity. This should be noted in the repository’s READEME.md file at a minimum, and within the CODEOWNERS file if useful.
  • The sponsoring team takes collective ownership and responsibility for the repository’s oversight.

Maintenance Commitments

The contributor/team maintaining the repository agrees to reasonably maintain the project. This includes but is not limited to these expectations and requirements:

  • Issue Management: Triaging submitted feature requests and bug reports in a timely manner.
  • Communication: Responding to community questions and providing reasonable support channels.
  • Transparency: Clearly communicating the project’s status, roadmap, and any changes in maintenance capacity.
  • Best Practices: Adhering to project-level best practices and expectations.
  • Policy Compliance: Using project-level policies, such as being compatible with the GPLGPL GPL is an acronym for GNU Public License. It is the standard license WordPress uses for Open Source licensing https://wordpress.org/about/license/. The GPL is a ‘copyleft’ license https://www.gnu.org/licenses/copyleft.en.html. This means that derivative work can only be distributed under the same license terms. This is in distinction to permissive free software licenses, of which the BSD license and the MIT License are widely used examples., and the Community Code of Conduct.
  • Documentation: Maintaining clear, accessible documentation for users and potential contributors.

Quality Standards

Repositories must follow WordPress coding standards where appropriate, establish suitable testing processes, and maintain the same quality standards as other WordPress code bases.

Governance

  • Appeals or exceptions to these criteria can be discussed in the appropriate Make team blogs.
  • Periodic reviews of repositories may be conducted to ensure ongoing compliance with criteria.
  • Project leadership has the final say for what can be included.

Repository Lifecycle Management

Archiving Policy

  • If maintenance ceases and the repository does not represent a canonical pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, the repository will be archived after 6 months if reasonable efforts to find new maintainers are unsuccessful.
  • Archived repositories can be unarchived if factors change and/or a maintainer steps up.
  • Exceptions can be made to this policy. The repository’s current usage, importance to the ecosystem, maintenance burden, etc. should all be considered before archiving a repository.

Security Considerations

  • Unless a repository is explicitly mentioned in the project’s HackerOne policy, it will not be eligible for the project’s bug bounty program.
  • Should any security vulnerabilities be discovered, critical security issues must be addressed promptly in coordination with the Security Team, even in experimental repositories.

Special Considerations

  • Experimental repositories should be clearly labeled as such and may have modified expectations for support and stability.
  • Tools primarily used by WordPress contributors (e.g., phpunit-test-reporter) may also have different support requirements than user-facing components. Some repositories may require little to no maintenance and should remain open to signal that it’s still relevant.
  • Specific expectations and requirements for Canonical plugins should be explored separately.

Conclusion

These criteria balance innovation with WordPress’s high standards. They create a framework for healthy GitHub repository management that supports project growth while ensuring quality and sustainability. Community feedback is welcomed and encouraged so these guidelines can be improved to appropriately serve contributor needs.

Props @4thhubbard, @jeffpaul, @priethor, @johnbillion, and @annezazu for pre-publish review.