[PHP-DEV] [RFC] "Abstain" voting option for RFCs

Mailing Lists php.internals
1

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: PHP: rfc:rfc_vote_abstain
And the PR at: Add "Abstain" voting option and update phrasing for the voting by TimWolla · Pull Request #20 · php/policies · GitHub

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 :slight_smile:

2

On Tue, Jul 22, 2025, at 5:03 PM, Tim Düsterhus wrote:

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: PHP: rfc:rfc_vote_abstain
And the PR at: Add "Abstain" voting option and update phrasing for the voting by TimWolla · Pull Request #20 · php/policies · GitHub

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 :slight_smile:

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

3

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: PHP: rfc:rfc_vote_abstain
And the PR at: Add "Abstain" voting option and update phrasing for the voting by TimWolla · Pull Request #20 · php/policies · GitHub

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.

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 |
+---------------------------------------------------------------------+
| Appointments - Nextcloud |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+

4

There are two immediate benefits for me:

  1. 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.

  1. 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

5

Hey

Am 23.07.25 um 17:21 schrieb Volker Dusch:

On Wed, Jul 23, 2025 at 4:30 PM Andreas Heigl <andreas@heigl.org> wrote:

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:

1) 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.

2) 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 |
+---------------------------------------------------------------------+
| Appointments - Nextcloud |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+

6

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: Explicitly allow STV for secondary votes · TimWolla/policies@0d8eaf0 · GitHub

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 Add secondary vote example · TimWolla/policies@de94b7a · GitHub. 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

7

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 (PHP: 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 :slight_smile:

Best regards
Tim Düsterhus

8

On Thu, Jul 24, 2025, at 4:13 AM, Tim Düsterhus wrote:

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. :slight_smile:

Find the changes in the following commit:
Explicitly allow STV for secondary votes · TimWolla/policies@0d8eaf0 · GitHub

: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
Add secondary vote example · TimWolla/policies@de94b7a · GitHub.
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

9

On Thu, Jul 24, 2025, at 4:28 AM, Tim Düsterhus wrote:

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
(PHP: 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 :slight_smile:

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

10

Hi

On 7/24/25 15:42, Larry Garfield wrote:

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. :slight_smile:

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

11

On 27 July 2025 14:09:50 BST, "Tim Düsterhus" <tim@bastelstu.be> wrote:

Hi

On 7/24/25 15:42, Larry Garfield wrote:

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. :slight_smile:

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

12

People can just abstain by not voting anyway - I really don’t see what adding this would give us.

···

http://about.me/kenguest/

13

On Mon, Jul 28, 2025, at 3:38 AM, Ken Guest wrote:

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

14

On Sun, Jul 27, 2025, at 8:09 AM, Tim Düsterhus wrote:

Hi

On 7/24/25 15:42, Larry Garfield wrote:

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. :slight_smile:

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.

<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. :slight_smile:

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: Ranked voting - Wikipedia
</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

15

2025年7月28日(月) 23:31 Larry Garfield <larry@garfieldtech.com>:

On Mon, Jul 28, 2025, at 3:38 AM, Ken Guest wrote:
> 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)
- https://tekitoh-memdhoi.info
- youkidearitai (tekimen) · GitHub
-----------------------------

16

Hi

On 7/27/25 15:43, Derick Rethans wrote:

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

17

Hi

On 7/28/25 16:15, Larry Garfield wrote:

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

18

Hi

On 7/23/25 00:03, Tim Düsterhus wrote:

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 Add "Abstain" voting option and update phrasing for the voting by TimWolla · Pull Request #20 · php/policies · GitHub.

Best regards
Tim Düsterhus