Membership Request Vote Processing: Sponsor Model

[Paul Jones]

Hi all,

Flattering though it is to be considered such, I am not the official membership request vote-couting person. :-)

I cannot be counted on (ha!) to tally votes in a timely manner. Probably no single person on this list can be. As such, we need a more sustainable rule to make sure people are encouraged to vote on membership requests, and that the votes get tallied in a timely manner.

I suggest a "sponsor" model. In this approach, the applicant seeks out a sponsor; that is, a current voting member. That can happen on the list, or off. Then when the applicant makes his request, he names his sponsor as part of the application email.

The sponsor, for his part, is in charge of the voting process. He notes the starting and ending dates, the number of voting members at the start of the vote, and the quorum count needed. He sends out reminders by whatever means he feels appropriate to drive the vote. At the end of the voting period, he tallies the votes, notes if quorum was established, and whether or not the application was accepted.

This approach distributes the workload so that we're not dependent on any one person, and nothing gets left "to the group" (or to me ;-) to be handled appropriately.

What do we think of that idea?

* * *

Having said all that, I will tally up the current membership vote threads and follow through on updating any accepted members.


-- pmj

[Ryan Parman]

I'm game. Let's document the process on the site somewhere so that we can all easily find it, and can then know what needs to be done. IMO, this doesn't need a vote or anything. JFDI.

> --
> You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
> To post to this group, send email to php...@googlegroups.com.
> To unsubscribe from this group, send email to php-fig+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Larry Garfield]

Makes complete sense to me. +1.

(And if someone can't find anyone to sponsor them, that's probably an
indication they wouldn't be accepted anyway.)

--Larry Garfield

[Mike van Riel]

Nothing to add, sounds good. +1

To unsubscribe from this group, send email to php-fig+unsubscribe@googlegroups.com.

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

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To post to this group, send email to php...@googlegroups.com.

To unsubscribe from this group, send email to php-fig+unsubscribe@googlegroups.com.

[Paul Dragoonis]

Sounds good to me paul. It solves an obvious problem.

To unsubscribe from this group, send email to php-fig+u...@googlegroups.com.

[Brett Bieber]

On Wed, Dec 5, 2012 at 6:36 PM, Paul Jones <pmjo...@gmail.com> wrote:

Flattering though it is to be considered such, I am not the official membership request vote-couting person. :-)

I cannot be counted on (ha!) to tally votes in a timely manner.  Probably no single person on this list can be.  As such, we need a more sustainable rule to make sure people are encouraged to vote on membership requests, and that the votes get tallied in a timely manner.

I suggest a "sponsor" model. In this approach, the applicant seeks out a sponsor; that is, a current voting member.  That can happen on the list, or off.  Then when the applicant makes his request, he names his sponsor as part of the application email.

The sponsor, for his part, is in charge of the voting process.  He notes the starting and ending dates, the number of voting members at the start of the vote, and the quorum count needed.  He sends out reminders by whatever means he feels appropriate to drive the vote.  At the end of the voting period, he tallies the votes, notes if quorum was established, and whether or not the application was accepted.

This approach distributes the workload so that we're not dependent on any one person, and nothing gets left "to the group" (or to me ;-) to be handled appropriately.

What do we think of that idea?

Sounds good to me.

--
Brett Bieber

[William Durand]

+1

--

William Durand | http://www.williamdurand.fr

--

[Devon H. O'Dell]

2012/12/5 Paul Jones <pmjo...@gmail.com>:
<...>

> What do we think of that idea?

It sounds like a great idea to this non-member.

One (at least tangentially) related question is whether new members
can vote in an overlapping time period. That is: person A starts the
process at T1, person B at T2. A becomes a member at T3, B becomes a
member at T4. (These times are sequential.) Is A eligible to vote on
B? Is the quorum value inclusive of A or is it determined at the time
the vote began?

I realize that this is inconsequential for me; I seem to recall some
of these questions coming up in other voting threads and I don't know
whether they were answered (or at least, I didn't see the answers).
Apologies if this is already well-defined.

--dho

> * * *
>
> Having said all that, I will tally up the current membership vote threads and follow through on updating any accepted members.
>
>
> -- pmj
>

[justin]

On Thu, Dec 6, 2012 at 9:38 AM, Devon H. O'Dell <devon...@gmail.com> wrote:

One (at least tangentially) related question is whether new members
can vote in an overlapping time period. That is: person A starts the
process at T1, person B at T2. A becomes a member at T3, B becomes a
member at T4. (These times are sequential.) Is A eligible to vote on
B? Is the quorum value inclusive of A or is it determined at the time
the vote began?

A fair approach might be: if A chooses to vote on B, the quorum value would be inclusive of A. If A abstains, the quorum value should not include A.

--j

[Phil Sturgeon]

As a heads up, the new Review Workflow bylaw forces a "Coordinator" to take the role of "vote counter person" for any PSR-related votes, so a similar deal should be set up for membership voting.

I say the sponsor should be in charge of counting? That's how I've done it in the past.

[Larry Garfield]

I thought that was already the idea of the membership application
process; a sponsor is responsible for endorsing, calling a vote,
counting, and if it passes filing a pull request to add the
project/person to the site.

--Larry Garfield

> --
> 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/8aa0160d-2caa-4937-82f2-2f9627ad670a%40googlegroups.com.

[Donald Gilbert]

+1 - the sponsor should be the point of contact for the applicant to the FIG, and as such take responsibility for initiating and counting votes.