EDemocracy Summary This is a specification. No code have been written (yet). EDemocracy is a tool to assist group communication, negotiation and decision making process. The core is a tree hierarchy of interest groups where issues can be raised, possible solutions be figured out and voted. Issues can be escalated up or handled down in the hierarchy. The process is helped with the proven comnunication methods of the Internet Age. It is basically a web portal (or a set of web portals if you like), where one can get informed about news, form groups, share opinions and anticipated solutions, and vote on them. Officials can be elected, appointed by officials, empowered or called back through the portal. The uninteresting part of rights, which are related to the working of the software can be automatically granted through votes. EDemocracy is useless without the real word. First you need an organisation which is supposed to work in a democratic way (a LUG, a local autonomy or a country). Than you have to match the tree hierarchy in EDemocracy to the real world structure. For example you can say that the leaders of the LUG are elected in the top level group, and they are obliged to fulfill resolutions accepted there. In a greater structure you can match second level groups to departments, and reserve the top level group for the really serious decisions. The other tie to the real world is the digital certificate of every citizen of the portal. Warning Given the current state of art, one should not depend on IT in really serious questions. This system (even when it will be more than a specification:) will not be secure enough in face of allegiations about someone playing with the vote results. (IT without supplementary physical and organisational controls can never give real dependability, and creating even moderately complex IT systems which could do it with the appropriate outside help is out of the reach of the current state of the art. Maybe in ten years, maybe not.) In spite of this I believe that this system would help a lot of organisations in most steps of the decision making process even now. (In a LUG I would do everything through it but the election of the leaders and the really important decisions would be confirmed by real world voting.) Environment Assumptions A1. Democratic management of the real world organisation using the software leads to its best (or least wrong) development. A2. Citizens of the system are able to make informed decisions, able to recognise the lack of information and act upon it. (ie. one can abstain from voting or tick "None of Above" when one or the other is needed.) A3. Citizens' identification is possible to the extent needed by electronic signature (the CA(s) used is good enough). A4. The mapping of the real world offices, roles and responsibilities to the ones of the software leads to a meaningful result. A5. The organisational structure (formal and informal) of the real world organisation can be adequately mapped by a hierarchical tree where some nodes can be made visible under nodes differing from their parent (okay, maybe calling it tree is not too exact). A6. Citizens of the real world organisation can and willing to use the software as an arbitration tool. A7. Citisens are either able to keep focused on the issue or choose a moderator who is able to keep high enough signal/noise ratio in a given debate without blocking points to get through A8. Data needed for informed decision is legally reacheable for all citizens Threats countered T1. Majority opinions are not taken into account T2. Minority opinions are not taken into account T3. Voting method used leads to polarisation T4. Issues are gone through without possibility given to get informed about them T5. Issues got unsolved for too long time T6. Low signal/noise ratio makes issues or viewpoints unintelligible Specification 1. objects in the system citizens: the users of the system. Each citizen is associated with its digital signature and roles in the system groups: Groups are the containers of other objects in the system. Groups can have citizens, roles, rights, issues, news items, wikies and mailing lists. Groups represent (1) groups of the citizens (2) an organisational unit dealing with problems pertaining to that group. There is a tree hierarchy of the groups. Each groups but the root group have one parent. Each group can have one or more children. Group A can adopt group B as its child even if A is not the parent of B. This is to have information on things going on in B, to encounter T4. Members of a group are automatically member of its parent group. Every citizen is the member of the root group. Child groups can be created by the role holding the right to do so (then the right lists the new members of the group) or by including it in a vote alternative (then all who have voted on the alternative will be members of the group(T2)). One can cease to be a member of a group by their own will or by a vote. Groups have attributes which can be set. roles: A role is a set of rights, associated with a citizen, with an optional length of time to take the role. When a group is created, only the "member" and "nomember" roles are defined, according to the parent group's "subgroup_memberrights" and "subgroup_nomemberrights" attributes. The other roles should be defined by a vote and filled by and election. The citizen-role association can be ended by the citizen holding the right, after the time passing, or by a vote. rights: Rights are either access rights handled by the system, or labels which have no meaning within the system, but interpreted in the real world. Every access right can be exercised by the citizens of the group as a whole through voting (T1). issues: Issues are the subjects of voting. The issues can be in the following states: proposed, announced, ready for vote, under vote, dealt with. Every citizen can propose an issue, and explain it. Every one else can second it. If there are enough seconds (enough is a function of the citizen count, given as a group attribute), the issue is announced in the group's news and mailing list. From now on every one can propose a solution. The solution can contain commands to the software, which would be acted upon if the solution will be choosen (with the exception of the group creation command, which will be acted upon after the vote). Every other one can second it. If there are enough seconds (a function of the citizen count, given as a group attribute), it will be a vote alternative. Every one can push the issue for vote. If there are enough pushes (also a function of the citizen count, etc.) The issue will be ready for vote. A vote alternative called "None of the above" will be automatically appended, and it will be announced again, and the issue goes under vote. After a predetermined time (a group attribute again), the vote will be tallied using FIXME Condorcet method used in Debian. The commands in the winner alternative will be executed, and the group creation commands in other alternatives will also be executed. A special case of issue creation is escalation. An escalation appears in the parent of the group which made it, and starts with the announcement in the announced state. Issues which cannot reach the announced state for a given time interval are automatically deleted. Urgent issues go by the same process, but with other attributes. news items: News items are appearing in the web space associated with the group just like with a normal portal. news items can be proposed by any citizen, and if they get enough (see above:) seconds or passed by a citizen having a news editor role, they will be appear there. Issues have their news items automatically in the holding group and all groups which have that group as a child. News editors can edit proposed news. The policies for news edition/acceptance when not enough seconds are beyond the scope of the software. Citizens having the news escalator right can escalate news. Escalated news will appear in all groups which have that group as child. News also can be escalated by enough citizen wanting that while the news is not too long in the group. wikies: All groups can have a wiki. The rights regarding to the wiki are maintained by the software (not strictly necessary). All citizens proposing an issue or a solution automatically gets (FIXME what kind of) right to a wiki page which is automatically referenced from the documents generated by the software regarding the proposal. This wiki page can be used to describe the issue or solution in detail. mailing lists: All group can have mailing lists. An -announce mailing list distributes all the news items, and it is automatically run. Other mailing lists may be created to facilitate discussions (normally one for the citizens, but maybe more for e.g. unmoderated discussions, or the officials, or archivals, etc). The rights related to the mailing lists are also maintained by the software (not strictly necessary). 2. commands and activities 2.1 commands These commands can either be mailed by a signed letter (or through the webpage), or included in a vote alternative. rights needed are noted. Add CA . addcacert Create citizen [with certificate] [with attributes] [=]*. create_citizen Add ([citizen] |myself) to group . addcitizen | register In [group] create group [with description] [with members] . creategroup In [group] resign ([from role] |from membership). In [group] adopt [group] . adoptgroup In [group] set to . setattribute[:] In [group] create role [with description] [with rights] . createrole In [group] appoint [to role] . appoint[:] In [group] call back [from role] . callback[:] In [group] propose [urgent] issue [with description] . propose_issue[:urgent] In [group] second issue . second_issue[:urgent] In [group] push issue for vote. push_issue[:urgent] In [group] escalate issue ([with description] ). escalate_issue[:urgent] In [group] propose solution [with description] . propose_solution In [group] second solution . second_solution In [group] propose news [with description] [with long story> ]. propose_news In [group] second news . second_news In [group] escalate news . escalate_news 2.2 other activities There are other not command oriented activities. Needed rights are noted. voting: the user gets a vote sheet which should be filled, signed and sent back voter editing and administering wiki pages FIXME using and moderating mailing lists mailuser[:] mailadmin[:] reading group home reader 3. group attributes subgroup_memberrights: a list of rights for members of the group subgroup_nomemberright: a list of rights for those citizens who are not members of the group member_attributes: a tuple with required and optional member attributes. only consulted in the root group. issue_seconds_needed: a function of the group citizen's number issue_pushes_needed: a function of the group citizen's number issue_vote_time: number of days issue_timeout: number of days issue_urgent_seconds_needed: a function of the group citizen's number issue_urgent_pushes_needed: a function of the group citizen's number issue_urgent_vote_time: number of days issue_urgent_timeout: number of days issue_wiki_url_template: function of the issue id issue_alternative_wiki_url_template: function of the issue and the alternative id news_seconds_needed: number of days news_escalations_needed: number of days news_escalate_timeout: number of days 4. architectural hints These thoughts are only hints, because it is just a functional specification. The vote tallying and signature check module should be well-separated from the other parts. This way the integrity of the core might be maintained. The digital signature used is a big question. x509v3 makes it easier to create trusted web application, but the trust relationship of pgp makes it much more appropriate for a community resource like this. This is why commanding the software is anticipated with digitally signed emails. If nomembers get reader right, it means that only the mailing list administration and the private wiki pages need authentication in the web side. Of course the needed emails can be triggered with mailto: url's to make the web site more comprehensively useable. Or the equivalents of commands can be programmed into web forms if one is happy with x509v3 certs (which I am not in a community application). Or the problem can be mitigated with a CA issuing x509v4 certs for pgp keys, or solved by a browser and a web server which can use pgp keys for authentication. The rights should be maintained in an LDAP, making integration with other applications easier. Representation of rights in ldap can be made in some ways, maybe OrganisationalUnits for groups and OrganisationalRoles for roles are useable. Maybe examples of other applications would be the wiki and the mailing list manager themselves. To make it scaleable, it might be worthwile to be able to put each groups in different servers should it be needed. I would use the Zope framework to create such a software. It is clear that such a software can only be open source.