|
|
ISO User Requirements on Computer-Supported Voting and Polling |
Edited by Jacob Palme, e-mail: jpalme@dsv.su.se, at the research group for CMC (Computer Mediated Communication) in the Department of Computer and Systems Sciences at Stockholm University and KTH.
From: Subgroup for group communication during the co-located meeting of CCITT Study Group VII/Q.18, CCITT Study Group I/Q.15 and ISO/IEC JTC 1/SC 18/WG 4 SPWM in the Hague.
To: ISO/IEC JTC 1/SC 18/WG 1 and CCITT Study Group I/Q.17.
Title: Annex A: Draft user requirements for computer-supported voting and polling as a group communication task.
Version: 2.
Date: October 1991.
This paper is a draft of user requirements on standards for computer-supported voting and polling. Computer-supported voting and polling is a special application within the field of group communication.
Keywords: Computer conferencing, Bulletin Board systems, Message Handling Systems, Electronic Mail, Voting, Polling, Balloting.
|
Abbreviation |
Term |
Description |
|
|
Synchronous |
Cooperation which takes place in real time, i.e. the
users cooperating are at one and the same time exchanging
information |
|
|
Asynchronous |
Cooperation which does not take place in real time, information sent between participants is stored, so that one user can receive input from the other users and produce output to them at independent times. This does not preclude several active participants at the same time, but information between them might not be transmitted in real time. The present work on standardization of Group
Communication within ISO/IEC JTC 1/SC 18/WG 4 is only on
asynchronous group communication, not on synchronous group
communication. |
|
AGC |
Asynchronous Group Communication |
Tools to enable several people to cooperate, collaborate
and communicate to perform joint tasks via open networks |
|
ACC |
Asynchronous Computer Conferencing |
An application within group communication, which allows a
group of users to discuss issues through stored, structured
and interchanged contributions. |
|
CSVP |
Computer Supported Voting and Polling |
An application area which may occur as a subtask within
other group communication tasks. It may include the
definition of an agenda of issues, the selection of a
voting/polling profile, the collection of preferences and
the aggregation, analysis and presentation of a group
result. Voting and polling can be informative ("straw
votes") or decisive. |
|
VP, voting process |
Voting/polling Process |
The process of handling a particular vote from initiation
to result |
|
|
Voter |
A user (person, organization or organizational unit) who
is authorized to participate in a voting process |
|
Delegation |
Voting rights delegation |
When a voter delegates the right to vote on an issue or a
set of issues to another group communication user |
|
|
Vote |
The response on an issue given by a voter |
|
VG |
Vote group |
The group of voters who are authorized to participate in
a voting process |
|
Inititiator |
Vote Initiator |
The role of a group communication user who initiates a
voting process |
|
Profile |
Vote Profile |
A profile, which specifies a particular way to handle a
certain voting process |
|
Issue |
Vote Issue |
The issue to be addressed by a particular voting
process |
|
VOD |
Vote Opening Date |
The date/time when voters can begin inputting their
votes |
|
VCD |
Vote Closing Date |
A date/time after which voters are not allowed to input
their votes |
|
|
Vote period |
The time period between the VOD and the VCD |
|
|
Continuous vote |
A vote whose vote period overlaps with the discussion |
|
Agenda |
Vote Agenda |
A list of subissues to be answered in sequence for a
particular issue |
|
Form |
Vote Form |
The form of the agenda presented to the voters |
|
Observer |
Vote observer |
A group communication user who is allowed to view the
voting process but not allowed to put in votes |
|
|
Viewing threshold |
A condition on vote levels that must be reached before
the result can be viewed. |
|
Quorum |
Vote Quorum |
The number of voters required to answer before voting on
an issue can be closed |
|
|
Majority |
The percentage of the non-abstaining voters who must
agree for a decision to be reached |
|
|
Consensus |
100 % majority, i.e. all non-abstaining voters must agree
on the decision |
This work item is to produce a part of forthcoming group communication standards to cover the use of voting and polling as a tool for gathering opinion in group communication applications. Voting and polling may be used as an aid for making decisions. The standard is not intended to support formal elections, i.e. voting to choose people for roles.
There exist many different rules and procedures (voting profiles) for handling voting and polling. It is not the intention of the standard to prescribe which of these profiles to use, but rather to allow the system to provide a basic structure which can support many different voting profiles. An informative annex may however give some advice taken from social choice theory on pros and cons of various profiles.
The word "may", when employed in these user requirements, indicates different alternatives for handling voting. There is then a user requirement that the forthcoming standard should be capable of handling such alternatives.
Below are described steps which may be involved in a VP. The steps need not necessarily be taken in the order given here.
A voting or polling process (VP) starts when a decision has been taken to start it by a group communication user or group which has privileges to start a particular kind of voting or polling process. The decision to start a VP may in itself be done using a separate voting process. A voting or polling process is often preceded by a discussion on the issues to be voted on. However, when continuous voting is applied, the discussion and the voting may start at the same time. A group, company or organization may regulate who is allowed to initiate votes and which voting profiles are allowed for various kinds of voting processes within certain groups.
On a complex issue, with many alternatives, voting may be split up into a series of subvoting processes to follow each other. For example, one voting profile may be used in the first voting process to generate and/or select the most reasonable alternatives out of a large number of possible alternatives, and another profile may then be used to select the final choice among the alternatives chosen in the first voting process.
The voting group is the group of voters who are allowed to participate in a particular VP. An existing group, used for other purposes (such as Asynchronous Computer Conferencing, ACC) may be used, or a special group may be selected for this voting process, for example a defined subset of a larger group. Members of the voting group (voters) can be persons, organizations or organizational units. Voters may be allowed to delegate the voting right to others. A voter should be designated with an unambiguous name.
Voting observers (VO) who are allowed to view, but not participate, in the voting process may also be designated.
Before a VP can start, the voting issue, voting agenda, vote form and voting profile must be defined. (Some voting processes may allow this to be changed during the ongoing voting period.) This can be defined by the vote initiator, or through discussion within the VG. The choice can also be made through discussion in the VG or some other group. Voting may itself be used in the process of defining the issue, voting agenda, vote form and voting profile.
Members of the voting group may be allowed to propose alternative resolutions of the issue, and the voting profile may specify how to handle the case where many alternative proposals have been made.
Access controls may regulate which voting profiles are allowed for particular kinds of votes within particular groups.
The vote form specifies one question or a series of questions. The order of the subquestions may be defined or may be chosen randomly to avoid bias. Various vote profiles may specify which answers are allowed to vote questions. Examples of possible kinds of answers are:
A common process of producing a vote agenda is to split up a complex question into a number of binary choices. Whether this is allowed or not should be specified in the vote profile.
The vote form may allow voters to give motives for their votes in a textual appendix to the vote they have cast.
In a polling process, the responses to a number of related items may be combined to form a "scale".
The opening of a vote is the date/time when voters are allowed to input votes.
A particular kind of vote is a continuous vote. By this is meant that voting is allowed during the whole discussion of an issue, and that a tabulation of the opinions within the group is available at any time during the discussion. Continuous votes are especially useful if consensus (full agreement among all voters except abstainers) is required. Continuous voting may imply a need for changes in the vote issue and agenda during the voting period.
The vote period usually starts with the distribution of the vote form. This form may contain a description of the issue and the agenda, specify the order of the items on the agenda, specify the allowed answers to each item on the agenda and give other information about this particular VP. Users should be told if they may change their votes, if their individual votes will be readable by other people, what security mechanisms are used to protect the votes etc. Users may also be told if they must vote before seeing other votes.
Voters are allowed to cast their votes during the voting period. A voter may, or may not, be allowed to change a vote which has already been cast by that voter. Other voters and observers may or may not be allowed to see each other's votes during and after the voting process.
The voting system may remind voters who have not yet cast their votes to do so at various times during the voting period.
Cast votes can be tabulated, aggregated and analyzed in various ways (such as sums, percentages, means, standard deviations, quartiles etc.). The report may be sent out or be made available to the initiator or to other voters and observers during or after the voting period.
Voting may be secret (no one is told the individual votes). The voting profile may also specify that each voter can choose whether his/her vote is secret or not.
Special security mechanisms may be designed to ensure secret voting.
The voting profile may specify that the vote is to be closed at a certain date/time, or when a minimum number of votes have been cast (quorum) or a combination of these two alternatives.
Security mechanisms can be used to protect both the individual votes and the collective outcome, and to prohibit unauthorized access, including falsified votes. Non-repudiation of individual votes and the collective outcome may also be ensured.
Time-stamping, encryption, digital signatures etc. could be used to provide security. The use of such advanced security mechanisms should however not be mandatory in all voting profiles.
The voting profile describes how a particular VP is to be handled. The standard should contain a number of basic, pre-defined voting profiles, but it should be possible to define and use other profiles than those pre-defined in the standard.
The standard itself should not label various profiles as "good" or "bad". However, an informative annex to the standard might summarize some knowledge from social choice theory on pros and cons of various profiles. One objective of such an annex is to recommend voting profiles which allow voters to input their sincere opinion and not to make it worthwhile to vote tactically. By tactical voting is meant cases where a voter votes contrary to his opinion on sub-questions because this might with certain voting profiles increase the probability of the final outcome desired by this voter. Such an annex can describe risks of misuse of certain voting profiles and risks of and ways of avoiding biased voting agendas.
Pre-defined and/or registered profiles should each be given a unique object identifier.
The voting profile should specify how to handle all cases which in this user requirement specification are described by words such as "may". This may include the following points:
These acknowledgements were not part of the official ISO document.
This document was produced at an ISO/CCITT standards meeting, and the development was aided by input from Arnie Urken, Murray Turoff, Roxanne Hiltz and Shoichiro Seno.