Hi
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/130470
Voting runs until 2026-06-01 12:00:00 UTC. There is a single primary
vote to cast.
Best regards
Tim Düsterhus
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
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
mastodon: @derickr@phpc.social @xdebug@phpc.social
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
- 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
-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-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
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:
-
"I'm not sure I like the notion or language of 'hands-off' vs.
'hands-on' release managers." 1 -
"I disagree with designating whether anyone is 'hands-on' or
'hands-off.'" 1 -
"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 -
"If we can come up with better terminology around the roles [...]
then I'll probably change my vote to a 'yes.'" 2 -
"I've been thinking more about the terminology and have come up with
a concrete suggestion." 3 -
"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
Hi
Am 2026-06-01 15:49, schrieb Ben Ramsey:
At least 4 messages raised concerns about the naming of the roles:
"I'm not sure I like the notion or language of 'hands-off' vs.
'hands-on' release managers." [1]"I disagree with designating whether anyone is 'hands-on' or
'hands-off.'" [1]"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]"If we can come up with better terminology around the roles [...]
then I'll probably change my vote to a 'yes.'" [2]"I've been thinking more about the terminology and have come up with
a concrete suggestion." [3]"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
Hi
Am 2026-06-01 15:49, schrieb Ben Ramsey:
At least 4 messages raised concerns about the naming of the roles:
"I'm not sure I like the notion or language of 'hands-off' vs.
'hands-on' release managers." [1]"I disagree with designating whether anyone is 'hands-on' or
'hands-off.'" [1]"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]"If we can come up with better terminology around the roles [...]
then I'll probably change my vote to a 'yes.'" [2]"I've been thinking more about the terminology and have come up
with a concrete suggestion." [3]"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
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
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:
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.
The RFC has been accepted with 17 (Yes) to 6 (No) votes and 4
Abstentions (74%).
Best regards
Tim Düsterhus