Hi
I just opened voting for the “Release Manager Selection” policy RFC.
The RFC text is in: PHP: rfc:release_manager_selection_policy
The PR with the actual policy is: Clarify policy for Release Manager Selection by TimWolla · Pull Request #28 · php/policies · GitHub
The discussion thread is: php.internals: [RFC] Release Manager Selection
Voting runs until 2026-06-01 12:00:00 UTC. There is a single primary vote to cast.
Best regards
Tim Düsterhus
On Mon, 18 May 2026, Tim Düsterhus wrote:
I just opened voting for the “Release Manager Selection” policy RFC.
The RFC text is in:
PHP: rfc:release_manager_selection_policy The PR with
the actual policy is: Clarify policy for Release Manager Selection by TimWolla · Pull Request #28 · php/policies · GitHub The
discussion thread is: php.internals: [RFC] Release Manager SelectionVoting runs until 2026-06-01 12:00:00 UTC. There is a single primary
vote to cast.
I voted no on this. Not because of the policies themselves, but because
"hands-off" and "hands-on" are phrases from a school yard — and
suggestions to come up with better names were ignored.
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Consider supporting me: Xdebug: Support
mastodon: @derickr@phpc.social @xdebug@phpc.social
On Mon, May 25, 2026 at 12:10 PM Derick Rethans <derick@php.net> wrote:
On Mon, 18 May 2026, Tim Düsterhus wrote:
I just opened voting for the “Release Manager Selection” policy RFC.
The RFC text is in:
https://wiki.php.net/rfc/release_manager_selection_policy The PR with
the actual policy is: https://github.com/php/policies/pull/28 The
discussion thread is: https://news-web.php.net/php.internals/130470Voting runs until 2026-06-01 12:00:00 UTC. There is a single primary
vote to cast.I voted no on this. Not because of the policies themselves, but because
“hands-off” and “hands-on” are phrases from a school yard — and
suggestions to come up with better names were ignored.cheers,
Derick
^^^This - I voted no for the same reason. If the RFC passes, I plan to write up a follow-up to change the terms.
After discussion with some other release managers and developers at PHPTek, I haven’t heard any arguments *against" the terms “Veteran release manager” and “Co-release managers”. Those terms would also makes it clear that
-Daniel
Hi,
Il 25/05/2026 21:16, Daniel Scherzer wrote:
^^^This - I voted no for the same reason. If the RFC passes, I plan to write up a follow-up to change the terms.
After discussion with some other release managers and developers at PHPTek, I haven't heard any arguments *against" the terms "Veteran release manager" and "Co-release managers". Those terms would also makes it clear that
* the veteran need not be "hands-off", that can be decided by the RM team
* the veteran is clearly a veteran (from the name) rather than just someone who doesn't do much ("hands-off") and you have to check the policy to understand why
* the veteran is still involved in things, even if they are not making the actual releases
I'm guilty of switching my vote twice already. I was, and still am, in favour of the change.
At first I took for granted that the feedback about the "hands‑on / hands‑off" terminology had been incorporated. When I realised it hadn’t, I was a bit disappointed and changed my vote.
Earlier today Volker reached out and kindly asked why. We had a brief chat, and I ended up deciding that it's not the end of the world if this RFC passes with the current wording. It's still much better than the alternative -- the RFC failing, delaying things further, or worse, stopping progress on the topic altogether.
I'd also be very much in favour of a follow‑up RFC to improve the terminology.
Cheers
--
Matteo Beccati
Hi
Am 2026-05-18 13:47, schrieb Tim Düsterhus:
I just opened voting for the “Release Manager Selection” policy RFC.
The RFC text is in: PHP: rfc:release_manager_selection_policy
The PR with the actual policy is: Clarify policy for Release Manager Selection by TimWolla · Pull Request #28 · php/policies · GitHub
The discussion thread is: php.internals: [RFC] Release Manager SelectionVoting runs until 2026-06-01 12:00:00 UTC. There is a single primary vote to cast.
The RFC has been accepted with 17 (Yes) to 6 (No) votes and 4 Abstentions (74%).
Best regards
Tim Düsterhus
Hi
Am 2026-05-25 18:50, schrieb Derick Rethans:
I voted no on this. Not because of the policies themselves, but because
"hands-off" and "hands-on" are phrases from a school yard — and
suggestions to come up with better names were ignored.
I don't think this is an accurate representation of the discussion. The concerns raised were with regard to the policy, not the naming of the roles. I also disagree with the notion that suggestions were “ignored”. I have replied to every discussion (sub-)thread.
Best regards
Tim Düsterhus
On 6/1/26 08:27, Tim Düsterhus wrote:
Hi
Am 2026-05-25 18:50, schrieb Derick Rethans:
I voted no on this. Not because of the policies themselves, but because
"hands-off" and "hands-on" are phrases from a school yard — and
suggestions to come up with better names were ignored.I don't think this is an accurate representation of the discussion. The concerns raised were with regard to the policy, not the naming of the roles. I also disagree with the notion that suggestions were “ignored”. I have replied to every discussion (sub-)thread.
At least 4 messages raised concerns about the naming of the roles:
1. "I'm not sure I like the notion or language of 'hands-off' vs. 'hands-on' release managers." [1]
2. "I disagree with designating whether anyone is 'hands-on' or 'hands-off.'" [1]
3. "I still dislike the distinction of 'hands-on' and 'hands-off' as descriptors for these roles and disagree with their use in defining these roles." [2]
4. "If we can come up with better terminology around the roles [...] then I'll probably change my vote to a 'yes.'" [2]
5. "I've been thinking more about the terminology and have come up with a concrete suggestion." [3]
6. "I agree with Ben, I would prefer 'Veteran Release Manager' / 'Co-release Manager' over 'hands on' / 'hands off'. The 'hands off' sounds negative to me." [4]
Cheers,
Ben
[1]: php.internals: Re: [RFC] Release Manager Selection
[2]: php.internals: Re: [RFC] Release Manager Selection
[3]: php.internals: Re: [RFC] Release Manager Selection
[4]: php.internals: Re: [RFC] Release Manager Selection
Hi
Am 2026-06-01 15:49, schrieb Ben Ramsey:
At least 4 messages raised concerns about the naming of the roles:
1. "I'm not sure I like the notion or language of 'hands-off' vs. 'hands-on' release managers." [1]
2. "I disagree with designating whether anyone is 'hands-on' or 'hands-off.'" [1]
3. "I still dislike the distinction of 'hands-on' and 'hands-off' as descriptors for these roles and disagree with their use in defining these roles." [2]
4. "If we can come up with better terminology around the roles [...] then I'll probably change my vote to a 'yes.'" [2]
5. "I've been thinking more about the terminology and have come up with a concrete suggestion." [3]
6. "I agree with Ben, I would prefer 'Veteran Release Manager' / 'Co-release Manager' over 'hands on' / 'hands off'. The 'hands off' sounds negative to me." [4]
(1), (2), and (3) were concerns with regard to the policy itself, not the terminology used. For (4) you elided the relevant part during, namely “and make the roles less about their level of involvement”, which is also a concern regarding the policy itself. And similarly the email that contained quote (5) also mentions “I don't want to define the roles around involvement”, which is a concern regarding the policy itself and (6) is in direct agreement of that without adding anything by itself.
Best regards
Tim Düsterhus
On 6/1/26 09:07, Tim Düsterhus wrote:
Hi
Am 2026-06-01 15:49, schrieb Ben Ramsey:
At least 4 messages raised concerns about the naming of the roles:
1. "I'm not sure I like the notion or language of 'hands-off' vs. 'hands-on' release managers." [1]
2. "I disagree with designating whether anyone is 'hands-on' or 'hands-off.'" [1]
3. "I still dislike the distinction of 'hands-on' and 'hands-off' as descriptors for these roles and disagree with their use in defining these roles." [2]
4. "If we can come up with better terminology around the roles [...] then I'll probably change my vote to a 'yes.'" [2]
5. "I've been thinking more about the terminology and have come up with a concrete suggestion." [3]
6. "I agree with Ben, I would prefer 'Veteran Release Manager' / 'Co- release Manager' over 'hands on' / 'hands off'. The 'hands off' sounds negative to me." [4]
(1), (2), and (3) were concerns with regard to the policy itself, not the terminology used. For (4) you elided the relevant part during, namely “and make the roles less about their level of involvement”, which is also a concern regarding the policy itself. And similarly the email that contained quote (5) also mentions “I don't want to define the roles around involvement”, which is a concern regarding the policy itself and (6) is in direct agreement of that without adding anything by itself.
Best regards
Tim Düsterhus
Since I wrote three of those messages, I should like to think I know what my own concerns were. The meaning of my statements can be both about the terminology _and_ the policy. These concerns aren't mutually exclusive.
I chose my words carefully. I referred to the "language" and used the words "designating," "descriptors," and "terminology," all of which are specific to the naming.
As for "eliding the relevant part," for the quotation, I was only focusing on the part that discussed the naming, but it looks like you did not consider that relevant.
Cheers,
Ben
Hi
Am 2026-06-01 16:15, schrieb Ben Ramsey:
Since I wrote three of those messages, I should like to think I know what my own concerns were. The meaning of my statements can be both about the terminology _and_ the policy. These concerns aren't mutually exclusive.
The requested change to the policy itself (“don't have separate roles”) necessarily implies a change to the terminology, since without separate roles there is no need for terminology describing the roles. I'm not a native speaker of English, but the way the emails were phrased, the two concerns were inseparably linked with each other with the concern about the policy being the “actual” concern (e.g. “notion of” in the first quote, “distinction” in the third quote, “and” from the elided part of the fourth quote). That's why I explained why the policy looks the way it looks, which didn't receive any further reply with clarification that the terms themselves would also be a concern for an otherwise unchanged policy.
Best regards
Tim Düsterhus
On 6/1/26 10:16, Tim Düsterhus wrote:
Hi
Am 2026-06-01 16:15, schrieb Ben Ramsey:
Since I wrote three of those messages, I should like to think I know what my own concerns were. The meaning of my statements can be both about the terminology _and_ the policy. These concerns aren't mutually exclusive.
The requested change to the policy itself (“don't have separate roles”) necessarily implies a change to the terminology, since without separate roles there is no need for terminology describing the roles. I'm not a native speaker of English, but the way the emails were phrased, the two concerns were inseparably linked with each other with the concern about the policy being the “actual” concern (e.g. “notion of” in the first quote, “distinction” in the third quote, “and” from the elided part of the fourth quote). That's why I explained why the policy looks the way it looks, which didn't receive any further reply with clarification that the terms themselves would also be a concern for an otherwise unchanged policy.
Best regards
Tim Düsterhus
No worries. I didn't reply with clarification because I assumed your response meant you were not interested in entertaining changes to the terminology. The vote has passed now, so I guess few others shared the same concerns.
Cheers,
Ben