no, it’s not released – but i made a branch that should be a relatively stable version of 0.3.

it has none of the election work (it’s not finished) – and in hindsight, maybe it should have gone into a seperate branch… but oh well.

been doing some security fixes as well… and updating the installed copy on digital as i do.

you can now accept nominations and put down your spiel.

At some point I’m going to have to go through a bunch of the code and do a security audit. We should be fine with what we’re running now, but the head of 0.3 most likely isn’t. All that will be problematic is insertion of crap into the outputted HTML.

There’s also been a number of improvements recently in the forms infrastructure which the older parts of the UI could benefit from.

Not that speed is a current problem, but a bit of caching could really help some things along – esp with get_member_id, get_member and has_permission. We really don’t need to go back to the database multiple times in the same page display. Temporary variables can just be messy too – much better to keep the code clean.

Preferential Voting

Good small explanation.

added a column to election. you now have a “number of required nominations”.

in a normal election, this will be two. One person nominates, the other seconds.

When there are enough nominations, the person can accept it, and then an entry is created in election_candidate.

at least this will be the case… soon.

About to go and write the accept nomination page thingy.

previously, we had the idea of an election candidate:

create table election_candidate (
     id serial unique not null,
     election_position_id int not null,
     approved boolean,
     member_id int not null,
     spiel text,
        CONSTRAINT "election_candidate_pkey" PRIMARY KEY (id),
        CONSTRAINT "election_candidate_election_position_id_fkey" FOREIGN KEY (org_id) references election_position(id) on update restrict,
      CONSTRAINT "election_candidate_member_id" FOREIGN KEY (member-id) references current_memberships(id)
 -- FIXME: need constraint that member is a member of the correct org.
 );

now, that’s all fine and good… but we need the whole nominations thing to work.

so what about something like this:

create table election_candidate_nomination (
     when timestamp not null default now(),
     election_position_id int not null,
     from_member_id int not null, -- member doing the nominating
     for_member_id int not null, -- the member being nominated,
     reason text,
     CONSTRAINT "nomination_from_member_id_fkey" FOREIGN KEY (from_member_id) references members(id) on update restrict,
     CONSTRAINT "nomination_for_member_id_fkey" FOREIGN KEY (for_member_id) references members(id) on update restrict,
     CONSTRAINT "election_candidate_election_position_id_fkey" FOREIGN KEY (org_id) references election_position(id) on update restrict,

);

this should be adequate to keep track of nominations. When enough nominations are gathered and the candidate accepts, then we can create an entry in election_candidate.

okay…. my previous ramblings on the details of the voting stuff (see MemberDB Voting code (planning… 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 member B for position P.
(there doesn’t need to be a distinction between nominate and second – indeed we could just allow up to n nominations – or should it be a preference?)
Member B either accepts or refuses the nomination

If the nomination is refused by member B, that’s final (for that position).

If the nomination is accepted, we no longer need to allow further nominations of B for P.

When the nominations period is over and the show candidates period begins, we just display those nominated who have enough nominations (i.e. been seconded).

When it comes time to vote, those people are on the ballot.

Admins can, of course, dick with this as much as they want.

Yes, admins can screw with the results of the election – we are root, hear us roar.

At least it’s a bit more secure than some elections.

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 infrastructure changes too. A bunch of stuff in the forms code has made things easier – I have no idea how i’d do all of this without that as a base (okay, i’d probably go and write it).

I’m basically spending this week on the voting stuff, and being this far in atm seems to be on track. I guess i’ll see as time goes on.