Proposal: a solution for member participation

319 views
Skip to first unread message

Alessandro Lai

unread,
Dec 9, 2015, 8:55:54 PM12/9/15
to PHP Framework Interoperability Group
(Hello there. Community member here, I come here sometimes, and I've translated some PSR. Just FYI, I would like to put in my 2 cents)

In the past weeks, we've experienced some problems with the participation of voting members. Just a few days ago, quorum wasn't met for a membership vote, PSR6 has seen a lot of debate and passed with just 16 +1 on nearly 50 voting members, and so on. Other threads were open to discuss this problem, and I put a little of my time thinking about it.

An idea came to me, a simple modification to the voting process:

Count every member that didn't vote as a -1

This seems a little harsh, but let me list the pros:

- quorum is no longer needed, the absolute majority needs to be achieved
- +0 gains importance
- no more +0 just to avoid insulting someone
- you are encouraged to vote and show effort, or you will drag down any vote

To counter the problems of participation, with the entrance of a secretary, we could enforce some hard rules for continuous absence from vote, like counting abstaining and +0 and revoking (temporarily?) the voting right to the offending member; I would suggest a mandatory "show of interest and participation" as a requirement to regain the voting right.

What do you think about it? I would like to spring a productive discussion about it...

Jason Walker

unread,
Dec 10, 2015, 1:08:28 AM12/10/15
to PHP Framework Interoperability Group
Hi everyone,

This is my first post as an on-off lurker around here. I think what the PHP-FIG is doing is wonderful and I believe your open format (in terms of crafting standards) is great.  That said, as an observer, I'd like to add an opinion to this conversation surrounding voting.

There has been some recent discussion around voter turnout among members and participation in general. I do not wish to really comment on participation because my gut tells me that folks probably do participate off-list which makes the list (which is where I get 95% of my FIG info from) a bad benchmark for participation on some levels (excluding votes, of course).  I also feel that the upcoming secretary positions will play a role in how participation is tracked (and encouraged) so I'm anxious to see how that plays out.

That said, I feel under the current voting bylaws that the FIG is in an (involuntary) position to pass standards (and memberships) based on "cliques" instead of voting community majority.  I don't feel that the requirements around quorum and majority +1 votes reflect the size of the group properly.  Currently, as of the PSR-6 acceptance vote, the FIG is at 43 members, meaning quorum is around 16 and simple majority is at 9.  In a minimal effort situation (or majority abstention with or without valid reasoning) it only takes 21% of the voting community to pass a standard or accept a new member.  I don't believe this is in line with what it means to adopt standards/voting reps in line with a community majority.

The +0 abstention vote should not be shunned and should be allowed to make an impact on quorum, if even at a reduced impact.  This may be sticky territory because in terms of PSR's and membership applications there can be a number of reasons why a rep will vote +0. They may recognize the effort and discussion on the list, but be too busy to review the spec and/or put a proof of concept together to see how it works with their project - provided it even applies. They may not have the domain knowledge regarding the subject and therefore do not wish to vote +1/-1 due to that.  They may simply not care about that particular spec (again, might not apply to them) but do not want to hold a potentially good measure up from others using it.  There could be a number of reasons for a plus +0 vote, so an abstention vote should stay regardless.  

Beyond that, members should always avoid voting +0 if they would have voted -1 just to avoid backlash.  I couldn't say (nor prove for that matter) how much of that goes on, but to individual members, interoperability trumps feelings as far as I am concerned.  The best thing a person voting -1 can do is offer valuable and constructive criticism.  If you feel something goes against the core goals of the group and/or doesn't help interoperability - don't abstain - vote against it.  If that isn't the reason though and a +0 fits better - by all means vote that instead.

With all of that I will give my own opinion on how the voting protocol should work:

- Quorum becomes super majority (2/3) of the voting member populace. (Would be 29 with a group of 43 members.)
- Super majority (again 2/3) in terms of +1's to accept a new member or standard. (Would be 20 +1's in a quorum of 29.)
- Cap the abstention votes (+0) at 33% of turnout in terms of calculating quorum. Absent votes do not count for anything (like usual).
- Round up calculations in all cases.

Examples: 

15 @ +1, 5 @ -1, 20 @ +0 (40 votes, 3 absent) = Vote doesn't pass - Quorum not met (20 + 7 = 27.)
20 @ +1, 0 @ -1, 23 @ +0 (43 votes, 0 absent) = Vote doesn't pass - Quorum not met, although enough +1 votes (20 + 8 = 28, 20 of 20 +1's needed)
19 @ +1, 8 @ -1, 10 @ +0 (37 votes, 6 absent) = Vote doesn't pass - Quorum met, but not enough +1 votes (27 + 4 = 31, 19 of 20 +1's needed)
25 @ +1, 5 @ -1, 13 @ +0 (43 votes, 0 absent) = Vote passes - Quorum met (30 + 5 = 35, 25 of 20 +1's needed.)

This may make things harder to get through, but also puts onus on the various PSR working groups and potential members to put more effort into the spec and be noisier on *why* their standard should be a recommendation or *why* they should have voting privileges. 

I don't believe this will make folks magically start voting +1 where they would have voted +0 (or -1) but will instead encourage working groups/voting hopefuls to attempt to achieve a higher adoption rate in the pre-draft/draft/application stages before going to an entrance/acceptance/membership vote.

My $1.05 on the matter.

Thanks,

Jason

Alessandro Lai

unread,
Dec 10, 2015, 8:01:43 PM12/10/15
to PHP Framework Interoperability Group
This proposal is distant from mine, but I like it anyway because we have one thing in common: we want to diminish the value of +0.

Right now, a +0 can be a -1 in disguise, but it practice it will count as a +1,because it will increase the quorum but not the number of +1 needed!

I think we're getting to the bottom of this problem, and that the other issue to be tackled, aside from +0 OP, should be incouraging members' participation and involvement in votes.

Jason Walker

unread,
Dec 10, 2015, 8:56:51 PM12/10/15
to php...@googlegroups.com
Hi Alessandro,

Yes I fully agree that the +0 needs to have less influence than a +1/-1 in votes. Likewise I think your proposal is worthy of discussion. (And I did not mean to hijack your thread with an alternate proposal, hopefully the discussion takes a turn toward your idea.)


--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/zNhayZyXsEw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/d91a150e-8cb7-422e-9df0-c534fe5cc956%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Adam Culp

unread,
Dec 10, 2015, 11:08:26 PM12/10/15
to PHP Framework Interoperability Group

Chris Tankersley

unread,
Dec 10, 2015, 11:28:57 PM12/10/15
to php...@googlegroups.com
Part of what the new secretary role will do is start to properly and formally track inactive projects:

    "Tracking member project activity, and marking projects as inactive"

What constitutes an inactive member I don't believe has been codified (though if it has, great!) That will start to purge the number of projects down, lowering the quorum needed for votes to be official.

I'm hesitant to say that not voting at all is an automatic -1, because there might be reasons that a project doesn't vote. I'd rather it stay the same and just be used to determine the minimum number of voters required.

I'm also hesitant to say that a simple majority is all that is needed for votes. You could end up with a situation where only three members vote, with -1 and two +1's and all of a sudden we have a new PSR. I doubt that would happen, but the fate of a PSR, something that is deemed to have been vetted and decided upon by FIG, rests on the shoulders of three people. Having the quorum helps maintain that a good chunk of the member projects are at least taking notice of whatever is going on.

I'll admit, I've almost lost some stuff in the shuffle due to the PSR-12 and PSR-6 discussions that cropped up. I haven't been here long but I feel that's an oddity.

That's just my two cents though.


--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
Chris Tankersley
http://ctankersley.com

Dracony

unread,
Dec 11, 2015, 4:26:03 AM12/11/15
to PHP Framework Interoperability Group
We have already discussed these ideas in an earlier thread. All we'd achieve by enforcing voting is '+1' votes from the projects that didn't  have the time or the desire to checkout some new proposal or membership request. Voting +0 is a valid way of saying "I'll skip this one" when thwy are used moderately. I really know no solution to this sadly

Jason Walker

unread,
Dec 11, 2015, 10:05:00 AM12/11/15
to PHP Framework Interoperability Group
I think this is why increasing the quorum and majority +1 requirements may be useful.

Removing +0 votes I don't believe would help all that much (if any) since voting (or lack thereof) is considered by some to be a participation metric. But largely I believe that a +0 vote is a valid response, it just carries too much water.  I'm sure the voting reps have personal lives that need their attention first - families, jobs, etc.  There may not always be enough time to fully review a spec to make an informed +1/-1 vote, hence +0 fits well.  I don't think pressuring members who are volunteering their time for this stuff to make a definitive up/down vote is going to help. 

At the other end of the spectrum the voting bylaws allow for passage of PSR's with a small minority of the voting body throwing a +1 votes so long as quorum is met.  If there are a plethora of +0's in a vote (the reasons for the +0 does not matter) then you can push a PSR out with 1 out of 5 members supporting it.

Of course, at the end of all of this, once a PSR is accepted the un-written rule around them seems to be "Don't like it, don't use it."  So to that end perhaps the voting requirements are purposely relaxed to allow small groups of projects within the FIG to create standards they know they will use together.  But that is digressing from the topic at hand.

Alessandro Lai

unread,
Dec 11, 2015, 11:14:41 AM12/11/15
to PHP Framework Interoperability Group
Wait, I'm not advocating the removal of +0 votes. In my proposal, +0 remains, but has to be explicit, and the removal of quorum will lessen the weight of +0 itself. In this scenario, +0 means "I don't have the knowledge do vote properly, I abstain", not "I trust the majority of others".

In the other proposal, +0 are explicitly weakened by weighting 33% on the quorum.

Still, the issue seems to be the weight of +0.

Alexander Deruwe

unread,
Dec 11, 2015, 11:14:52 AM12/11/15
to php...@googlegroups.com
If a project can't spend the time reviewing, then why are they a
voting member? Adhering to PSR's in their various projects doesn't
require being a voting member at all, wanting to get in and be a
voting member should be a commitment.

I normally just lurk, haven't contributed anything, but I'm a big
proponent of the "major" early PSR's. I just needed to speak up
because something seems way off here ...


Alexander
> https://groups.google.com/d/msgid/php-fig/4b6d404c-9e56-4c7b-afb1-b27e78feadc2%40googlegroups.com.

Jason Walker

unread,
Dec 11, 2015, 11:42:57 AM12/11/15
to PHP Framework Interoperability Group
Opps, sorry Allesandro, I wasn't suggesting you were advocating removing the +0 vote.  For some reason I had this topic on my mind still: https://groups.google.com/forum/#!topic/php-fig/Undf02UPb0U

In that discussion it was initially suggested than one way to lessen the impact of abstention is to drop the +0 vote.

Alessandro Lai

unread,
Dec 11, 2015, 2:44:06 PM12/11/15
to PHP Framework Interoperability Group
Maybe the reason I used was the less important. But +0 still can have meaning; for example, a particular PSR could not apply to a specific project, or/and the representative could not be familiar with the argument, maybe for the same reason.

This is why I don't think that +0 should be removed. But I remain convinced that it should be of lesser/no weight in the voting process.

Alessandro Lai

unread,
Dec 11, 2015, 2:45:44 PM12/11/15
to PHP Framework Interoperability Group
No worries! ;)

An addendum: maybe can we require a quick motivation behind any +0 vote?

Jason Walker

unread,
Dec 11, 2015, 3:44:47 PM12/11/15
to PHP Framework Interoperability Group
I believe that would be discouraging to voting in general.  I'm sure the voting members would not like having their vote put on the spotlight or their positions challenged because they cast a +0 (or any direction for that matter). 

Chris Tankersley

unread,
Dec 11, 2015, 4:11:37 PM12/11/15
to php...@googlegroups.com
On Fri, Dec 11, 2015 at 2:45 PM, Alessandro Lai <alessand...@gmail.com> wrote:
No worries! ;)

An addendum: maybe can we require a quick motivation behind any +0 vote? 

I think then we're inviting discussion into the voting thread. If someone votes +0 or -1 and wants to open a discussion thread that's fine, but no one should feel the need to publicly justify their votes. 

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Dracony

unread,
Dec 12, 2015, 6:44:26 AM12/12/15
to PHP Framework Interoperability Group
Changing the rules is not going to help, really. If you have people that just dont have the time or care about a particular thing no rule bending is going to solve that without it looking like policing our own members.

The only solution I can think of now is for the Secretary to identify non-contributing members (and that also means participating in the discussion etc) and then talking to them privately about their commitment to the FIG. Perhaps they only were interested in the first PSRs (autoloading, code standards) and not so much in the new ones, etc. The project would then decide to either forefeit their voting membership for some time (it would be fairly easy for them to pass another entrance vote if they wanted anyway) or commit to more involvement. The emphasis should be made that this is indeed a working group.

We could also allow voluntary membership suspension, the project declares its going to be dormant for a while, and they suspend their vote until further notice (thus lowering the quorum)

On Thursday, December 10, 2015 at 2:55:54 AM UTC+1, Alessandro Lai wrote:

Mike van Riel

unread,
Dec 12, 2015, 9:15:49 AM12/12/15
to php...@googlegroups.com
I’m opposed to diminishing the effect of having the +0 votes. For me it remains I abstain because of a reason but I want to defer the judgment to others. An example of this would have been PSR-6, where I, or the phpDocumentor community, did not feel adequately knowledgable to cast a vote either way. In this case I would abstain and defer to those who are knowledgeable on the topic.

Consider this: what is worse, that I vote +1 or -1 when I don’t know enough about a topic to make a properly informed decision?

I do however think that it may be of interest to research whether we should have a minimum number of positive votes or a ratio between positive and negative to have a convincing majority.
signature.asc

Matthew Weier O'Phinney

unread,
Dec 15, 2015, 1:53:48 PM12/15/15
to php...@googlegroups.com


On Dec 11, 2015 1:44 PM, "Alessandro Lai" <alessand...@gmail.com> wrote:
>
> Maybe the reason I used was the less important. But +0 still can have meaning;

In reading this thread, I get the sense that +0 and the effect it had on votes is not properly understood.

A majority is reached when a majority of votes cast are either -1 or +1 and quorum is met. As such, +0 have meaning in setting the number of votes twitted for a majority. As an example, let's say we have 39 member projects. By-laws indicate that quorum would then be 13, with 7 +1 votes twitted to pass. If we have 13 votes as follows:

- -1: 2
- +0: 7
- +1: 4

then the vote fails, as it did not receive half or greater of quorum.

As such, +0 is eminently relevant. The project casting +0 may feel they have insufficient understanding to vote either way, feel that it does not affect their project sufficiently to warrant a +1 or -1, etc — but they are indicating they are aware of the vote and willing to establish quorum.

I honestly don't think anything needs to change here, other than potentially raising the quorum requirements. The concept of quorum exists because we know it's impossible to guarantee 100% turnout for every vote; the question is: what threshold is acceptable?

> for example, a particular PSR could not apply to a specific project, or/and the representative could not be familiar with the argument, maybe for the same reason.
>
> This is why I don't think that +0 should be removed. But I remain convinced that it should be of lesser/no weight in the voting process.
>

> --
> You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/7b5eaa0b-10db-4785-9428-e9cd51d071aa%40googlegroups.com.

Jeremy Lindblom

unread,
Dec 15, 2015, 4:31:09 PM12/15/15
to php...@googlegroups.com
I think +0 is useful as well, but we might consider:

- raising quorum requirements
- requiring 2/3 majority
- failing a vote if there are too many +0 vs. +1/-1 (which might indicate that not enough reps care about it, so why are we trying to push it through)

--
Jeremy Lindblom (@jeremeamia)
Software/Platform Engineer at Engrade (part of McGraw-Hill Education)
Co-author of the AWS SDK for PHP (@awsforphp)
PHP-FIG Representative for the Guzzle project

Looking for a senior-level software engineering position doing PHP? I have some available with McGraw-Hill Education in Seattle and Los Angeles (Santa Monica or Irvine). Contact me for me more information.


Dracony

unread,
Dec 15, 2015, 4:59:35 PM12/15/15
to PHP Framework Interoperability Group
We really shouldn't dwell too much on the voting system imho, since ultimately it's not the problem. The problem is some projects/people don't hve the time/motivation to participate, and if that is so no changes to the actual system (short of maybe ways of revoking vote rights) are going to help much really. 


On Thursday, December 10, 2015 at 2:55:54 AM UTC+1, Alessandro Lai wrote:

Jason Walker

unread,
Dec 15, 2015, 6:31:20 PM12/15/15
to PHP Framework Interoperability Group
Well, voting may not be the ultimate problem, but I feel it is a contributor that if modified can help stimulate participation a little bit.  I'm still convinced that the voting should be tweaked to make the acceptance of newer standards and members gain broader support before admission.

In terms of voting only, I don't see anyone calling +1/-1 votes as a lack of participation.  When it comes to lack of participation in the voting threads it is the +0 votes and missing voters that are being called out.  Many have (rightfully) defended the +0 vote as it has valid use cases and have even made a good argument that +0 is indeed a show of participation.

That said, the voting system's low quorum/majority requirements does support mass abstention in allowing new standards or voting members into the group.  I think that directing focus away from "how members vote" to "how PSR's and voting hopefuls get their support" is a more relevant and attainable goal.  If you raise the bar for acceptance then the onus is on working groups and applicants to convince all those +0's that they deserve a +1.   It promotes the working groups to engage with the voting body, who in turn engage with the working groups to collaborate and contribute, provide opinions, show support, criticize (constructively of course), make a proof of concept, etc.  This will stimulate participation because now voters will want to get an idea of what they are voting in before casting a +1 (or -1 on the other end of things).  You can also see who isn't participating because the voting members are being prodded individually for input.

Collaboration means participation.  Collaboration become necessary when you aren't relying on a handful of +1's and a plethora of +0's to pass an acceptance vote.

Alessandro Lai

unread,
Dec 16, 2015, 11:47:54 AM12/16/15
to PHP Framework Interoperability Group
That, I think, is well understood. What is not ok in my opinion is that a PSR with this votes will pass:

+1: 2
+0: 30
-1: 1

That should be retracted ASAP, it's clear that a tournout like this isn't FIG backing this PSR.
So, that's why IMHO we should lower the weight of +0 in quorum, and/or require 2/3 majority. FIG should approve only PSR that are widely backed and approved by a LARGE majority of its voting members.

Roman Tsjupa

unread,
Dec 16, 2015, 11:51:25 AM12/16/15
to PHP FIG

Well 51% '+1' and 49% '-1' wouldn't look as fig is really backing a PSR too though.

You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/zNhayZyXsEw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

Alessandro Lai

unread,
Dec 16, 2015, 11:59:30 AM12/16/15
to PHP Framework Interoperability Group
Yes, exactly. That's why I was talking about a 2/3 majority too.
I know that these are harsh rules, but we could decide to enforce them only on really important votes, like the final ones on PSR.

Roman Tsjupa

unread,
Dec 16, 2015, 12:01:33 PM12/16/15
to PHP FIG

And then tweak each PSR for years (like the psr6) to make it pass. And as the result less standards out there.

Remember that perfect is the enemy of good.

Matthew Weier O'Phinney

unread,
Dec 16, 2015, 12:25:09 PM12/16/15
to php...@googlegroups.com
On Wed, Dec 16, 2015 at 10:47 AM, Alessandro Lai
<alessand...@gmail.com> wrote:
> That, I think, is well understood. What is not ok in my opinion is that a
> PSR with this votes will pass:
>
> +1: 2
> +0: 30
> -1: 1
>
> That should be retracted ASAP, it's clear that a tournout like this isn't
> FIG backing this PSR.
> So, that's why IMHO we should lower the weight of +0 in quorum, and/or
> require 2/3 majority. FIG should approve only PSR that are widely backed and
> approved by a LARGE majority of its voting members.

As I've explained elsewhere in one of the NUMEROUS threads opened in
the past week, that's not at all how the voting process works.

+0 votes are used both to establish quorum, as well as in the total
tally of votes. In your example above, there are 33 votes, of which 2
are +1 and 1 is -1. In order to pass, the vote needs a majority of the
*total*, or 17 in this case. That vote does not pass.
> https://groups.google.com/d/msgid/php-fig/650bfe46-81eb-4041-8338-5d79cff1c5d2%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



--
Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

Paul M. Jones

unread,
Dec 16, 2015, 12:46:27 PM12/16/15
to php...@googlegroups.com

> On Dec 16, 2015, at 11:25, Matthew Weier O'Phinney <mweiero...@gmail.com> wrote:
>
> On Wed, Dec 16, 2015 at 10:47 AM, Alessandro Lai
> <alessand...@gmail.com> wrote:
>> That, I think, is well understood. What is not ok in my opinion is that a
>> PSR with this votes will pass:
>>
>> +1: 2
>> +0: 30
>> -1: 1
>>
>> That should be retracted ASAP, it's clear that a tournout like this isn't
>> FIG backing this PSR.
>> So, that's why IMHO we should lower the weight of +0 in quorum, and/or
>> require 2/3 majority. FIG should approve only PSR that are widely backed and
>> approved by a LARGE majority of its voting members.
>
> As I've explained elsewhere in one of the NUMEROUS threads opened in
> the past week, that's not at all how the voting process works.
>
> +0 votes are used both to establish quorum, as well as in the total
> tally of votes. In your example above, there are 33 votes, of which 2
> are +1 and 1 is -1. In order to pass, the vote needs a majority of the
> *total*, or 17 in this case. That vote does not pass.

(/me grimaces)

Sorry, MWOP, that's a "pass." +0 counts only for quorum tally, not for pass/fail tally. Per <https://github.com/php-fig/fig-standards/blob/master/bylaws/001-voting-protocol.md>:

> N.b.: "Abstain" votes are counted only for quorum, and are not counted when calculating majority.

(At the time, the concern was that +0 would mean the same thing as -1, instead of true neutral, thus the reason for leaving them out of the majority calculation.)



--
Paul M. Jones
pmjo...@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php


Matthew Weier O'Phinney

unread,
Dec 17, 2015, 5:32:27 PM12/17/15
to php...@googlegroups.com
On Wed, Dec 16, 2015 at 11:46 AM, Paul M. Jones <pmjo...@gmail.com> wrote:
>
>> On Dec 16, 2015, at 11:25, Matthew Weier O'Phinney <mweiero...@gmail.com> wrote:
>>
>> On Wed, Dec 16, 2015 at 10:47 AM, Alessandro Lai
>> <alessand...@gmail.com> wrote:
>>> That, I think, is well understood. What is not ok in my opinion is that a
>>> PSR with this votes will pass:
>>>
>>> +1: 2
>>> +0: 30
>>> -1: 1
>>>
>>> That should be retracted ASAP, it's clear that a tournout like this isn't
>>> FIG backing this PSR.
>>> So, that's why IMHO we should lower the weight of +0 in quorum, and/or
>>> require 2/3 majority. FIG should approve only PSR that are widely backed and
>>> approved by a LARGE majority of its voting members.
>>
>> As I've explained elsewhere in one of the NUMEROUS threads opened in
>> the past week, that's not at all how the voting process works.
>>
>> +0 votes are used both to establish quorum, as well as in the total
>> tally of votes. In your example above, there are 33 votes, of which 2
>> are +1 and 1 is -1. In order to pass, the vote needs a majority of the
>> *total*, or 17 in this case. That vote does not pass.
>
> (/me grimaces)
>
> Sorry, MWOP, that's a "pass." +0 counts only for quorum tally, not for pass/fail tally. Per <https://github.com/php-fig/fig-standards/blob/master/bylaws/001-voting-protocol.md>:
>
>> N.b.: "Abstain" votes are counted only for quorum, and are not counted when calculating majority.
>
> (At the time, the concern was that +0 would mean the same thing as -1, instead of true neutral, thus the reason for leaving them out of the majority calculation.)

Well OUCH! I misunderstood this all along, then.

Since that's the case, I suggest we need to make the following changes:

- Either remove +0 entirely, OR
- Have +0 count towards the total votes cast when determining pass/fail, AND
- Raise the quorum.


--
Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

Jason Walker

unread,
Dec 17, 2015, 6:26:06 PM12/17/15
to PHP Framework Interoperability Group
The first time I read the voting bylaw I understood it the same way until I caught the footnote at the bottom.

As I've been reading the various voting related threads and even thinking about my own suggestion early in this thread I started to wonder there is too much focus on what a +0 means versus what it means to vote.

I feel +0 must stay, but that more +1 (relative to voting body) should be needed to pass a vote.

Has the FIG considered removing the quorum out right and requiring a simple or super majority of +1 to pass a vote?

Alessandro Lai

unread,
Dec 18, 2015, 4:11:43 AM12/18/15
to PHP Framework Interoperability Group
I wouldn't remove +0, there are still cases where it's a reasonable vote. I like the second proposal more.
Reply all
Reply to author
Forward
0 new messages