Hi
Adding an "Abstain" option to RFCs was an idea that floated around
multiple times in the past and it now came up again as part of (more
than) one of the RFCs that recently went to vote. I've therefore finally
written up a policy RFC to add such an option. As part of doing that I
have also cleaned up the phrasing of the corresponding section and added
some clarification of what I believe matches the current policy and just
wasn't written down, particularly around "secondary votes".
Please find the RFC at: https://wiki.php.net/rfc/rfc_vote_abstain
And the PR at: https://github.com/php/policies/pull/20
As with all policy RFCs, the corresponding PR to the policies repository
will be the authoritative source of the proposal and the RFC (and
discussion) will only provide extra context. Please do not comment on
the PR (except for minor typographical or phrasing clarification
suggestions). For comments regarding the actual "policy" reply to this
discussion thread for proper visibility instead and I'll make sure to
incorporate them as appropriate.
This message is intended to begin the official discussion period. While
it would be great to bring this policy into effect before any RFCs
targeting PHP 8.6, I'll make sure to monitor the (list) activity with
regard to folks being busy finalizing their own RFCs (and enjoying their
summer vacations [1]) to make sure everyone had plenty of opportunity to
participate in the discussion, so I would expect a vote around end of
August at the earliest.
Best regards
Tim Düsterhus
[1] I'll be on vacation myself in August :-)
Hi
Adding an "Abstain" option to RFCs was an idea that floated around
multiple times in the past and it now came up again as part of (more
than) one of the RFCs that recently went to vote. I've therefore finally
written up a policy RFC to add such an option. As part of doing that I
have also cleaned up the phrasing of the corresponding section and added
some clarification of what I believe matches the current policy and just
wasn't written down, particularly around "secondary votes".Please find the RFC at: https://wiki.php.net/rfc/rfc_vote_abstain
And the PR at: https://github.com/php/policies/pull/20As with all policy RFCs, the corresponding PR to the policies repository
will be the authoritative source of the proposal and the RFC (and
discussion) will only provide extra context. Please do not comment on
the PR (except for minor typographical or phrasing clarification
suggestions). For comments regarding the actual "policy" reply to this
discussion thread for proper visibility instead and I'll make sure to
incorporate them as appropriate.This message is intended to begin the official discussion period. While
it would be great to bring this policy into effect before any RFCs
targeting PHP 8.6, I'll make sure to monitor the (list) activity with
regard to folks being busy finalizing their own RFCs (and enjoying their
summer vacations [1]) to make sure everyone had plenty of opportunity to
participate in the discussion, so I would expect a vote around end of
August at the earliest.Best regards
Tim Düsterhus[1] I'll be on vacation myself in August :-)
I support this change. Thank you.
The only thing I'd add is that in the case of multi-option secondary votes, STV/RCV also be explicitly allowed. (Rank first, second, third, etc.). (I'm aware the mechanism for STV is kinda clunky on the wiki right now, but we know how to make it work.) Perhaps even encouraged if "do nothing" is not one of the options.
An example of both up/down and either/or secondary votes would also be helpful.
--Larry Garfield
Hi
Am 2025-07-23 16:05, schrieb Larry Garfield:
The only thing I'd add is that in the case of multi-option secondary
votes, STV/RCV also be explicitly allowed. (Rank first, second, third,
etc.). (I'm aware the mechanism for STV is kinda clunky on the wiki
right now, but we know how to make it work.) Perhaps even encouraged
if "do nothing" is not one of the options.
I meant to allow any alternative forms of “majority” with the:
The interpretation of the result of a secondary vote, necessary
threshold(s), and tie-breakers MUST be defined at the start of the
voting period.
rule, but it certainly makes sense to spell this out explicitly. I've
opted to only allow STV, because that's what is established in the
project, so participants already know how it works.
Find the changes in the following commit:
https://github.com/TimWolla/policies/commit/0d8eaf048f9a998bcc7bf6a8c696ba5452a255ae
An example of both up/down and either/or secondary votes would also be
helpful.
I have added an example for a plurality vote in
https://github.com/TimWolla/policies/commit/de94b7a132c4a74e54e7848914203f1849231697.
I am having trouble with phrasing an example for a non-plurality vote
that doesn't get complicated. If you have a suggestion, I'm happy to add
it. But a secondary vote with a 2/3 majority should already be known
from a primary vote and it's always necessary to clearly specify how the
results of secondary votes are interpreted for an individual vote.
Best regards
Tim Düsterhus
Hi
Am 2025-07-23 16:05, schrieb Larry Garfield:
The only thing I'd add is that in the case of multi-option secondary
votes, STV/RCV also be explicitly allowed. (Rank first, second, third,
etc.). (I'm aware the mechanism for STV is kinda clunky on the wiki
right now, but we know how to make it work.) Perhaps even encouraged
if "do nothing" is not one of the options.I meant to allow any alternative forms of “majority” with the:
The interpretation of the result of a secondary vote, necessary
threshold(s), and tie-breakers MUST be defined at the start of the
voting period.rule, but it certainly makes sense to spell this out explicitly. I've
opted to only allow STV, because that's what is established in the
project, so participants already know how it works.
Just to clarify here, Single Transferable Vote and Ranked Choice Voting are the same thing. I think it's just another Ameircan-vs-British English question. :-)
Find the changes in the following commit:
https://github.com/TimWolla/policies/commit/0d8eaf048f9a998bcc7bf6a8c696ba5452a255ae
:thumbs up emoji:
An example of both up/down and either/or secondary votes would also be
helpful.I have added an example for a plurality vote in
https://github.com/TimWolla/policies/commit/de94b7a132c4a74e54e7848914203f1849231697.
I am having trouble with phrasing an example for a non-plurality vote
that doesn't get complicated. If you have a suggestion, I'm happy to
add
it. But a secondary vote with a 2/3 majority should already be known
from a primary vote and it's always necessary to clearly specify how
the
results of secondary votes are interpreted for an individual vote.Best regards
Tim Düsterhus
How about this, as a following paragraph:
As an STV example, a secondary vote using STV and having 5 "Foo", 4 "Bar", 8 "Baz", and 9 "Abstain" first-choice votes has no majority, so will go to a second round. "Bar" will be eliminated and those votes redistributed to second-choice options. If for example the second round result is 6 "Foo", 9 "Baz", and 11 "Abstain", then Baz will have won as it has a clear majority of non-Abstain votes cast.
--Larry Garfield
Hi
Just to clarify here, Single Transferable Vote and Ranked Choice Voting are the same thing. I think it's just another Ameircan-vs-British English question. :-)
My understanding is that “Ranked Choice Voting” is a generic term of
which “Single Transferable Vote” is a specific implementation. I
specifically do not want to allow any other implementations than the one
the PHP project is already comfortable with using.
How about this, as a following paragraph:
As an STV example, a secondary vote using STV and having 5 "Foo", 4 "Bar", 8 "Baz", and 9 "Abstain" first-choice votes has no majority, so will go to a second round. "Bar" will be eliminated and those votes redistributed to second-choice options. If for example the second round result is 6 "Foo", 9 "Baz", and 11 "Abstain", then Baz will have won as it has a clear majority of non-Abstain votes cast.
That is quite verbose and requires two assumptions to be made, making it
hard to follow when not already knowing how STV works. I think it will
confuse more than it helps.
Best regards
Tim Düsterhus
Hi
Just to clarify here, Single Transferable Vote and Ranked Choice Voting are the same thing. I think it's just another Ameircan-vs-British English question. :-)
My understanding is that “Ranked Choice Voting” is a generic term of which “Single Transferable Vote” is a specific implementation. I specifically do not want to allow any other implementations than the one the PHP project is already comfortable with using.
That's my understanding too, and I also agree we shouldn't make it more complicated.
How about this, as a following paragraph:
As an STV example, a secondary vote using STV and having 5 "Foo", 4 "Bar", 8 "Baz", and 9 "Abstain" first-choice votes has no majority, so will go to a second round. "Bar" will be eliminated and those votes redistributed to second-choice options. If for example the second round result is 6 "Foo", 9 "Baz", and 11 "Abstain", then Baz will have won as it has a clear majority of non-Abstain votes cast.
That is quite verbose and requires two assumptions to be made, making it hard to follow when not already knowing how STV works. I think it will confuse more than it helps.
Please don't add abstention to STV votes. If you select fewer options than you can, that is already an abstention.
STV is really only used for secondaries (and release managers) anyway, so I would rather see this not get more complicated.
cheers
Derick
People can just abstain by not voting anyway - I really don't see what
adding this would give us.
Hi
Just to clarify here, Single Transferable Vote and Ranked Choice Voting
are the same thing. I think it's just another Ameircan-vs-British English
question. :-)My understanding is that “Ranked Choice Voting” is a generic term of
which “Single Transferable Vote” is a specific implementation. I
specifically do not want to allow any other implementations than the one
the PHP project is already comfortable with using.That's my understanding too, and I also agree we shouldn't make it more
complicated.How about this, as a following paragraph:
As an STV example, a secondary vote using STV and having 5 "Foo", 4
"Bar", 8 "Baz", and 9 "Abstain" first-choice votes has no majority, so will
go to a second round. "Bar" will be eliminated and those votes
redistributed to second-choice options. If for example the second round
result is 6 "Foo", 9 "Baz", and 11 "Abstain", then Baz will have won as it
has a clear majority of non-Abstain votes cast.That is quite verbose and requires two assumptions to be made, making it
hard to follow when not already knowing how STV works. I think it will
confuse more than it helps.Please don't add abstention to STV votes. If you select fewer options than
you can, that is already an abstention.STV is really only used for secondaries (and release managers) anyway, so
I would rather see this not get more complicated.cheers
Derick
People can just abstain by not voting anyway - I really don't see what
adding this would give us.
There are a couple of recent RFCs, including some in voting now, where I don't know enough about the subject to have an opinion, but I do want to be able to give the author the respect of having read it and acknowledged it. It also signals that I am paying attention and engaging, even if I don't have any particular input on this particular RFC.
So even without getting into quorum or "use it or lose it" policies, I would still find Abstain useful. Maybe not critical, but useful. And getting it in place, and people used to it, could simplify future steps of using Abstain for those or other things.
--Larry Garfield
2025年7月28日(月) 23:31 Larry Garfield larry@garfieldtech.com:
People can just abstain by not voting anyway - I really don't see what
adding this would give us.There are a couple of recent RFCs, including some in voting now, where I don't know enough about the subject to have an opinion, but I do want to be able to give the author the respect of having read it and acknowledged it. It also signals that I am paying attention and engaging, even if I don't have any particular input on this particular RFC.
So even without getting into quorum or "use it or lose it" policies, I would still find Abstain useful. Maybe not critical, but useful. And getting it in place, and people used to it, could simplify future steps of using Abstain for those or other things.
--Larry Garfield
Hi
I was suspicious that "Abstain" would not reflect a small number of opinions.
Because in Unicode's CJK position, it tends to be a small number of people.
However, I agree if you are just as Larry said, respecting the author
of the RFC.
Regards
Yuya
--
Yuya Hamada (tekimen)
Hi
That is quite verbose and requires two assumptions to be made, making it hard to follow when not already knowing how STV works. I think it will confuse more than it helps.
Please don't add abstention to STV votes. If you select fewer options than you can, that is already an abstention.
STV is really only used for secondaries (and release managers) anyway, so I would rather see this not get more complicated.
Having an “overall” abstention for secondary STV votes still makes sense
me (e.g. within the first widget only or as a separate single-option
widget to indicate abstention) to indicate that you do not want to
participate in the ranking at all.
I also believe that the current phrasing of the PR is good with that. A
vote that is decided by STV still is a single vote, even if it consists
of multiple voting widgets.
Best regards
Tim Düsterhus
<Tangent> Disclosure: I am a founding member of the Board of Directors for Fair Vote Illinois, the Ranked Choice Voting organization in my US state. I also led the ground campaign for my town to become the first in the state to vote to adopt RCV. So I have more than a passing involvement in these details. :-)Hi
Just to clarify here, Single Transferable Vote and Ranked Choice Voting are the same thing. I think it's just another Ameircan-vs-British English question. :-)
My understanding is that “Ranked Choice Voting” is a generic term of
which “Single Transferable Vote” is a specific implementation. I
specifically do not want to allow any other implementations than the one
the PHP project is already comfortable with using.
The terminology in this area is sadly rather muddled, as there are no formal terms. There are several closely related voting systems that involve voters listing choices in exclusive order. Collectively they are known as "Ranked Voting." There are then several different ways to count and collate the votes, though they all look identical to the voter.
Condorcet voting is where the winner is whoever would win in a one-v-one match up with every other candidate. This can be easily determined through a ranked ballot, though not all elections have a Concorcet winner.
Instant-runoff voting is what most people think of, where you eliminate low-ranked choices and count voters' next choices, until there is a majority winner. In the US, for reasons I don't understand, it's become commonplace to use the term "Ranked Choice Voting" for this method, and is the most common form of Ranked Voting in use today. It also goes by the name Preferential voting or Alternative vote in different areas, just to keep life confusing.
Single Transferable Vote, according to Wikipedia, is for electing multiple people in the same election. It involves counting fractional votes in case someone gets more votes than needed. It also goes by the name "Proportional Ranked Choice Voting." This is what FIG has long used for electing its leadership. Technically STV's degenerate case where there's only one choice being elected is equivalent to IRV/RCV.
There's also others like Bourda count, which are not relevant to us for now.
cf: https://en.wikipedia.org/wiki/Ranked_voting
</Tangent>
All that said, I am not suggesting we put "RCV" into the bylaw text. It's fine to just list STV as that's the term we already use.
How about this, as a following paragraph:
As an STV example, a secondary vote using STV and having 5 "Foo", 4 "Bar", 8 "Baz", and 9 "Abstain" first-choice votes has no majority, so will go to a second round. "Bar" will be eliminated and those votes redistributed to second-choice options. If for example the second round result is 6 "Foo", 9 "Baz", and 11 "Abstain", then Baz will have won as it has a clear majority of non-Abstain votes cast.
That is quite verbose and requires two assumptions to be made, making it
hard to follow when not already knowing how STV works. I think it will
confuse more than it helps.Best regards
Tim Düsterhus
It's 3 sentences, and less than 4 lines wrapped. I'd hardly call that verbose.
--Larry Garfield
Hi
How about this, as a following paragraph:
As an STV example, a secondary vote using STV and having 5 "Foo", 4 "Bar", 8 "Baz", and 9 "Abstain" first-choice votes has no majority, so will go to a second round. "Bar" will be eliminated and those votes redistributed to second-choice options. If for example the second round result is 6 "Foo", 9 "Baz", and 11 "Abstain", then Baz will have won as it has a clear majority of non-Abstain votes cast.
That is quite verbose and requires two assumptions to be made, making it
hard to follow when not already knowing how STV works. I think it will
confuse more than it helps.It's 3 sentences, and less than 4 lines wrapped. I'd hardly call that verbose.
Compared to the rest of the policies I'd still call it verbose. The
bigger issue to me is that it doesn't really explain much when you are
not already familiar with STV. Wikipedia is in a much better position to
explain this than the policy document. I also expect STV votes to be
fairly rare, most RFCs do not even come with secondary votes in the
first place, because details are decided in the discussion.
Best regards
Tim Düsterhus
Hey
Am 23.07.25 um 00:03 schrieb Tim Düsterhus:
Hi
Adding an "Abstain" option to RFCs was an idea that floated around
multiple times in the past and it now came up again as part of (more
than) one of the RFCs that recently went to vote. I've therefore finally
written up a policy RFC to add such an option. As part of doing that I
have also cleaned up the phrasing of the corresponding section and added
some clarification of what I believe matches the current policy and just
wasn't written down, particularly around "secondary votes".Please find the RFC at: https://wiki.php.net/rfc/rfc_vote_abstain
And the PR at: https://github.com/php/policies/pull/20As with all policy RFCs, the corresponding PR to the policies repository
will be the authoritative source of the proposal and the RFC (and
discussion) will only provide extra context. Please do not comment on
the PR (except for minor typographical or phrasing clarification
suggestions). For comments regarding the actual "policy" reply to this
discussion thread for proper visibility instead and I'll make sure to
incorporate them as appropriate.This message is intended to begin the official discussion period. While
it would be great to bring this policy into effect before any RFCs
targeting PHP 8.6, I'll make sure to monitor the (list) activity with
regard to folks being busy finalizing their own RFCs (and enjoying their
summer vacations [1]) to make sure everyone had plenty of opportunity to
participate in the discussion, so I would expect a vote around end of
August at the earliest.
I do like the idea!
But after some consideration I asked myself: Why?
If I do not want to vote, I currently do not vote. Easy as that.
Abstaining IMO only has a benefit to reach a certain quorum. Which to
this point isn't something we have implemented in the voting process.
Which is something that I was thinking about might be of interest to
introduce so that RFCs require a certain amount of votes to actually
have "merit" and aren't just something very esoteric that only 2 people
care about.
But as we do not have that I am not sure what the benefit of an
"abstain" would be - apart from seeing that person X did not
accidentally but deliberately not vote.
As there is no personal liability (at least to my knowledge) of someone
with Karma to actually vote I don't see the benefit.
Unless we introduce such a "liability" in terms of removing voting-karma
from people that have not voted within a certain amount of time - it
seems for them not to be of interest any more.
This would also allow us to reduce the amount of people with voting
karma to an overseeable number - IIRC the last time we checked we had
over 1000 people with voting karma but only at max 50 people or so
actually voting.
Adding an Abstain in combination with one of these changes
- Introducing a certain amount of minimum votes (including abstains)
- Connecting voting karma to actual particiation in votes
sounds very reasonable and worthwile in my opinion.
Adding an abstain just so one can see that one abstained on the other
hand seems to me rather pointless.
My 0.02€
Cheers
Andreas
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+
Adding an Abstain in combination with one of these changes
- Introducing a certain amount of minimum votes (including abstains)
- Connecting voting karma to actual particiation in votes
sounds very reasonable and worthwile in my opinion.
Adding an abstain just so one can see that one abstained on the other
hand seems to me rather pointless.
There are two immediate benefits for me:
- I get a couple of messages per week asking about a certain RFC, if I've
seen it, etc. For RFCs where I don't want to vote, it would be nice to
communicate that.
I don't vote on RFCs where I haven't read the implementation and tested
things, so for some topics I choose not to spend the time. Getting asked
about it by multiple people gets draining. Totally a "me" problem, sure,
but something that would be solved by allowing me to communicate that I've
seen the thing, publicly.
- Looking back, when going over the RFC list, it would be nice to see
which things I've read and engaged with. Not just what I voted on.
And I don't think it makes sense to tie future-looking policy changes into
this; that would require a way bigger scoped discussion.
Cheers,
Volker
--
Volker Dusch
Head of Engineering
Tideways GmbH
Königswinterer Str. 116
53227 Bonn
https://tideways.io/imprint
Sitz der Gesellschaft: Bonn
Geschäftsführer: Benjamin Außenhofer (geb. Eberlei)
Registergericht: Amtsgericht Bonn, HRB 22127
Hey
Am 23.07.25 um 17:21 schrieb Volker Dusch:
Adding an Abstain in combination with one of these changes
- Introducing a certain amount of minimum votes (including abstains)
- Connecting voting karma to actual particiation in votes
sounds very reasonable and worthwile in my opinion.
Adding an abstain just so one can see that one abstained on the other
hand seems to me rather pointless.There are two immediate benefits for me:
- I get a couple of messages per week asking about a certain RFC, if I've
seen it, etc. For RFCs where I don't want to vote, it would be nice to
communicate that.
Would that then mean that the abstain voting option would already be
open during the discussion phase?
I don't vote on RFCs where I haven't read the implementation and tested
things, so for some topics I choose not to spend the time. Getting asked
about it by multiple people gets draining. Totally a "me" problem, sure,
but something that would be solved by allowing me to communicate that I've
seen the thing, publicly.
- Looking back, when going over the RFC list, it would be nice to see
which things I've read and engaged with. Not just what I voted on.
But isn't that a third option that has not necessarily something to do
with voting? I mean, Interacting does not necessarily mean to vote
yes/no OR to abstain.
And I don't think it makes sense to tie future-looking policy changes into
this; that would require a way bigger scoped discussion.
I'd rather see it the other way around. For me the abstain would be a
consequence from the other - possibly bigger scoped - discussions.
As you point out, the abstain alone solves a me "problem". Changing the
process just for that, seems overkill to me.
But solving the future-looking policy changes along with this - and
"introducing a quorum" is mentioned as a "Future Scope" - is something
that I'd absolutely look forward to!
For me the abstain is neither a single change nor the beginning of a
process. For me it is the logical consequence of introducing a quorum.
Again, just my 0.02€
Cheers
Andreas
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+
Hi
Am 2025-07-23 17:34, schrieb Andreas Heigl:
As you point out, the abstain alone solves a me "problem". Changing the
process just for that, seems overkill to me.
Requiring an "Abstain" option in the voting widget is a simple change to
the process. It does not require any additional effort from RFC authors,
since I'll make sure to add it to the voting widget in the RFC template
(https://wiki.php.net/rfc/template) should this RFC pass.
I believe the proposal has sufficient merit on its own and also allows
us to collect "hard data" that can be used as part of a discussion for
future scope changes, such as an RFC quorum.
I don't believe having an "Abstain" option needs to be tied to larger
changes to the process and I am not interested in increasing the scope
of this RFC, intentionally leaving those to “Future Scope”. If you don't
see the value right now, but don't outright reject the proposal due to
being interested in future scope changes building on the proposal,
abstaining from the vote would probably be the right decision :-)
Best regards
Tim Düsterhus
Hi
Am 2025-07-23 17:34, schrieb Andreas Heigl:
As you point out, the abstain alone solves a me "problem". Changing the
process just for that, seems overkill to me.Requiring an "Abstain" option in the voting widget is a simple change to
the process. It does not require any additional effort from RFC authors,
since I'll make sure to add it to the voting widget in the RFC template
(https://wiki.php.net/rfc/template) should this RFC pass.I believe the proposal has sufficient merit on its own and also allows
us to collect "hard data" that can be used as part of a discussion for
future scope changes, such as an RFC quorum.I don't believe having an "Abstain" option needs to be tied to larger
changes to the process and I am not interested in increasing the scope
of this RFC, intentionally leaving those to “Future Scope”. If you don't
see the value right now, but don't outright reject the proposal due to
being interested in future scope changes building on the proposal,
abstaining from the vote would probably be the right decision :-)Best regards
Tim Düsterhus
Applying similar logic as for technical RFCs,
- This is self-contained.
- This dove-tails cleanly with planned and intended future development.
- Adopting it now does not preclude those future developments, nor do any harm to the language/process on its own.
- The order in which those related developments are adopted (eg, a quorum, or a "use it or lose it" policy, etc.) does not matter. If anything, it would make more sense for Abstain to come first, rather than after those.
- This one is largely uncontroversial, whereas a quorum or "use it or lose it" policy almost certainly would be.
Those all strike me as good reasons this is fine to adopt stand-alone and get it out of the way, just as, eg, pipes could be adopted without PFA, on the expectation of PFA later.
--Larry Garfield
Hi
This message is intended to begin the official discussion period. While
it would be great to bring this policy into effect before any RFCs
targeting PHP 8.6, I'll make sure to monitor the (list) activity with
regard to folks being busy finalizing their own RFCs (and enjoying their
summer vacations [1]) to make sure everyone had plenty of opportunity to
participate in the discussion, so I would expect a vote around end of
August at the earliest.
It turns out that most of the RFCs for PHP 8.5 have already been merged
for Beta 1 / soft freeze and the others are making good progress.
There's also little list activity overall.
The discussion for this RFC also didn't really bring up any major issues
or points of contention (other than “is this really necessary”, which
can be decided by the vote).
I therefore plan to open the vote at the end of the week / early next
week, which is a bit earlier than initially suggested. Of course if
anything worth discussing pops up after this email or someone asks for
additional time to review, we'll wait for that.
As of now the commit that will be voted on is
de94b7a132c4a74e54e7848914203f1849231697 in
https://github.com/php/policies/pull/20.
Best regards
Tim Düsterhus