MeatballWiki | RecentChanges | Random Page | Indices | Categories
[EditThisPage] , Contents  , ...
This page is intended as a meeting place for people interested in adding voting systems to wiki. What kind of collaboration is possible? Please state your interest. Please add you thoughts and suggestions. There are many problems. Become part of a think tank to solve them.
- It may help to break this page down into just the Collaboration aspects and move some the rest of the content into VotingSystemDiscussion or even a new page such as VotingSystemsTheory?.
Interested in collaboration:
With related, signed contributions by: SunirShah, MattisManzel, BayleShanks, ...
- HansWobbe (Who is not expert on Voting, but is prepared to learn as much as possible while participating in this enterprise.)
A Table Of Contents  exists to help focus the current efforts and to help navigate the accumulating content.
Fundamentally, an Election is one of many possible solutions to the need to make a decision that affects a group. Since this particular approach to decision-making generally tries to balance or blend the the concepts of Leadership versus Representation, to various different degrees, it becomes necessary to define the procedures that will be used to conduct an election, as well as to define who has the RightToVote. This is generally the responsibility of a 'non-partisan' ElectoralAuthority? (in the case of governments) or (in the case of a corporation) is predefined in its By-Laws, before 'ownership' is extended to a large enough group to become problematic.
In both cases of a government and of a corporation, the rules that become part of a Voting System are still subject to the other "laws of the land" that may apply in their operating jusidictions, or to any Contractual Obligations that the parties have agreed to and that can be effectively enforced. In essence, for a Vote to be a binding decision-making process that grants a legitimate right to act on behalf of the Group, it needs to be viewed as an enforceable Contract, defining Authorized actions by specified individuals, on behalf of the Group as a whole, and its participants.
- Not only does this sound daunting as I write it, it also seems contray to the OpenCommunity spirit that exists in prominent Wikis. It may, however, be an inescapable conclusion. At the very least, it should be noted that this discussion of Voting Systems is taking place "WITHOUT PREJUDICE" ''(as lawyers say), and that it is in no way related to the operation of this meatball community.
... equivocated elections and voting ... removed to VotingSystemDiscussion
- 1. 
- 1.1. Contents
3. An Initial Approach
- 2.1. Voting "may" be a form of decision making.
- 2.2. Preamble
4. Objectives of the proposed system(s)
- 3.1. Existing meatball pages related to Voting.
- 3.2. Significant considerations & Issues.
- 3.3. Features and their relative importance.
- 3.4. A Wiki Voting Farm implementation strategy.
- 3.5. Proposed testing of Trust mechanisms
- 4.1. The initial focus is Voting within Wiki Communities.
- 4.2. A solid foundation should support additional uses.
6. Current focus
- 5.1. Glossary.
5.2. Related deliberations
- 5.1.1. Democracy
- 5.1.2. plebicite
- 5.2.1. Online Deliberation Conference
- 6.1. List(s) of system elements
- 6.2. System elements details
- 6.2.1. Confirmation of Voting Member status.
- 6.2.2. Considerations regarding the use of "split keys":
2.1. Voting "may" be a form of decision making.
| It is important to have a clear understanding of the purpose of Voting, in order to collaborate on building Voting Systems. |
Here at meatball, there are many pages containing 'bread crumbs' of insights and ideas that both support various perspectives related to Voting and that suggest various alternatives. It would be quite helpful to have a comprehensive summary of the reasons for Voting.
This Preamble provides some of the background leading up to the creating of this page.
Are you actually building a voting system?
- This is an area of considerable interest to a couple of groups I associate with, so I am interested in trying to find 'synergies'. -- HansWobbe.
It hasn't top priority, but - yes - I'm working to extend wiki to handle (e.g. democratic decision) processes. Voting is only a part of that. -- HelmutLeitner
- I absolutely understand and agree that Voting is just a part of the process. I have been taking the approach that there are some existing mechanisms that could be considered (such as Petitions, for example). I have also been spending quite a bit of time on 'governance' issues, especially as they relate to the current North American business scene. By the way, the members of a corporate Board of Directors are elected and the existing Proxy approach and cronyism that have plagued Boards is a very 'hot' topic over here. Is there any material about what you are thinking yet that I could review in order to ensure that I can help (rather than hinder), or would you prefer to work independantly? -- HansWobbe.
No, I'd really like to cooperate. How would you like to cooperate? Theoretical discussion and design? Implementation issues? A real application where this is put to use? -- HelmutLeitner
- Good! I too would like to cooperate.
I'm not sure just yet how to proceed and may need about a week to ponder this. Since I have been somewhat involved with any number of groups that are interested in various facets of voting, I think I should take the next few days to poll various interested parties that I know (and that I respect) to see what their interests are and what their level of activity is. This should help in deciding what could and should be done. Then I should be able to decide how I can best contribute to a co-operative effort, and start to define the appropriate boundary conditions for the scope of the undertaking. I suspect one of the reasons that I am being a bit 'methodical' at this early stage, is that I believe this may be a very important Enterprise and I want to ensure I avoid acting like a Wiki:WikiPuppy. After a bit of thought I suggest TrustedVirtualVoting? as a page that can be used, if only to avoid diverting this one's purpose. Since I am open to other suggestions, I did not simply create it. Feel free to agreee by doing so or disagree by simply moving this text elsewhere. -- HansWobbe
This is interesting. Voting sliders in text, whereever they might work. -- MattisManzel
Ok, take any time you need. Maybe consider my position as a developer: I do not want to attach a voting system to wiki, but extend wiki in a general way, so that a democratic process can be configured within wiki pages by normal wiki users (admins, members, depending on the configuration). The configuration part is - because of WikiFractality and WikiVirtualData within ProWiki - a solved problem, just work, although language elements must be invented to configure the processes. One will need a time-aware state engine, maybe a CronWiki? script, that changes the state and the place of pages representing the democratic process - that's something I haven't yet in my mind. The points are an orthogonal design, an efficient implementation and seamless wiki integration of this general state engine. Once this exists, users should be able to configure this in a hundred different ways to develop the democratic, social or technical processes (e. g. automatic news publishing) they need. The more complex but real and pressing needs can be put into the pot, the easier will it be to find the right solution to the problem. Pure voting wouldn't do. This is my overall picture of the situation. -- HelmutLeitner
Helmut: I have a couple of initial questions:
- in your view, is the democratic process limited to politcal organizations or does it also encompass corporate governance issues? One fundamental difference that I see between these is evident in the 'one individual, one vote' versus 'one share, one vote' approach.
- Are there any aspects of the RightToVote that you are particularly interested in? I have had to struggle with the realization that in Canada we have three levels of governemnt and that the qualifications to vote are an inverted pyramid (i.e. there are stricter qualifcations to vote in a Municipal election than in a Provincial one, which is in turn more stringent than a Federal one.) While this is at least theoretically related to the jurisdiction's RightToTax?, the fundamental relationship between Taxaxtion and Representation is under serious attack as our ecomonies shift from Real Asset custody systems to an Information & Services based value system, and as our elected Representatives fall further behind in understanding the impacts of the dramatically improveed communications that are now a part of our world.
I have also been quite bedeviled by the issues of the Canadian CharterOfRights? and those inherent in a corporate Shareholders Agreement and the related By-Laws under which at least publically traded organizations must operate. If you have any initial thoughts on these, I'd be pleased to try to factor tose considerations into my thinking as well.
I would like to separate the technical issues from the social issues. In this context my use of "democratic process" was not a good choice, let's better use "decision process". Part of the decision process is voting (there can be more than one votings at different stages of a single decision process, e. g. "do we delegate the decision or do we want to vote?" and "do we agree that we have completed the discussion and heard all arguments?" and "do we agree on the wording of the voting alternatives?" and "final voting"). With any voting go the questions: "who may vote" and "how is the result of the voting calculated". Votes may have equal weight, but they might also have arbitrary weights according to shares or trust metrics. For the software this is just a factor in an equation, so why should a developer bother? A certain decision may need 50%+1vote or 66% or 100% consensus. One could have different classes of voters: in an online community one could count authenticated member votes and anonymous votes separatedly and make a decision valid only if both partitions of the community agree. There are thousands of different ways to construct a decision process. Only time will tell what will work. So I think if we design a specific decision process (instead of making it configurable) we are bound to fail.
Sorry for being so long, the short answer is: I don't know Canadian law and specific needs, but a wiki voting system is IMHO only finished if you are able to freely design and configure any process on demand.
Transparency is an issues (how does this process develop). Voting during discussion? May I change my vote? Open or secret voting? Handling of vetos? How much time for voting? What if a majority is already given before end time (faster voting)? Voting in stages (dropping alternatives with least votes)? Logging of all events. Voting only together with reasoning? Quality control if we have a chance to prove decisions right or wrong (voting on predictions)? Repeat a voting after some time? ... There are dozens of issues and millions of combinations. We are just at the beginning of designing new forms of democracy and participation (e. g. solve the problem of minorities in societies). We need a toolset and a language for that. -- HelmutLeitner
It may be better to start with a Corporate model rather than a Government model since there are more instances we can use and they are more modern. Furthemore, corporate examples may be more applicable since ultimately, abiding by a communities charter may be subject to a legal challenge, and Courts have shown themselves to be capable of interpreting and enforcing 'commercial' contracts, much more easily than they can address Soverign ones.
Examples that may be most applicaple to what we are familar with at meatball and hence may be easier to start with include:
- Co-operatives (In the US a significant undertaking is Mountain Equipment Co-Op, which suppliers its "member - owners" with recreational eqipment).
- Credit Unions which are also owned by their members should also be a source of pertinent insights.
I will also give some thought to how we might be able to structure some of the options that you have listed in a way that we can extend into the many possible combinations I see emerging from your comments so far. Again, in this case, corporate Charters and By-Laws should provide a considerable set of insights that are worth considering, and that may even provide some templates we can use.
By the way, since you mentioned...
- ...designing new forms of democracy and participation (e. g. solve the problem of minorities in societies)
... have you considered that Democracy and Minority Rights may well be at odds with each other. After all, a binding majority vote and its resulting decision may well be at the expense of a minority. (I've actually just finished re-reading the UN's Universal Declartion of Human Rights as a result of pondering this.)
Yes, that was the point I wanted to make about minorities. In a state their could be an additional minority "chamber" where the majority is put into a 30% minority position, or an USA-like state could give minorities state-status in the senate (adding 2 extra representatives for "blacks", "jews", "females", "poor", "large families", "handicapped", "old", ... whatever ), so they become better represented. In eastern European or African states democracy often stops working because of strong ethnic groups, tribes or religious groups dominating over normal policial interests. A realname voting community (a future GründerWiki or MeatballWiki) could, for example, give representatives of anonymous contributors the right to vote, which would normally be impossible. -- HelmutLeitner
I am certainly enjoying this page, even while I am amazed each day at how many more aspects of this emerge and at the effort it takes to avoid desparing of the possible scope of this whole thing. I'm going to try a very little experiment by just listing quick bullets that occur to me as I deal with this. Hopefully, seeing them accumulate, it will then be possible to compare and rank them somehow. If you prefer I do this off-line, just say so and I'll remove this.
- ... minority "chamber" ...
- The Role of Cabinet as opposed to the full House (of Representatives)
- Effectiveness of decision making declines as a function of the number of participants.
- ... give minorities state-status ...
- there are situations and jurisdictions in which minorities actually have more rights than the members of the majority.
- Currently, it is my opinion that this tends to cause more problems than it solves, especially in the long-term, but my opinion is based on casual observations that are not the result of a careful review and deliberation. I will have to do a lot more before I am prepaqred to assert this assumption as an opinion.
- ... representatives of anonymous contributors the right to vote ...
- I think that the US Electoral College may be an instance of this idea.
- And I fear that this type of Anonymity will be implemented with many similarities to the current 'self -serving' polls that are undertaken.
- I am quite firm in my opinion that it is a responsibility of my elected Representative to represent my views as a member of his Constituency. At the very least, the representative should be obligated to summarize, present and act on the views of all of his Constituents in an effective manner. I believe that one of North America's major problems is that voting on Party lines, especially if only to retain (or gain) power, really does mock the Democratic process.
Sorry that I added seemingly endless complexities to the simple idea of voting. It's not to make systems more complex, but to make a sufficient implementation much simpler and faster.
- There is no need what-so-ever to say "Sorry".
- Voting appears simply to the casual observer in the same way that a tree does, to someone not familiar with the micro intricacies of photosynthesis, osmosis, etc.; not the macro intricacies of forestry.
- I believe that a 'configurable' solution will have to handle many complexities and that the extra effort to generalize this is attractive given the potential benefits.
Have you made your mind up about our cooperation? We havn't really talked about who might do what, what our interests are, what to put in and get out of such a project. Whether to do it in the open, here or elsewhere, or develop at some backstage and come back when a resulting system can be shown? Whether to do it as a community project or sell development, access or results to interested organizations. -- HelmutLeitner
- I definetly wish to cooperate.
- One reason that I remain a bit cautious is that this could become an 'all consuming' exercise for me and I cannot afford that, since I still have other responsibilities. I do not wish to make assertions about what I can do, until I have a clearer idea of what I can offer and that my offer is adequately attractive to justify my participation. Ideally, I would like to work on those aspects to which I can contribute more effectively than any other participant. If we all do that, progress will happen in an enjoyable way.
- I do think that we may have to 'modularize' this undertaking, if only to be able to deliver something and learn from the experiences of the users of our solution.
- ... Whether to do it open, here ...
- I prefer to work in the Open to the extent possible. After all, we may attact orthers that wish to participate, especially since there seems to be a great deal of interest in the Subject at this time. Wikis are, however, only one communication medium, and Meatball is jus one instance of a wiki.
- If our results have commercial value, then we may need to consider more private sites.
- If we use other sites that do not have an active community that contributes to their maintenance (spam fighting, etc) , then we will definetly need to protect our efforts with more appropriate defences. I believe that your ProWiki software supports ACLs; I too have a good set of resourcs that include Secure, Private, Semi-private and Public access to a number of different software applications including Wikis, PhpBb? bulletin boards, etc. In short, I do not think we are 'constrained' to any one way of collaborating technically. -- HansWobbe
Hans, none of us has taken obligations, we are cooperating in the WikiNow. Of course we could change that, for example when someone needs results in time. But we can also just continue the way it is. If you accept ProWiki as a test system, I could set up a wiki for development and testing, during the next 3-4 weeks, maybe called DecisionWiki?. Then we can look how things develop. Usually when a system comes into existance, it starts moving and gets a momentum of its own. Want to try? No obligations? -- HelmutLeitner
Helmut: I would be most pleased to. And I would be delighted to use ProWiki, especially since I have been wanting to try to use it for quite a while but, until now, I have always had to focus on a few other priorities that have kept me away from just learning about software. -- HansWobbe
Hans, ok, then let's do it that way. I'll prepare the wiki, but don't expect any real development to have happened when I open it in February. I'll just prepare some tools, so that I'll be able to develop according to the demand. In the meantime it would be good to continue the discussion. Maybe you take the lead with your immediate needs. What should a system do, to be useful to you? -- HelmutLeitner
3. An Initial Approach
I think the approach that that I should take to defining 'immediate needs' is to start by:
- listing some of the issues that are already documented in various existing Meatbell Pages as well as a few other sources that I am familiar with. In 'refactoring' this information, I will strive to identify those capabilities of a voting system that are commonly accepted as being necessary to fix some of the obvious problems, evident in current systems or that appear to be needed in a next generation of systems.
- listing the Issues that are most significant, either in the view of their Advocates, or in the view of their Opponents.
- attempting to classify the emerging requirements in a way that supports the development of solutions, over time, via a development release schedule that can be used to manage expectations in a realistic and credible manner.
I am quite certain that this approach will change as we get going, and I won't mind that in the least, since I prefer to learn more about all of this as we work away at it. In the mean time, it should be a valid initial approach. -- HansWobbe
3.1. Existing meatball pages related to Voting.
Contributions to this list are more than welcome.
3.2. Significant considerations & Issues.
- Voting for Governments versus Voting for Governance. There are likely to be very different requirements for Voting to elect a Representative to one of the three traditional levels of governement (Municipal, Provincial & Federal) than there are in voting for the Directors of a publically-traded company. Yet another case that should be considered is the 'Co-Operative', a not-for-profit association that works to achieve an advantage for its members (e.g. Mountain Equipment Co-op, a Credit Union, the Canadian Wheat Board, ...). Finally, since many of our concerns relate specifically to on-line communities, we should at least consider (any) differences between these and other 'organizations'.
- Voting administration:
- Anonymous ballots
- WikiPrivacy - secret ballots reduce corruption pressures
- Can the casting of the ballot, its counting and the resulting announcement be audited?
- Certificates as Vote 'proxies'
- Just a quick place holder & reminder to incorporate some of the lessons learned in the last two weeks, this weekend.
- Taxation (Income re-distribution) & Representation
- 'Owernership' of the collective's assets.
- Elected Mandate, Referendums, ...
- Minutes of Representatives meetings, Disclosure, Secrecy, ...
- Right to Recall
- BackRoomDecision, Transparency,
- Group decision making versus Leadership
- Authority (to act), (within defined discretion).
- TheIndividual (a minority of One) versus the SilentMajority
- Remedies (rights of redress in the event of 'breach' of 'contract').
- Founders, Administrators, Voting Members, non-voting members,
- TrustedCustody? of Assets
3.3. Features and their relative importance.
- Fundamental functional needs:
- The ability to frame a choice (Question) and communicate it adequately (perceived fairness).
- The ability to confirm eligibility to Vote.
- The ability to count the ballots that are cast in a reliable manner.
These aspects may be of secondary importance:
- "Casting" a ballot, counting ballots effectively & efficiently, and 'auditing' these procedures.
- Voting types
- Decision process types
- Decision types
3.4. A Wiki Voting Farm implementation strategy.
Introducing a new Voting System will, inevitably, be a traumatic undertaking, judging from the amount of associated rhetoric that exists. One way of facilitating the introduction may be to create a Voting System that is modular to the extent that it can be used for a 'single purpose' vote. Ideally, this would allow a Community to 'hold' a vote on a specific Topic, without having to first deal with all of the many fundamental related issues.
A Wiki Voting Farm implementation strategy might be within our capabilities.
On the basis of what little I know of the fractal wiki concepts at this
time, it might well be possible for us to develop a Wiki Voting Farm,
that eventually provides a superset of all possible required functions.
- This is consistent with our stated objectives of at least understanding Voting and its related issues in the broadest possible terms.
- In providing such a central facility, we could make it available to various communities that might wish to hold a single Vote without the redundant expense of developing their own comprehensive, robust systems and infrastructure. This would be consistent with meatball's 'barn raising' mission, as I understand it.
- This could also allow the evolutionary growth of a BootstrapConstitution since Communities could use such a facility to hold an initial [plebicite].
- "Trusted" party and "Split Key" Cerificates could be managed to provide reliable, secure tokens for a vote.
3.5. Proposed testing of Trust mechanisms
Initial outline, in point form.
One of the recognized, major problems of the online world is confirming the identity of an individual.
- PKI (PublicKeyInfrastructure) based approaches seem to be a theoretically correct approach, but also appear to be sufficiently complicated (at least in the 'general' case) that their adoption is rare.
- They do, however, seem to be relatively easy to implement in 'limited' domains.
- The process of creating a 'Certificate' is a relatively trivial undertaking that seems to be freely supported in a many technologies. (Microsoft's standard capability is being tested and found to quite acceptable, technically.)
- The problem, then, is to be able to 'Trust' the 'Authority' that issues the Certificate.
- In a limited environment (Use or Scope), this may be achieved quite simply.
People are quite capable of 'recognizing' other people.
- Everyone is generally capable of recognizing someone they have seen (even just in a picture).
- People can recognize a vast number of other individuals, based entirely on their Voice Recognition capabilities, as is evident in the use of telephones.
People even actively decide on an appropriate level of Trust.
- Trust depends on a subjective assessment of the Risk / Reward ratio for any particular transaction.
- Trust 'grows' over time since:
- People learn more about the nature of the Individuals they interact with and form better models of 'expected' behaviour.
As a test, it may make sense to create a Public / Private key for an individual that wishes to identify themselves.
- I have asked two 'Officers' of my Company (which has a Certificate issued by Verisign) to participate in a process that creates a Certificate for me, derived from the Company's Certificate.
- In Banking, as in most other environments, the test of a stringent system is that collusion between two individuals is needed to compromise a system, in order for it to be deemed to be secure.
- As 'pruduent' individuals, these Officers will undoubtedly wish to document at least the degree of their Certainty, the Scope of their Intentions and any related 'Warantees' they may be able to offer.
- I am now in a position to use the 'public' part of this Certificate to identify myself relatively trivially.
4. Objectives of the proposed system(s)
4.1. The initial focus is Voting within Wiki Communities.
- Consistent with the MeatballMission and the fact that this is a Wiki Community, the design of the proposed systems will be focused on:
- On-Line communities,
- Wiki technologies,
4.2. A solid foundation should support additional uses.
- To strive to meet as broad and diverse a set of needs as efficiently possible.
- It should at least be possible to use the system in On-Line Communities, especially wikis.
- Ideally, it will be possible to use the system for additional Groups, such as:
- Semi-Private meetings of a Board or Directors.
- Annual meetings of a General Membership such as an Assocation or a Corporation.
- Opinion Polls
- Government elections are likely to be outside of our achievable scope, at any of the three levels of government.
In this special case of a wiki, this Appendix section is the 'penultimate' (second last), rather than 'final, section.
This is consistent with the common practice of many wiki users to append their most recent chanages to the end of the page.
The use of headings will generate enteries in the Contents as the terms are defined.
- noun (pl. democracies) 1 a form of government in which the people have a voice in the exercise of power, typically through elected representatives. 2 a state governed in such a way. 3 control of a group by the majority of its members.
- - ORIGIN Greek demokratia, from demos ‘the people’ + -kratia ‘power, rule’.
- This definintion (one of a great many that are available) is from the Oxford dictionary. It was picked on the assumption that a definition from a non-American source might provided a broader perspective.
- A referendum (plural: referendums or referenda) or plebiscite is a direct vote in which an entire electorate is asked to either accept or reject a particular proposal. This may be the adoption of a new constitution, a constitutional amendment, a law, the recall of an elected official or simply a specific government policy. (continued [Referendum] at Wikipedia)
5.2. Related deliberations
5.2.1. Online Deliberation Conference
This would be a great thing to discuss at the upcoming [OnlineDeliberationConference], if anyone here is going. I'm thinking about proposing a workshop topic of some sort -- lemme know if you're going and you'd like to talk about this there.
There is little about the programme. One day for "local networking" seems to make it a kind of insider event. Do you think they would appreciate what wikzens do here at MeatballWiki and elsewhere, be interested in general wiki issues? -- HelmutLeitner
The stuff wikizens do here is definitely on topic for the conference. Also, it is certainly not trying to be an insider event. The day for local networking is simply because many of the people at Stanford University who research this sort of thing haven't really met each other and interacted much. So they figured that this would be a good excuse to present their stuff to one another, and that if they make it temporally contiguous with the conference (i.e. the afternoon before the conference really starts), then maybe some people from elsewhere would like to drop in too. The rest of the conference is not supposed to be about that, though.
This conference is a followup to the 2003 conference "Developing and Using Online Tools for Deliberative Democracy". I went to that one, and a lot of the stuff we discussed were exactly the type of thing that gets discussed on MeatballWiki (particularly in the "sociology of group deliberation" discussion group that I attended). There was a lot of talk about the dynamics of group discussions, and about how discussions can be facilitated by humans (there were some professional group facilitators there at the conference, with interesting stories), and about how to design software so as to promote good group dynamics.
I kept wanting to jump out of my chair and tell people to go read this or that page on meatball. Happily, I think I managed to restrain myself and just quietly suggest once or twice that MeatballWiki may be of interest to others. Anyway, I think that there is a very large correlation between what is on-topic for MeatballWiki and what is on-topic for the upcoming conference.
In addition, I told the organizer that I'm thinking of proposing a workshop (small discussion group) with a topic related to wikis, and he said he thought that would be a great idea. Wikis are also an item in the list of "topics of interest" at the conference website.
For more details on what is on-topic at this conference, there is a very long and detailed discussion on the [overview] page at the conference website; there is another short summary that I wrote at the [CommunityWiki blog]; and you could take a look at some [notes by me and some other people] from the 2003 conference.
Then maybe some of us should go there, talking about MeatballWiki views. The stuff on this page probably won't create results until May, but a "Wiki and Democracy" paper, talk or workshop might be interesting. -- HelmutLeitner
I am sufficiently interested in this subject that I would attend, but unfortunately, I have a conflict, needing to be in Washington DC at that time. Is this likely to be an annual event, occuring at the same time? -- HansWobbe
Helmut: Yes, that's along the lines I was thinking. What do you think of the "extreme decentralization" workshop idea at http://communitywiki.org/cw?OnlineDeliberationConference? Since I dunno how many wiki people will actually attend, that includes wiki stuff and non-wiki stuff. I'd be down for a purely wiki workshop if there is enough interest, though. Workshop proposals are due March 15.
Hans: The plan is definitely to make it a recurring conference, I don't know if people are thinking annual or bi or triannual. But this is only the second iteration, so we'll see if it "takes". Personally, I give it about 80% odds of continuing at least binannually. I don't know if it'll stay at the same time every year though.
6. Current focus
This 'Current Focus segment of this file may be relocated as the structure of this page changes. For the moment, its location at the end of this file supports convenient editing.
6.1. List(s) of system elements
Planned elements of the systems (implementation detail):
- voting process configuration -- all actions that influence processes of voting
- Schedule -- when the various component activities will take place and their durations.
- access conditions
- who - has the RightToVote (Voting Members)
- Most types of Votes have criteria that must be met by Voting Members. Some examples include:
- tenure (must have been a member of the Group for at least some minimal period, or as of a certain date)
- Are Voting Members identified publically? Will (or should) this lead to 'lobbying'?
- page -- where the voting is located
- dialog -- selections of alternatives
- result calculation
- voting process log -- logs all configuration (admin) actions and all system actions (start, stop, results)
- voting dialog -- what is presented to the user (configurable)
- voting progess information -- (optional) information about the ongoing process
- voting event -- a user gives his vote
- voting event log -- contains all voting events (by users) for a single voting process, maybe subpage of voting page
- voting result -- raw material of voting according to the log
- Validation procedures
- Can the ballots that were cast be Auditied or Authenticated?
- Proof that each voting member voted only once and with the correct weight.
- The 'weight' concept is common in Company votes that are based on ownership Shares. (We should confirm if our scope includes Companies or if we prefer to focus strictly on On-Line Communitiers.)
- This will require some type of Log-In that is restricted so that the Vote is not tainted by the ballots of non Voting Members.
- voting decision -- calculated depending on the result
- voting decision execution -- if the system is able to do so, maybe only publishing the result
- community decision page -- maybe a locked page containing the automatic digest of all decision processes
- Over time, this will tend to evolve into a Charter or Constitution or a set of governing By-Laws via BootstrapConstitution.
- form design wiki markup -- so that voting dialogs can be written
- cronwiki script -- the agent that works on the time-line, independent from the user events (maybe a general process controll system)
- cronwiki language -- configuration of what cronwiki is expected to do
- low-level-voting interface -- e. g. "action=vote&id=pagename&value=yes"
6.2. System elements details
Each of the entries in the preceding list of system elements needs to be expanded.
6.2.1. Confirmation of Voting Member status.
A theoretically rigorous identification system can be based on the use of Certifictes, IFF (if and only if):
- An "Electoral Authority" is recognized as having the ability to objectvely define the eligibility criteria and to confirm that only those individuals are actually casting ballots.
- Recent preliminary reviews of existing Certifiate technologies suggest that:
- A full Public Key Infrastructure is still considered by many to be relatively complicated.
- Limited implementations can, however, be simplified significantly and are probably at least a step in a theoretically correct direction.
- The notional Authority could issue a Certificate, to each eligible Voter, derived from the Authorities Public key and a unique Vote number for each ballot, for use in a particular Vote.
- A Voter's identity could be confirmed independantly, in advance of Voting, by at least two Trusted entities (creating the need for collaboration, to 'beat' the system).
- Ideally, such a system will:
- Allow only Eligible participants to Vote.
- Provide a secure Audit log that can be used by all parties to confirm the process worked, while still maintaining the Privacy (secrecy) of the Voters identity.
- An independant (of the Electoral Authority) process exists for confirming the identity of individuals and such individuals are fully aware of the need to protect their Certificate(s). By separating the responsibilities of the Electoral Authority and the Trusted Authority that issues a Certificate (of identification) the system can be made secure against most forms of attack, up to the point at which collusion between two of three independant parties occures.
6.2.2. Considerations regarding the use of "split keys":
The fundamental concept of a split key is that two (or more) individuals must collaborate in order to complete a specific Task. Ideally, these Individuals will be "at Arms Length" (i.e. not have a vested interest in 'colluding').
In its simplest possible form (for the purpose of Voting) several Roles must interact appropriately.
- There needs to be an "Electoral Authority", a non-partisan role that sets the rules for the vote and confirms that they have been applied fairly.
- An important aspect of this role is defining Eligibility To Vote.
- Each of the 'factions' (sub groups with dissenting opinions, political parties, etc., ...) must have at least two Representatives involved in 'scrutineering' the process.
- The actual Voters.
Considering the use of PKI in these three roles:
The Voter could cast a ballot, supported by the combination of the Individual's and the Authorities' public Key.
- The Electoral Authority could confirm that an Individual is eligibe to Vote by using the public portio of their Key to validate the public portion of a Voter's key.
- The Scrutineers, as well as the Voter and the Authority, could count and Audit the Votes, with or without being able to identify the Voter, depending on whether or not the Vote is a secret ballot, by simply reviewing the composite Public key segments.