Only 18 bugs for MemberDB 0.4!

Yes “only” 18….

although the “make installation procedure not suck” has to be the most important.

I’m very tempted to branch and make a 0.3.1 release the “no, it really works this time” release. mainly because there were still a few annoying bugs (being female could cause you trouble if you messed with the edit-member page. It would store it okay, just always display it wrong (which meant that it *looked* like it wasn’t recording you as female).

Hopefully I’ve stopped the javascript error box popping up on some platforms too.

sydney meeting

I’m in Sydney for the weekend for a Linux Australia committee meeting. This will be the third year I’ve been on the LA committee.

So, if you’re in Sydney and want to join us for a drink and a discussion – get in contact (la committee, me, or ppl on the slug list should know).

Lots to discuss and talk about, should be good.

MySQL port of MemberDB

Spent probably about 3 hours today porting the database schema to MySQL 5 along with finding some bugs in the process. Pretty minor ones, mainly to do with how things could be improved to improve compatibility with schemas written with postgresql in mind.

While chasing up some stuff on why the serial type alias in mysql wasn’t exactly the same as postgresql serial type (which is an integer with a sequence and default value) i found this gem in the postgresql docs:

Note: Prior to PostgreSQL 7.3, serial implied UNIQUE. This is no longer automatic. If you wish a serial column to be in a unique constraint or a primary key, it must now be specified, same as with any other data type.

Great huh? So upgrade postgresql and don’t go sifting through your tables (now come on, everybody uses a serial/auto_increment field in a lot of tables) you loose!

i.e. there’s bugs in memberdb now that weren’t there when i started and i didn’t change any code to make them. hrrm…

anyway, i’ll write at some time the few easy steps it took to get the schema across (it takes no time once you know what you’re doing – like a few commands and a few search and replaces).

for now, you can get stuff from arch: stewart@flamingspork.com–memberdb/memberdb–mysql–0.4

the schema loads, i’ll have to change one bit of code to make it all work – otherwise everything should be fine (but let me test first – or provide fixes, not complaints :)

A Linux Australia election spiel.

Given the growth and success of LA it has become apparent that the the way the managing committee is run needs to be changed. We need to become effective in concentrating volunteer effort. Committee members have taken a lot and they have been getting burnt out. Reaching out and engaging others in the community is crucial to the future of LA. This includes improving communication with conference organisers, the community at large and inside the committee itself.

Several specific tactics I plan include: reducing the number of formal committee meetings (reducing administrative burden), implementing efficient ways to decrease the length of meetings while increasing the amount achieved, implementing a better way to track tasks that we want to achieve and the progress made on them, starting informal conference calls to help co-ordinate projects, committee thoughts (so that everyone is on the same page) and community participation. Last but not least, it is the main goal of LA to make sure that linux.conf.au runs and is a success.

For those who don’t know:
Stewart lives in Melbourne, breathes code, has been VP of LA for two years and works for MySQL AB.

Weatherall’s Law

If you don’t already – point your RSS feed reader over to Weatherall’s Law

and examine her most recent writings about Software Patents.

Kim describes her blog as “Being the thoughts and comments of an Australian IP Academic on IP, IT, etc.”

There is, of course, the legal disclamier that the views expressed there are her own and not that of….

which for some reason makes me giggle. Maybe it’s because she’s a lawyer and isn’t just putting it on there to sound cool.

branched stable–0.3

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.

Additional code into voting

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.

making a nominee a candidate

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.

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