Release Manager Selection View as Markdown

Introduction

The current policy about the “Release Manager Selection” process is using unclear and confusing terminology and allows for decisions to be made that no longer match the currently practiced reality and leave room for ambiguity with regard to the interpretation of the voting results.

As an example, it specifies that “[t]he release manager team consists of two or three people” where “at least one […] should be a ‘veteran’” and “[t]he other can be […] a veteran, or […] someone new”. It is not clear how the decision between two or three RMs is to be made and what happens if a veteran receives fewer votes than “someone new”.

In practice the last several PHP versions always had 3 RMs, with the veteran RM being one of the RMs of the previous PHP version and not actively participating in the “daily business” and two “rookie” RMs who were provided advice by the veteran. The “call for applications” usually also specifically mentioned a 1 veteran + 2 rookie split, which added to confusion as to how the voting should be set up when multiple applicants qualified for the veteran role.

This policy RFC intents to clarify the process by using clearer terminology and removing “alternatives”.

Proposal

Accept the policy in https://github.com/php/policies/pull/28.

To summarize the policy from a high-level perspective, the policy specifies:

1. That there are 3 RMs for each version. 2 of them are “hands-on” (actually doing the work) and one of them is “hands-off” (providing advice and being available as a backup).
2. That RMs may not be “hands-on” for more than one actively supported version (first two years) at the same time.

The policy aims to match the “current working practice” of the RM selection in the past several years.

Open Issues

None.

Future Scope

None.

Voting Choices

Primary Vote requiring a 2/3 majority to accept the RFC:

Vote: Accept php/policies PR #28 (Clarify policy for Release Manager Selection) at commit d887ee1e1ece6a46d1d621d2d551474cb15ea161? — Yes: 17 · No: 6 · Abstain: 4 (closed)

Patches and Tests

• https://github.com/php/policies/pull/28

Implementation

After the RFC is implemented, this section should contain:

1. the version(s) it was merged into
2. a link to the git commit(s)
3. a link to the PHP manual entry for the feature

References

• Discussion: https://news-web.php.net/php.internals/130470

• Voting: https://news-web.php.net/php.internals/130937

• The PHP 8.6 call for RMs: https://news-web.php.net/php.internals/130240

• An email pointing out unclear terminology in the PHP 8.6 application thread: https://news-web.php.net/php.internals/130402

Rejected Features

None.

Changelog

• 2026-03-27: Initial version
• 2026-05-03: Various changes to clarify and streamline the terminology