Page MenuHomePhabricator

SecurePoll should evaluate voting requirements globally for global elections
Open, LowPublic

Description

Steps:

  1. Set up global poll with "Basic requirements" of requiring n edits or more to vote
  2. Try to vote from a wiki where you have fewer than n edits, but from an account that has more than n edits globally

Expected outcome: You're allowed to vote in the election since you have more than the required number of edits globally, even though you don't have the required number of edits on the one specific wiki you're voting from
Actual outcome: You're not allowed to vote in the election since it's only checking the number of edits you have on that wiki

SecurePoll should evaluate voting requirements globally for global elections, rather than locally on the wiki you're voting from

Event Timeline

Deskana raised the priority of this task from to Needs Triage.
Deskana updated the task description. (Show Details)
Deskana added subscribers: Deskana, Jalexander.
Deskana set Security to None.
Deskana added a subscriber: bd808.

@bd808 Here's the biggest issue that James A and I identified with SecurePoll in our testing of it. I'd say the time frame for requiring this is the board election in a few months.

bd808 triaged this task as High priority.Mar 3 2015, 7:28 PM

@bd808 Here's the biggest issue that James A and I identified with SecurePoll in our testing of it. I'd say the time frame for requiring this is the board election in a few months.

Marking as high priority.

@bd808 Here's the biggest issue that James A and I identified with SecurePoll in our testing of it. I'd say the time frame for requiring this is the board election in a few months.

Marking as high priority.

Thanks, to be clear we actually also need to be able to check a global voter list (so a voter list of global accounts that can vote from any wikis) since the election traditionally has an activity rule of X edits between Y and Z time. (in fact if necessary the global voter list alone would probably cover our requirements).

Thanks, to be clear we actually also need to be able to check a global voter list (so a voter list of global accounts that can vote from any wikis) since the election traditionally has an activity rule of X edits between Y and Z time. (in fact if necessary the global voter list alone would probably cover our requirements).

Is this something that has been created by an ad hoc process for past elections? Is the resulting list used manually somehow to verify voter eligibility or is it enforced at vote time? (/me knows nothing about SecurePoll and on wiki votes really).

Thanks, to be clear we actually also need to be able to check a global voter list (so a voter list of global accounts that can vote from any wikis) since the election traditionally has an activity rule of X edits between Y and Z time. (in fact if necessary the global voter list alone would probably cover our requirements).

Is this something that has been created by an ad hoc process for past elections? Is the resulting list used manually somehow to verify voter eligibility or is it enforced at vote time? (/me knows nothing about SecurePoll and on wiki votes really).

It's enforced at vote time (along with the 'basic' requirements) via a voter list in the database (traditionally on each wiki). In the past it was created by running a script on the cluster, at this point it can still be done that way and there is also an interface that can be used to create a list for the most common variables which ends up essentially running the same process to create the database list.

[My guess is that we could get what we want by having it look at a centralAuth table of voters or something like that but there are likely multiple ways.]

Just doing a bump on this to see where we are :)

Just to make sure I'm understanding the feature change being requested, the desire is for this scenario to pass:

Given a poll created for "all wikis"
And the poll has minimum edit constraint
When the constraint is checked for a user
Then the user's global edit count is compared to the constraint.

In addition to this feature change you will need an eligible voter list drawn from the CentralAuth user table so that anyone with a valid SUL account can vote.

Both things are a must have for an election to take place in June and a nice to have for an election in May.

Assuming all of these assumptions are correct, I'll be trying to get this into someone's schedule in April. Right now all the people who would be reasonable candidates to work on this are heads down working on things with nearer deadlines. If I've gotten something wrong in the analysis, especially the deadlines, let me know so I can re-evaluate.

@bd808: It's my understanding that your comment is correct. @Jalexander can hopefully confirm.

Just to make sure I'm understanding the feature change being requested, the desire is for this scenario to pass:

Given a poll created for "all wikis"
And the poll has minimum edit constraint
When the constraint is checked for a user
Then the user's global edit count is compared to the constraint.

In addition to this feature change you will need an eligible voter list drawn from the CentralAuth user table so that anyone with a valid SUL account can vote.

Both things are a must have for an election to take place in June and a nice to have for an election in May.

Assuming all of these assumptions are correct, I'll be trying to get this into someone's schedule in April. Right now all the people who would be reasonable candidates to work on this are heads down working on things with nearer deadlines. If I've gotten something wrong in the analysis, especially the deadlines, let me know so I can re-evaluate.

Aye, this is correct, if we have to prioritize I would actually prioritize the centralauth voter list part (the 2nd piece) because that would allow us to do the user edit piece anyway.

Regarding the nice to have for the May election, that is also my understanding but I would double check to ensure that there isn't a desire to make that more of a must have.

bd808 added a subscriber: tstarling.

Assigning to @tstarling. Our current hope is that he will be free to work on this in early April.

What exactly are the qualification rules for the Board election? As far as I know, the SecurePoll min-edits property has never been used for a Board election, so the fact that it isn't global is not relevant to the operation of Board elections, unless the idea is to use it for the first time this year?

What exactly are the qualification rules for the Board election? As far as I know, the SecurePoll min-edits property has never been used for a Board election, so the fact that it isn't global is not relevant to the operation of Board elections, unless the idea is to use it for the first time this year?

The final qualifications for this years election aren't 100% set yet because they need to be agreed upon by the election committee. 2 years ago it was over 300 edits total (globally) and 20 edits in the past 4.5 months (at the time it was specifically between 15 December 2012 and 30 April 2013). I strongly anticipate the requirements being similar this year, if not slightly lower edit rules. I don't think we need the specific min-edits property itself since we need to do a voter list anyway (because of the recent edits requirement) so we mostly need to have a voter list checked globally.

The final qualifications for this years election aren't 100% set yet because they need to be agreed upon by the election committee.

Please finalise the language as soon as possible, and finalise the numbers and dates at least 4 weeks before the start of the election.

2 years ago it was over 300 edits total (globally) and 20 edits in the past 4.5 months (at the time it was specifically between 15 December 2012 and 30 April 2013).

The scripts needed to do that are already written, they are in cli/wm-scripts/bv2013.

I don't think we need the specific min-edits property itself since we need to do a voter list anyway (because of the recent edits requirement) so we mostly need to have a voter list checked globally.

Well, the bug description is very specifically about min-edits. I will reduce the priority on it and create another one for updating the bv2013 scripts.

tstarling lowered the priority of this task from High to Low.Apr 7 2015, 6:11 AM
tstarling removed a project: MediaWiki-Core-Team.

Update bv2013 scripts: T95262