docs: add MAINTAINERS guide

Document the conventions maintainers follow, so the practices we have
relied on tacitly are written down and discoverable. Covers the
"WordPressCS follows, it does not lead" principle for judging feature
requests, moderation rules (never delete, hide with reason), PR review
and merge expectations, branch handling, Dependabot triage, the release
outline, and cross-repo and upstream relationships.

Author: GaryJones

MAINTAINERS.md

@@ -0,0 +1,95 @@
+# Maintaining the WordPress Coding Standards
+
+This document describes the conventions maintainers of the WordPress Coding Standards (WordPressCS) follow when triaging issues, reviewing pull requests, and releasing new versions. It is aimed at maintainers and at contributors who want to understand how decisions are made.
+
+If you are looking to contribute a patch or a new sniff, start with [CONTRIBUTING](.github/CONTRIBUTING.md) instead.
+
+## Scope and philosophy: WordPressCS follows, it does not lead
+
+This is the single most important principle for judging feature requests, and it is worth understanding in full.
+
+WordPressCS is the *sniff implementation* of the [WordPress PHP coding standards as documented in the developer handbook](https://make.wordpress.org/core/handbook/best-practices/coding-standards/php/). For anything that concerns WordPress Core, WordPressCS does not get to decide what "correct" code looks like; it encodes a decision that has already been made and written down in the handbook.
+
+In practice this means:
+
+- **A change to the handbook must come first.** If someone wants WordPressCS to enforce (or stop enforcing) a particular convention, the convention needs to exist in the handbook before the sniff can change. WordPressCS should not invent or pre-empt standards.
+- **Non-trivial changes need community buy-in.** For anything beyond a trivial clarification, that typically means a post on [Make Core](https://make.wordpress.org/core/) to gather consensus. Be realistic about this: it only takes a single Core committer to disagree for a proposed change to be blocked, and that does happen.
+- **Review feature requests through this lens.** When triaging a feature request, the first question is rarely "is this a good idea?" but "is this already in the handbook, and if not, where is the discussion that would put it there?"
+
+There is a tension here. The handbook says the standards are meant for the whole WordPress community and not only Core, which in theory makes Core just one consumer among tens of thousands of projects. That argument has never worked in practice. A rule that Core itself does not follow looks odd, so proposals get judged against Core anyway. Core does still keep some exceptions of its own, and not only for bundled third-party packages, but do not count on the "just one consumer" point to unblock a change.
+
+## Code of conduct and moderation
+
+- Follow and uphold the [WordPress Code of Conduct](https://github.com/WordPress/.github/blob/trunk/CODE_OF_CONDUCT.md).
+- **Never delete a comment, issue or pull request.** This is a WordPress-organization-wide rule. If a comment needs to be removed from view, hide it with an appropriate reason rather than deleting it, so the record is preserved.
+
+## Reviewing and merging pull requests
+
+### Do not merge your own pull requests
+
+As a rule of thumb, never merge your own PR. There are two exceptions:
+
+1. **Release PRs**, which still need approvals but are merged on a planned date by whoever is running the release.
+2. **PRs that change a workflow.** Making the workflow change early would block other PRs, so the change should only be made *after* the PR has the required approvals and *just before* it is merged.
+
+### How many approvals a PR needs
+
+- **Trivial PRs** — for example Dependabot PRs where CI passes and no further changes are needed — need approval from **one** maintainer and can then be merged straight away.
+- **All other PRs** need approval from **two** maintainers, with the **second** maintainer doing the merge. The merging maintainer is also responsible for deciding whether the PR needs a squash-merge or not.
+- If the first approval has been given and the PR is then **changed significantly** (for instance, in response to the second maintainer's review), it needs a fresh review from either the first reviewer or another maintainer.
+- **When in doubt about a PR, do not merge.** Ping another maintainer for an extra pair of eyes.
+
+### Labels, milestones and related tickets
+
+Either of the two approvers must:
+
+- verify that the **labels** and **milestone** are set and correct, and
+- check that any **related tickets** will be closed by the PR, and give those tickets the milestone too.
+
+### External PRs
+
+For PRs from external contributors, **always favor the original poster (OP) making the changes** over a maintainer making them. Editing an external contributor's PR yourself should be rare, and only done when the PR is effectively abandoned or the change is genuinely trivial (such as fixing a typo).
+
+### AI-assisted contributions
+
+> [!NOTE]
+> This reflects the direction set by open PR [#2735](https://github.com/WordPress/WordPress-Coding-Standards/pull/2735), which is not yet merged. Until it is, [CONTRIBUTING](.github/CONTRIBUTING.md) still carries the older, stricter wording. Reconcile this section once #2735 lands.
+
+Contributors are free to use AI tooling, in line with the [WordPress AI Guidelines](https://make.wordpress.org/ai/handbook/ai-guidelines/). We ask only that they disclose what tooling they used and the extent to which a PR was authored by AI, and that they take responsibility for reviewing what the AI produced. When reviewing, do not reject a PR merely because AI was involved; judge it on its merits like any other, while holding the contributor to that disclosure and to the same quality bar. Direct any debate about the guidelines themselves to the AI team (via the [Make AI post](https://make.wordpress.org/ai/2026/02/01/ai-guidelines-for-wordpress/) or `#core-ai` on Slack), not to individual PR threads.
+
+## Working with branches
+
+- The branching model is documented in [CONTRIBUTING](.github/CONTRIBUTING.md#branches): ongoing development happens in `develop` and is merged to `main` once considered stable; feature branches are prefixed with `feature/`.
+- **If you have push access, push PR branches to the main repository, not to your fork.** This lets other maintainers check out your branch locally without adding an extra remote. Work-in-progress branches can, of course, still live on your own fork.
+- **For your own PR branches**, set the labels yourself, and set the milestone if it is clear-cut which release the change belongs in. When in doubt, leave the milestone open.
+
+## Dependabot pull requests
+
+Dependabot PRs are treated as trivial (one approval, then merge) when CI passes and no additional changes are needed. However:
+
+- **Always check the changelog for the update.** Read it for two reasons:
+  1. to see whether there is anything useful we could adopt in our own workflows, and
+  2. to gauge the risk of the update before merging.
+
+## Releases
+
+The full release procedure is documented in [`.github/release-checklist.md`](.github/release-checklist.md), which is the template used for release PRs from `develop` to `main`. In outline:
+
+- Releases go out as a PR from `develop` to `main`; the PR carries approvals but is merged on the planned release date by whoever is running the release.
+- Before release, dependency version ranges are reviewed, upstream releases (PHPCS, PHPCSUtils, PHPCSExtra) are checked for anything worth adopting, list-based sniffs and WP version properties are updated, every merged PR is confirmed to have a milestone, and the changelog is written.
+- After merging, tag and create a release against `main` (note that GitHub defaults the target to `develop`), close the milestone and open the next one, then fast-forward `develop` to equal `main`.
+- Afterwards, open a Trac ticket for WordPress Core, and publicize the release: a Make WordPress post for major releases, a note in the `#core` channel on the WordPress.org Slack (the `#core-coding-standard` channel receives an automated notification), and the optional marketing follow-ups listed in the checklist.
+
+## Related repositories
+
+Maintainers of the WordPressCS repository should also always be given commit/maintain access to the [`wpcs-docs`](https://github.com/WordPress/wpcs-docs) repository.
+
+## Upstream dependencies
+
+WordPressCS builds on, and coordinates closely with, several upstream projects maintained under the [PHPCSStandards](https://github.com/PHPCSStandards) organization:
+
+- [PHP_CodeSniffer](https://github.com/PHPCSStandards/PHP_CodeSniffer)
+- [PHPCSUtils](https://github.com/PHPCSStandards/PHPCSUtils)
+- [PHPCSExtra](https://github.com/PHPCSStandards/PHPCSExtra)
+
+Issues with sniffs whose names start with `Generic`, `PEAR`, `PSR1`, `PSR2`, `PSR12`, `Squiz` or `Zend` belong upstream in PHP_CodeSniffer; those starting with `Modernize`, `NormalizedArrays` or `Universal` belong in PHPCSExtra. See [CONTRIBUTING](.github/CONTRIBUTING.md#upstream-issues) for details.