CC Meeting: Election/Appointment processes
mdz at ubuntu.com
Thu Feb 25 22:11:25 GMT 2010
On Thu, Feb 25, 2010 at 06:03:10PM +0100, Daniel Holbach wrote:
> On 22.02.2010 12:19, Matt Zimmerman wrote:
> > On Mon, Feb 22, 2010 at 09:08:22AM +0100, Daniel Holbach wrote:
> >> Every Ubuntu Council or Board has a specific term length for their members
> >> defined.
> > Is there any way to check that this is documented all around? We discovered
> > recently that it was not correctly documented for the Technical Board:
> > https://bugs.edge.launchpad.net/ubuntu-community/+bug/485569
> Yes, this was part of the governance check at UDS. Every council/board
> should have them set now.
Do you mean that the default expiration time is set in Launchpad to be the
appropriate term length? If so, great. Is there guidance on how to set it
when new teams are created?
> >> At each UDS the list of boards and councils is checked for expiries.
> > Who is responsible for making sure that this happens? Not all elected teams
> > are represented at UDS.
> We had the session in the Community track the last time and I think we
> should continue to have it.
So the Canonical community team takes responsibility for it? That sounds
fine to me.
> > I think it should be a requirement for all of the elected councils/boards
> > (do we need both names?) to have a clear constituency, so that it's clear
> > who will vote. Perhaps this could be part of the description in Launchpad
> > so that it's recorded with the other essential information for the team.
> Agreed, it would be nice to record that information in LP for the
> governance bodies which have this special relationship and very clearly
> do that for the ones that don't.
> - ~ubuntu-lococouncil: ~communitycouncil
> - ~ubuntu-irc-council: ~communitycouncil
> - ~forum-council: ~communitycouncil
> - ~ubuntu-membership-board-americas: ~communitycouncil
> - ~ubuntu-membership-board-asia-oceania: ~communitycouncil
> - ~ubuntu-membership-board-emea: ~communitycouncil
> - ~kubuntu-council: ~kubuntu-members
> - ~edubuntu-council: ~edubuntu-members
> - ~developer-membership-board: ~ubuntu-dev
> - ~techboard: ~ubuntu-dev
> - ~communitycouncil: ~ubuntumembers
I'm not sure how kubuntu-members or edubuntu-members work, but this seems
sane to me.
> > I don't think it's necessary to limit the number of nominees; Condorcet
> > voting seems to handle this well.
> It's a bit hard to set up and might be good to have integrated into LP. :-)
I found it pretty easy to set up CIVS; the only hard part was getting the
list of email addresses out of Launchpad.
> >> * Launchpad votes are pretty straightforward, but a bit limited in its setup, either you
> >> * set up one poll for the whole election and see who gets the top <x> of <y> votes (5 of 12, when you have 12 nominees and 5 seats) or
> >> * set up one poll per person and see who gets the most "Yes minus No" votes.
> >> * [[http://www.cs.cornell.edu/andru/civs.html|CIVS]] makes use of the [[http://en.wikipedia.org/wiki/Condorcet_method|Concordet method]] which can be more suitable.
> > I suggest that we default to CIVS except where there is a reason to do
> > otherwise, for the sake of simplicity and because it collects and uses more
> > information from voters.
> > We should say something about how to communicate about nominations and
> > elections. If there is a defined constituency, then the requirement should
> > be to directly notify its members of the process (probably via a Launchpad
> > team).
> In the specific case of CIVS you need mail addresses of all your team
> members which Launchpad might not want to give you like that. Also does
> CIVS send out personalised links which might not work via Launchpad's
> "notify members of this team" link.
Yes, it does send out personalized links, so it's necessary to get the list
of email addresses. We should be able to make this easy, or just have
someone do it on behalf of the person running the election, because we don't
have very many elections per year really.
More information about the Team-council-members