implementing the nominations stuff

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.

nominations process

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.

Voting code

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.

Integrating MemberDB with LA’s look-and-feel

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, not to mention patches to the LA website :)

We’re going to have to undo some of those silly styling things (such as styling all h1 tags to be in the same position on the screen).

Screenshot of an Early effort at integrating LA's website with MemberDB

PEAR :: Bug #2417 :: [PATCH] Incorrect processing of ‘permission denied’ style error messages

PEAR :: Bug #2417 :: [PATCH] Incorrect processing of ‘permission denied’ style error messages

Got the bugger – and supplied a patch that fixes it!

This should spell an end to those annoying (and really unhelpful) “DB Error: unknown error” messages from PEAR::DB when the user doesn’t have enough permissions.

Been hitting this a bit with MemberDB.

I’d love PEAR::DB to return back the native error string as well… but it’s kinda hidden.

Maybe I should be changing the getMessage() methods to return the PEAR message *and* the extra debug stuff? hrrmmm…

oh well, for later

More Linux Australia website stuff

well, we’ve gotten everything into arch, and Pia and I have both committed to the central archive on digital fine. We’re getting places! this is *good*!

I think we’re nearly ready to go live. Just have to set up the news feeds for our “latest news” stuff. so, some mysql foo on digital, and it should all “just work”.

At some point soon, I plan to have a branch of memberdb in the archive so that the LA specific changes can be made there. Namely the site-look and site-messages folders.

These really should be seperate categories and use configs. I plan to do that soon… but possibly keep the website itself away from that (don’t want to scare Pia too much :)

Although arch does these things a *lot* better than other revision control systems. Although the user experience of the one we use at sgi is great – it’s all transparent to the user (unless you want to know).

MemberDB Voting code (planning… in some sense of the word)

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 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).

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).

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.

e.g., something like:

create table election (
        id serial unique not null,
        org_id int not null,  -- election for this org (NULL=all orgs)
        name varchar(50) not null,
        start_advertising date, -- date that we'll display in a UI that "an election is coming"
        nominations_start date,
        nominations_close date,
        advertise_candidates date, -- list the candidates from date onwards
        live_results boolean, -- results in real-time
        start_voting date, -- when voting opens
        close_voting date, -- when it closes
        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)
        description text,
        CONSTRAINT "election_pkey" PRIMARY KEY (id),
        CONSTRAINT "election_org_id_fkey" FOREIGN KEY (org_id) references orgs(id) on update restrict

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”.

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).

We need positions to elect people into.

create table election_position (
 id serial unique not null,
 election_id int not null,
 name varchar(50) not null,
 description text,
-- FIXME: insert constraints here

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).

something like:

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.

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.

So, an election has positions and each position has candidates. Candidates have spiels, and have to be approved before they’re listed.

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).

create table election_vote (
    election_position_id int not null,
    member_id int not null,
    election_candidate_id int not null
-- FIXME: constraints here

now… all that needs to be done is a UI… and some sanity checking of the above. :)

memberdb work

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
– sorting of the memberlist
– moving look and messages into site customisable directories (so nobody has to get scared by memberdb code itself)

so, been busy :)

some of these have made it to the stable branch… i guess i’ll put more of them in there as things actually stabilise. Especially since is actually running the stable 0.2 branch now (which is nowhere near final).

Have no real schedule or ideas on when to release 0.2, maybe when i’ve done the positions stuff, fixed the CSS and made a “edit member info” (accessible to admin and each member) UI. That’d be a real big leap from 0.1 :)

I’d like to put GPG stuff on the cards for 0.3…. but it’ll be tricky finding a nice way to integrate everything. I’m thinking along the lines of a UI where a person enters their key ID, fingerprint and keyserver (then we pull the key using gpg). To help verify, we could then send all email gpg signed/encrypted :)

we’d then have to have a not-well-trusted GPG key for memberdb installations – which could be… interesting….

but hey – it’s the one big feature request from an outside group.

They want to have GPG signed applications – but maybe they’ll settle for sending GPG encrypted mail to the applicant (saying “confirm membership like this”). The validity of the key can always be checked before approving the membership – it’s going to have to be semi manual anyway.

memberdb 0.1!

Oh yes, time for me to abuse my position and spam a bunch of lists! :)

memberdb is the membership database software i’ve been hacking off and
on for a while now, and is being used by Linux Australia.

In it’s current form, it’s visually not very pretty – but the backend
database has had a huge amount of design (and redesign) work put into
it. This release is to encourage feedback, patches and volunteers.

It’s also out there so that other groups can look at it as a possible
solution to their membership database needs. Okay, realistically,
they’ll need a lot of work on it before it suits them and not us. It’s
called contributing dudes!

Yes, there are bugs. Yes, probably a security issue or something that’s
slipped me by – open source, peer review – all good.

Anyway, go have a look:

or grab the 0.1 tarball from:

even better, grab the latest sources and start hacking! esp if you’re a
XHTML and CSS guru – i need them :)