{"id":261,"date":"2004-08-22T19:44:38","date_gmt":"2004-08-22T09:44:38","guid":{"rendered":"http:\/\/www.flamingspork.com\/blog\/?p=261"},"modified":"2013-10-04T09:27:00","modified_gmt":"2013-10-03T23:27:00","slug":"memberdb-voting-code-planning-in-some-sense-of-the-word","status":"publish","type":"post","link":"https:\/\/www.flamingspork.com\/blog\/2004\/08\/22\/memberdb-voting-code-planning-in-some-sense-of-the-word\/","title":{"rendered":"MemberDB Voting code (planning… in some sense of the word)"},"content":{"rendered":"

well… at some point there has to be some voting code done for MemberDB<\/a>. Namely because Linux Australia<\/a> has to have elections sometime early next year, and the code really should work before then!<\/p>\n

Currently, we can easily work out who is a current member of the organisation. Only current members, with the appropriate type of membership should be able to vote. Initially, we will assume that if member_types.validates_membership=true and member_types.revokes_membership=false, they are able to vote (i.e. if they show up in the current_memberships view).<\/p>\n

This means they can log in. This is a good thing (note, a member may have to reset their password first – this is supported in latest MemberDB snapshots).<\/p>\n

Once logged in, the member should be able to see a list of elections they can currently participate in. Elections (election table?) should be tied to organisation and a time period. They should also have a name and description. Only the election_id should be unique.<\/p>\n

e.g., something like:<\/p>\n

\r\ncreate table election (\r\n        id serial unique not null,\r\n        org_id int not null,  -- election for this org (NULL=all orgs)\r\n        name varchar(50) not null,\r\n        start_advertising date, -- date that we'll display in a UI that \"an election is coming\"\r\n        nominations_start date,\r\n        nominations_close date,\r\n        advertise_candidates date, -- list the candidates from date onwards\r\n        live_results boolean, -- results in real-time\r\n        start_voting date, -- when voting opens\r\n        close_voting date, -- when it closes\r\n        show_results date, -- show results from election from this date onwards (NULL=never). This field can be updated (i.e. after the results have been verified\/approved)\r\n        description text,\r\n        CONSTRAINT \"election_pkey\" PRIMARY KEY (id),\r\n        CONSTRAINT \"election_org_id_fkey\" FOREIGN KEY (org_id) references orgs(id) on update restrict\r\n);<\/pre>\n
In the future, we may want to support more than one election type – this should be safe to introduce in the future as we can add a column to election and election_vote. Currently, we’re only going to care about “first past the post” style elections. i.e. the classic “a show of hands”.<\/p>\n
Only authorised people should be able to change any details of the election – this should be a new activity, and members granted explicit permissions to do this. We will probably need to add a “data” field to the permissions table – allowing us to have more specialised permissions (i.e. only membey X can modify election Y, and only member A can modify election B).<\/p>\n
We need positions to elect people into.
\ne.g.<\/p>\n
\r\ncreate table election_position (\r\n id serial unique not null,\r\n election_id int not null,\r\n name varchar(50) not null,\r\n description text,\r\n-- FIXME: insert constraints here\r\n);\r\n<\/pre>\n
Each election needs candidates. Candidates need to be approved (by whoever can modify the election. Since the process for approving candidates can vary, this will require human thinking logic to work out that everything is okay before they click the “approve” button).<\/p>\n
something like:<\/p>\n
\r\ncreate table election_candidate (\r\n     id serial unique not null,\r\n     election_position_id int not null,\r\n     approved boolean,\r\n     member_id int not null,\r\n     spiel text,\r\n        CONSTRAINT \"election_candidate_pkey\" PRIMARY KEY (id),\r\n        CONSTRAINT \"election_candidate_election_position_id_fkey\" FOREIGN KEY (org_id) references election_position(id) on update restrict,\r\n      CONSTRAINT \"election_candidate_member_id\" FOREIGN KEY (member-id) references current_memberships(id)\r\n -- FIXME: need constraint that member is a member of the correct org.\r\n );\r\n<\/pre>\n
We’re currently making the assumption that only members can go for positions. This seems fair and reasonable – am open to arguments against it though.<\/p>\n
So, an election has positions and each position has candidates. Candidates have spiels, and have to be approved before they’re listed.<\/p>\n
Each member gets one vote per election position. They can change this anytime up until the closing date (this should take care of the “oh shit, someone dropped out of the election” thing too).<\/p>\n
\r\ncreate table election_vote (\r\n    election_position_id int not null,\r\n    member_id int not null,\r\n    election_candidate_id int not null\r\n-- FIXME: constraints here\r\n);\r\n<\/pre>\n
now… all that needs to be done is a UI… and some sanity checking of the above. :)<\/p>\n","protected":false},"excerpt":{"rendered":"
well… at some point there has to be some voting code done for MemberDB. Namely because Linux Australia has to have elections sometime early next year, and the code really should work before then! Currently, we can easily work out … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[6,13],"tags":[],"class_list":["post-261","post","type-post","status-publish","format-standard","hentry","category-linux-aus","category-memberdb"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p5a6n8-4d","jetpack-related-posts":[{"id":295,"url":"https:\/\/www.flamingspork.com\/blog\/2004\/11\/15\/nominations-process\/","url_meta":{"origin":261,"position":0},"title":"nominations process","author":"Stewart Smith","date":"2004-11-15","format":false,"excerpt":"okay.... my previous ramblings on the details of the voting stuff (see MemberDB Voting code (planning\u00e2\u20ac\u00a6 in some sense of the word)) didn't really address how someone nominates someone else and how they accept\/deny the nomination. Member A nominates member B for position P. Member C seconds the nomination for\u2026","rel":"","context":"In "linux-aus"","block_context":{"text":"linux-aus","link":"https:\/\/www.flamingspork.com\/blog\/category\/linux-aus\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":294,"url":"https:\/\/www.flamingspork.com\/blog\/2004\/11\/15\/voting-code\/","url_meta":{"origin":261,"position":1},"title":"Voting code","author":"Stewart Smith","date":"2004-11-15","format":false,"excerpt":"I've been making inroads into the voting part of MemberDB. You can create an election (with a number of positions), list elections, and view extra details about it. It handles the priviliged versus non-priviliged user thing and I'm getting to work on the nominations part. I've made a bunch of\u2026","rel":"","context":"In "linux-aus"","block_context":{"text":"linux-aus","link":"https:\/\/www.flamingspork.com\/blog\/category\/linux-aus\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":343,"url":"https:\/\/www.flamingspork.com\/blog\/2005\/01\/16\/memberdb-a-membership-database\/","url_meta":{"origin":261,"position":2},"title":"MemberDB – A Membership Database","author":"Stewart Smith","date":"2005-01-16","format":false,"excerpt":"MemberDB - A Membership Database I released 0.3 today. Contains all the election code as used in the LA 2005 Election. Yes, there's known bugs in this release.. check bugzilla for current ones.","rel":"","context":"In "linux-aus"","block_context":{"text":"linux-aus","link":"https:\/\/www.flamingspork.com\/blog\/category\/linux-aus\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":230,"url":"https:\/\/www.flamingspork.com\/blog\/2004\/05\/02\/memberdb-work\/","url_meta":{"origin":261,"position":3},"title":"memberdb work","author":"Stewart Smith","date":"2004-05-02","format":false,"excerpt":"been doing a fair bit of mods to memberdb recently - getting features in. - new css based look (which is almost correct) - more solid code around the place - better error reporting (that needs debugging... hahaha) - a start on the positions tracking UI - change password UI\u2026","rel":"","context":"In "linux-aus"","block_context":{"text":"linux-aus","link":"https:\/\/www.flamingspork.com\/blog\/category\/linux-aus\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":282,"url":"https:\/\/www.flamingspork.com\/blog\/2004\/10\/01\/integrating-memberdb-with-las-look-and-feel\/","url_meta":{"origin":261,"position":4},"title":"Integrating MemberDB with LA’s look-and-feel","author":"Stewart Smith","date":"2004-10-01","format":false,"excerpt":"Well... since LA actually has a look and feel now (thanks to the new website), I have to make good on the \"site look is independent of the actual memberdb code\" statement. It's proving to be sorta-true. A couple more patches into memberdb and it should all be right. Oh,\u2026","rel":"","context":"In "General"","block_context":{"text":"General","link":"https:\/\/www.flamingspork.com\/blog\/category\/general\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":973,"url":"https:\/\/www.flamingspork.com\/blog\/2008\/01\/11\/memberdb-speed-improvements\/","url_meta":{"origin":261,"position":5},"title":"MemberDB speed improvements","author":"Stewart Smith","date":"2008-01-11","format":false,"excerpt":"So I finally installed the xdebug PHP extension and started doing some performance analysis of MemberDB using xdebug and kcachegrind. The upshot of which is a number of commits to the bzr tree that dramatically improve performance in several key areas. The answer? Caching. I'm not even talking using memcached\u2026","rel":"","context":"In "linux-aus"","block_context":{"text":"linux-aus","link":"https:\/\/www.flamingspork.com\/blog\/category\/linux-aus\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/www.flamingspork.com\/blog\/wp-json\/wp\/v2\/posts\/261","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.flamingspork.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.flamingspork.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.flamingspork.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.flamingspork.com\/blog\/wp-json\/wp\/v2\/comments?post=261"}],"version-history":[{"count":2,"href":"https:\/\/www.flamingspork.com\/blog\/wp-json\/wp\/v2\/posts\/261\/revisions"}],"predecessor-version":[{"id":3454,"href":"https:\/\/www.flamingspork.com\/blog\/wp-json\/wp\/v2\/posts\/261\/revisions\/3454"}],"wp:attachment":[{"href":"https:\/\/www.flamingspork.com\/blog\/wp-json\/wp\/v2\/media?parent=261"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.flamingspork.com\/blog\/wp-json\/wp\/v2\/categories?post=261"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.flamingspork.com\/blog\/wp-json\/wp\/v2\/tags?post=261"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}