[maemo-community] Election process referendum

[From: Benson Mitchell]

On Mon, Feb 2, 2009 at 7:02 AM, Andrew Flegg <andrew at bleb.org> wrote:

> On Sun, Feb 1, 2009 at 4:12 PM, Dave Neary <dneary at maemo.org> wrote:
> >
> > Andrew Flegg wrote:
> >> What about a referndum with four options, then:
> >>
> >>   1) No change; the current process is fine.
> >>   2) A single-transferrable vote system.
> >>   3) A reweighted range voting system.
> >>   4) None of the above.
> >
> > I'd like to re-propose my initial proposition:
> > 1) No change.
> > 2) Codify preferential vote, without saying what specific voting or
> > counting system will be used.
>
> I'm still not convinced about giving the outgoing council so much
> control, and don't want to have these debates *every* 6 months as to
> what the current council should instigate for the next election.
>
> So would suggest:
>
>  1) No change; the current process ("first-five-past-the-post") is fine.
>  2) A single-transferrable vote system. (Wording TBD)
>  3) A reweighted range voting system. (Wording TBD)
>  4) Giving the outgoing council the decision before each election. (Wording
>     TBD).
>  5) None of the above.
>

I like those choices, but this brings us back to something someone pointed
out earlier, the difficulty of getting a clear winner in that sort of
referendum. We don't actually have specific scoring provisions for
referenda, so we could just go with plurality (rather than majority) here,
but that actually opens up some questions. Suppose that it splits 30, 25,
10, 20, and 5; we'd keep the current system, even though most of the RRV
voters would probably prefer STV or council's choice, and either of those
could have won head-to-head. Now I'm _not_ suggesting we have a referendum
on the voting method to be used in referenda on voting methods, but the
characteristics of the voting method to be used must be considered.

(It's probably obvious, but I think the _best_ way to choose is the proposed
5-choice ballot, but with range voting (non-reweighted, because it's single
winner), or failing that, IRV. I also am aware of the problems with using
one of the proposed voting methods to choose the voting method, so I'm going
for simplest without changing methods...)

I'm not sure we can do this, but it seems the simplest way to ensure a
meaningful result with plurality would be to divide this into two decisions:
which alternate method is best (three choices: STV, RRV, and outgoing
council's choice), and after results are known, whether to make the change
to the chosen method, or stay with what we have.


> > The constitution should be, IMHO, a framework document, not operating
> > instructions. Let's just specify a preferential voting system (which, by
> > my reading, is possible within the current council guidelines), and let
> > the council decide what to do in practice, after consultation.
>
> To clarify, your reading of "The 5 nominees with the most votes are
> elected" allows "most" and "votes" to be a total number of votes
> counted by an arbitrarily-different system, rather than the highest
> number of ballots cast?
>
> What do other people think? Certainly not the intention, but it seems
> - as a community - the most vocal (at least) don't mind suspending the
> constitution when it befits (e.g. at the last election).


I'm generally in favor of either following the constitution, or fixing it.
And in this case, I can't see how either of the proposed systems is in
compliance with "each community member gets one vote." Since we have time
for a referendum, it seems much better to change that wording than to try to
lawyer a preferential/score voting system out of what's there.

Oddly, we have much more slack with referenda voting/counting, but because
we're trying to pick a voting/counting system, it's difficult to leverage
that.


> > Graham, as I understand it, the requirement of 25 karma to vote and 100
> > karma or more to be candidates. The 25 karma requirement was relaxed for
> > the first election, and several changes have been made to the karma
> > measurement since then - ITt chats have been added, thumbs downs don't
> > affect the karma of blog authors, wiki and bugzilla karma measurements
> > have improved. The only reason I can think of that someone who is part
> > of the maemo community would not now have 25 karma would be if they
> > refused to create a maemo.org account. Otherwise, I think that karma is
> > a lot betternow than 4 months ago.
>
> Agreed. There are over 600 people with a karma of 25 or over having
> had a quick look, but I spotted a few ITT usernames in there without
> any count. I assume this is because they've not linked in ITT with
> their maemo username yet. I'll look to advertising the linkage feature
> on ITT this afternoon to better ensure people have the karma they
> deserve.
>
> I certainly *wouldn't* be happy if - at the last minute - the karma
> requirement was dropped again. There's been plenty of time for people
> to garner 25 karma points; to raise the issue etc. The proximity of
> time someone raises an issue to a deadline is, admittedly,
> understandable; but it dramatically reduces their ability to convince
> me.
>

Definitely agreed here, it's been stated since the last election that
(barring any further changes) a 25-point limit would be required.

>
> I also strongly disagree with those who say that karma shouldn't be
> used for this (ignoring Tim's valid point that, really, the Council
> doesn't have that much power), if it's not for rating someone's
> participation in the community, what *is* it for? One of the things
> mentioned when it was originally introduced was the prospect of karma
> contributing to future device programmes - discounted hardware is
> something much more concrete and attractive (assuming a council who
> isn't widely populated by trolls and fools)


Not only does it measure contribution, it also helps limit fraud, as it's
harder to set up a dozen dummy accounts and build their karma up.



Benson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maemo.org/pipermail/maemo-community/attachments/20090202/8b6fe5a4/attachment.htm