Missing Winning Method

[bradley-holt]

Description

The mayoral results for the City of Burlington should show the winning method, as this election is decided by plurality of 40% rather than the standard 50%.

Steps to Reproduce

curl 'https://example.org/town-meeting-season-2011/city-of-burlington/burlington-mayor' \
-H 'Accept: application/json'

Actual Results

{
   "title":null,
   …
}

Expected Results

{
   "title":null,
   …
   "winning_method":"The candidate with at least 40% of the vote is the winner."
}

Additional Comments

A paragraph (<p>) with a class of winning-method containing the winning method description should be added to the HTML output after the results.

[gdoteof]

Can you be more specific with what you want/need here?

Are we adding a winning_method for every result; or jsut the mayoral election? Weren't we going to use the ballot item text to display this meta information?

If not, are we looking for a new freeform text box for the user the describe every winning method? Or do we want to auto-gen these sentences based off the already selected algorithm?

@acrawford thoughts?

[acrawford]

Well, I think auto-gen makes sense now. Before that winner calculation was being done at the API level, the plan was to simply have plain text threshold levels in the text-box describing the ballot item.

I think there is less room for error/omission if it is auto-generated. However, if there are only a few situations (Burlington Mayor 40%, City wide ballot Item needing 66%), I don't know if the effort is worth it.

Have we already figured out which permutations this is useful for? I am guessing it is useful when you are viewing a ballot item at a municipal level and want to get a feel of how close someone is to "winning". (As well as to bring some clarity around how a result is calculated.)

In light of the timeline and UI work still to be done, If you have time to do it, Geoff, then go ahead, otherwise, we will do it in the Ballot Item text. I feel like we are bolting things on late in the game. It seems like this might create issues as LG is out sick and I have no definitive wording to give to you for the auto-gen. It also seems like the ballot item text is just fine for this on TMD, and the text for referendums and elections will be different as well, which creates all the same permutation issues. Since we are putting the full ballot item text in, it may include this exact same information...

We can't reference the tabulation method, with data present, unless it is also clear to the end user if the results are complete or not so if geoff puts it in on all permutations, in many places it won't make any sense.

can the UI survive without this?

[acrawford]

sorry If I wasn't clear. I am making the call to not do this, but to have the tabulation method as part of the ballot item text description. I realize that means this will not have some of the case by case display of tabulation method separate from the ballot Item text description. I am fine with that. It should not be difficult to add this later on, but I feel the need to get things working in the UI.

We need to get folks at Channel 17 to the point where they can see what the interface is going to look like, and so that we can get some feedback and an iteration or two in before I setup the module on live and accomplish:

Setting up Navigation to the election_event level in Drupal finish setup of node-elec_election_event.tpl.php testing result updates in JavaScript any needed apache 2 server module config benchmarking / load testing data entry for this election season testing data entry by entering last year's election data on live as an election dry-run.

[bradley-holt]

I don't think that the winning method text is critical to the UI, especially if there are only a handful of ballot items that would need explanation. The winning threshold data would be good to have for the charts, but that's something different.