User:Alex.rollin-GmailCom/Vote Processing

What is Vote Processing

Vote Procesing is what happens to votes after they are counted on a pollserver. Within this document it is usually meant to specifically be the actions to be performed by a set of scripts that have access to the counted votes on the pollserver. In this case, with a Votorola pollserver, we are dealing with the raw votes and the vote count.

(May be out of date. See current version, or help edit it, here.

This link shows the flow of data in the Votorola system universe and where vote processing sits in that chain. The simple idea is to show that vote processing happens after the votes are processed by the Votorola pollserver. Also, implicit in this, is the idea that something will be done with processed votes.

In fact, what will happen is that processed votes may be used to make changes back on the pollwiki, as well as to drive additional display of vote results in another UI somewhere else. That UI could be something like th Crossforum UI idea.

What's Involved in Vote Processing

The reason vote processing is needed could be one or more of:

1. The vote processing done by Votorola is only a part of the vote processing required by the group of voters using votorola
2. A group of votorola requires additional rules to process votes and take action
3. Groups will have a custom votorola registration list that is enacted through the pollwiki, respected by the pollserver, and then want to publish results or take action in a place besides the pollserver with pollserver data
4. Groups will have their own vote processing needs, so a custom vote processor as a modular solution is a resonable way to insert such a capacity into the system as it currently stands.

Interaction with the Votorola system is in these areas.

1. Votes are counted within the pollserver and moved out to another system for additional processing. The vote processor does not write data back to the pollserver at this time.
2. Changes may be made to the pollwiki based on vote processing. Generally the best process is to write to the pollwiki, or annotate it, as opposed to deleting anything

What is the scope of the vote processing project currently?

Vote processing needs will differ by group. One of the points of this project is to be as exhaustive as necessary in order to examine the needs of the groups that Alex Rollin is working with through Summer of 2011 in order to look at how Votorola will serve those needs and facilitate what is required for vote processing to be a part of fulfilling those needs.

Actions to be taken within the sphere of vote processing

Actions to be taken on the pollwiki

1. Confirm voter list as properties on the user page of voters (apply tag "invalid registration')
2. Read or write metadata to positions as necessary that includes specifics for a custom voter list
3. Compare position metadata with voter list to qualify positions and trigger actions
4. Create and maintain publicly viewable list of active revisions for positions based on rules within the area of the organization on the pollwiki

Data sets to be compiled within vote processing

1. Vote count
2. Triggered actions
3. Edits to be made to pollwiki
4. Current "Active" positions for an organization (should match the pollwiki, serves as a backup and comparison for assertive edits on the pollwiki

Display of datasets based on vote processing

This area is really for another place, and right now is best logically grouped under crossforum theatre. However, there are a few simple things to note that will allow this feature to be compatible with the idea of crossforum theatre in the long run.

1. Allow a tree or chunks of a tree, to be seen in a GUI
2. Allow a sorting of polls and identification of position based upon the criteria specific by rules implemented within vote processing
3. Allow some form of traversal of the tree based on the custom voter list of a group

Rules that could be used in Vote Processing

Each of these rules needs a couple of use cases in order to clarify it. To qualify a rule needs to have:

1. Description of information needed to trigger the rule
2. Clear action that must be taken when triggered
3. Clear description of what, if any, edits should be done to the pollwiki

Right now the easy way to do this is to talk as if the components are separate and then to build full rules from the components.

Entities

1. Vote trace
2. Raw vote count
3. Vote count
4. Voter
5. Registered Voter
6. Poll
7. Position
8. Pollwiki
9. Pollserver
10. Votorola Pollserver
11. Registration List

Quanitities

There needs to be a clear way to know how to talk about individual voters and their actions within a poll. These definitions of quantities will be rectified with the pollwiki and pollserver definitions

1. Total qualified voters
2. Total Cast Votes
3.  % of cast votes
4.  % of total qualified voters
5. Elapsed duration of position revision
6. Elapsed duration of vote count
7. Elapsed duration of (A) vote trace

Position/Poll States

How to refer to polls in the context of triggers and actions.

1. Invalid Candidate (candidate may not propose an actionable position)
2. Valid Candidate (candidate may propose an actionable position)
3. Invalid Poll(poll not yet subject to vote processing and action)
4. Valid Poll (poll subject to vote processing and action)
5. Invalid Position (position does not conform to the vote processing schema for this poll)
6. Valid Position (position conforms to the vote processing schema for this poll. valid positions can become active)
7. Active Position (active positions can become inactive)
8. Deactivated Position (triggers are no longer valid under current counts)

Triggers

Triggers are the if then condition that contributes to a rule being acted upon.

1. A certain quantity of votes
2. A certain quantity of

Questions that need to be answered

What is raw count and vote count, from the votorola pollserver? Which is useful for vote processing and why?

How to implement and maintain vote processing scripts in ways that allow it to work easily with the pollwiki and the pollserver?

I'm going to write about group voting on another page here:

results processing. deciding when cutoffs are reached. that little thing has the information and that's where it's kept. it needs an api to ask it where a poll is or what state it is in. then you have to show that to the users somehow.

its a method of acting on votes, but not an election method in itself. you could have different decisions taking place on the same polls at the same time. the UI is going away from votorola.

the results processor would take information from the pollserver. another app would visualize it. the UI app would poll results processing for information about post-processed results. the resultprocessor is only interested in current information from the pollserver. its all public right now. it stores that dump of the information and processes it. it would need to poll every four hours.

aside from storing and archiving and making available that account, it would also make the stage avialable. it could protect the wiki page, make a copy of it, store the url of the revision, of the frozen position. after that it just makes that information available until the next cutoff is available.

the use case is for legislation. locking the draft. making a copy of it. communicating that it can't be change.

One of the rules could be

User could lock the draft. If they want to tick the clock they could freeze the draft.

Revision (linkx) trigger the (linky organization) voting rules (linkz).

We should be able to query the semweb for a list of toilet paper proposals that are finalized within

Results bot should write information in. Results bot needs to be able to read/parse the position semweb data. Saves having to point the poll to the position. It's easy to infer the poll from the position because it is part of the name

need a way to write a custom voter list pollserver qualifies the final vote

hook it into a trust network.

policing on the pollwiki is okay with annotation in malicious contexts

you could allow people to assert division page would say what rules would be used. with a central wiki page protection an admin stuff.

raw data and count data. count data includes filtering and tallies, as well as the counts. it says how many at level of the nodes. they won't care that that someone who is unqualified has cast a vote.

anon can make positions but they cant vote. they wont show up in count data except as an end candidate. they can't vote.

my voter registration list will keep people from voting.

general votorola info here

The Votorola system includes a number of functional programs including the trust server. The primary user is the public user, completely unorganized. In theory it's the public sphere. We're coding an insitution of the publc sphere for communicative action; consensus building among people who are organized. As habermas says, a communicatively structured society, so a tool that is communicately structured.

For example there are impedence mismatch. The one we mentioned has no cutoffs. The public sphere has no cutoffs. There's no sense in saying "at midnight at such and such date the decision is finalized." We are designing outside of those cutoffs.

Any voting platform or voting facility is a pollserver. By this definition, a pollserver takes votes, stores them, and counts them. That is a statement about the architecture. In the architecture.

* Poll identification and definition

The poll server pulls this information from the pollwiki. The pollwiki is a passive thing. The pollwiki is dumb database where you organize information that endusers will want to have access to. Specifically read/write access.

A tool called Vomeer copies from Nationbuilder currently. It is called an autocaster, that votes on behalf of the votes on Nationabuilder. Currently that autocaster would know how the vote IDs of a remote pollserver. It would know how to count those votes. Otherwise that autocaster has to know how to do that translation. The ideal place for getting that information is from the pollwiki, which means end user rules. It would be a poll page compoentn where users could point o pollservers that dont have an equivalent ID scheme. It could be we have times where we have two pols in the same pollwiki that we decided are the same poll. We may need mirroring for reasons besides translation. When you take your area and go into a separate wiki. We might just do it with wholesale transfer we might just close the poll on the original on the central pollserver, then you could be safe to transfer the votes to a separate site. You wold have to do it with vote mirroring so that the votes would show.

A redirect to the voting page.

The hwole interface for voting will go to the UI. This means the poll counts, and basically what the poll server does now.

Instead of having a page right now where you go to votorola you would move that off into a UI layer. People would use whatever UI they wanted to cast their votes. The pollserver ends up being a dumb database.

The Pollwiki is not part of votorola. The pollwiki is at the center of it. The place the votes would be polled from would be the votorola pollwiki. The votorola pollwiki only Nationabuilder would pull its votes directly fr4om the pollserver. As long as it's better than not mirroring at all. In the case of the votorola method, you would need to have a trace of the votes available. Votorola is going to have to provide anyway. It doesn't have an API that is easy to trace a vote.

Tree perusal

votorola pollserver just votes. doesnt need vote counts. later when we do autocasting they can do the votes in the ui. all it does it store votes as votes foor a candidate. the api has to allow you to trace a tree. the vote know who you are voting for. you can construct a tree yourself using the api. it wil give you chunks of tress it doesnt store the raaw counts. it stores cumulative votes along the tree. you know the ote flow that passes through each candidate voter. storing the votes and the vote counts.

it does a single job. it stays separate so there can be different front ends to the pollserver. people have different ideas for how things shoudl be counted. some people may not like recursive delegation you will never get people to agree on the voting method. the reason it is communicative. places in the tree people. you can talk to people.

a UI would read from a pollserver.

* Defining electoral districts and other polling divisions
* Voter registration (streetwiki only)

Residential voter registry combined with the trust server. Not going to be separate from the pollwiki. They are combined, currently, in the pollwiki, as they may be going forward.

* Trust signing (streetwiki only)
* Indexing of poll positions by mailish username
* Provision of default drafting medium, e.g. for position statements
* Pollwiki hosting (in case of multi-area pollwiki)

Plans are to prototype cross forum theatre. Everybody is a client of the pollwiki and everybody is a client of it. It is not a part of votorola.

Cross forum ranging is the ability to travel across tools. One tool is a voting tool and one is a discussion tool. There's another called free-range drafting. The purpose of all these is to prevent split consensus.

Events discussion list post

Voting on positions

what if i want everyone to be able to vote as well as make positions but i want custom processed results that specify a tree with all my registration list and any links through non-registered voters with positions.

this means raw votes with my own tabulations.

spanish - consensus origin in spain in spanish - uswer uses google to translate position into english and changes it.

he votes for a spanish guy and makes the changes and shows the changes.

have to have a position in each language.