iTWire – Linux Australia election results are in – but is there a mandate?

iTWire – Linux Australia election results are in – but is there a mandate?

I mostly disagree with the conclusions drawn by David here.

On voter turnout, this year we were consistent with previous years (see previous graphs, and reproduced below):

We’ve even been on a (slow) increase. How do we increase this number though?

There are also other factors as to why people didn’t vote:

  • Happy with any combination of candidates (this was voiced at the AGM)
  • Not aware of voting timeframe, or in the middle of LCA prep/travel (how do we deal with this? Longer voting time? automated pestering of people via email from the membership system?)
  • No/limited choice in executive positions

If we look at the people standing for positions over the years (reproducing this graph from previous post):

It’s quite possible to assume that many people are happy with who’s standing for executive, and not too worried about OCM positions.

There is also no way to express “I’m happy with any combination of candidates” in the election system. The query for “number of members voted” (see the source. incidently, i wish launchpad let you link to line numbers):

$result = $dbh->query("select count(distinct member_id) as count from election_vote where candidate_id in (select id from election_candidate where election_position_id in (select id from election_position where election_id=".$election['id']."))");

So if you didn’t vote for anybody, you’re not counted in having voted. Patches are welcome to fix this :)

If it’s uncontested, then many people just don’t put a 1 in the box. New MemberDB releases (what we’re likely to use for next year) have a drop-down menu of numbers, which may result in less of this. It could also be a few votes against the candidate – in the absence of another choice (or the voter choosing to stand themselves). In any of these scenarios though, it’s not a significant number of votes – all candidates got an overwhelming majority of votes.

I also feel that somebody joining the council who is *not* a new face is a very big plus. We want (and indeed need) people who understand the organisation.

I’d also like to contrast our 66 voting members to the 2006 ACS AGM with only 26 voting members present and the 2007 ACS AGM having 40 voting members present. I was unable to find out details on how many people voted for board members though…

So I don’t think Linux Australia is in a bad place with having 66 people voting… I just think it could be better.

Do we have a mandate? Well… it’s mind-numbingly simple to stand for council – get one other person to nominate you and nominate yourself. The fact that nobody has is a sign it itself (and we do have active members and the broader community watching us).

MemberDB speed improvements

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 or caching things in database tables or anything like that – just about everything is still the same dynamically produced content as before, but I’m now caching some simple things avoiding many round-trips to the database while executing a script.

There were a few things that were taking a fair bit of execution time:

  1. The generation of the menu. In MemberDB, there’s a menu on the left. There’s also a powerful (read: non-trivial) permissions system allowing relatively fine grained granting of permissions. So, we need to check that the user has permission to go to the page before showing the page in the menu.
    Previously, for each item in the menu, we’d do a lookup to the database – checking if they have the permission or they are an admin. This ended up taking a bit of time – up to 30% of the time for the front page was taken up just generating the menu!
    So, now I cache the set of permissions for the user. One function to fetch it from the DB into a structure, another function to check the permissions of the user in that struct.
    While testing this, I actually used memcached to cache the menu to see how much of an improvement I could get… I’m about 69/70ths of the speed of using memcached with a purely PHP implementation caching the permissions info.
  2. Getting the information about a member is done in a variety of places. On some pages, you want information on the current logged in user (or just need to find their member ID). These are now cached for the duration of the script. Saved quite a few DB round trips
  3. When viewing an election (not the results, just the normal “view election” page that lists candidates), we need to get the membership information on a number of users (okay… so technically I should rewrite some of the queries to use joins in the DB… but this was easier). I now have a (limited) cache of membership info. So now, when a member has nominated multiple people, we only pull the member info out of the database once.
  4. Rewrite the “current_members” view. The old one was not as efficient as it could be. While the new one has slightly different semantics (can have duplicate rows, it turns out the use of DISTINCT was adding a bit of execution time, which for a bunch of queries is not needed) it’s significantly quicker.

I used the faithful Apache Bench (ab) to do benchmarks against the modified PHP code. I think the biggest improvement was the view election page which went from about 6seconds/page to 0.2seconds/page.