CC Meeting: Election/Appointment processes

[Matt Zimmerman]

On Mon, Feb 22, 2010 at 09:08:22AM +0100, Daniel Holbach wrote:
> On 19.02.2010 17:10, Daniel Holbach wrote:
> > On 17.02.2010 14:05, Jono Bacon wrote:
> >> Thanks for the notes, Matt. I think a community leader driven document 
> >> is a great idea. Daniel, could you kick off the first draft and email 
> >> our governance boards to get this started?
> > 
> > Let me know what you think:
> > 
> > 	https://wiki.ubuntu.com/CommunityCouncil/RestaffingProposal
> 
> In case you haven't seen it yet, it's being discussed here as well:
> 
> https://lists.ubuntu.com/archives/team-council-members/2010-February/000013.html
> 
> 
> Please share your thoughts either here or in the other thread. It'd be
> nice to get this discussed and approved.

(copying both lists)

Thanks for making a start on this, Daniel.  Overall, I think it's a good
start, but I would like to see it be a bit more prescriptive and
step-by-step.

Elections will happen regularly throughout the lifetime of the project, and
will be run by different people at different times, so the simpler we can
make this, the better.

> 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

> The only exception is Mark Shuttleworth's seat (aka SABDFL) on the
> CommunityCouncil and TechnicalBoard.

cf. https://bugs.edge.launchpad.net/ubuntu-community/+bug/485559

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

> The re-staffing can happen in form of an election or an appointment. While
> the Community Council and Technical Board reserve the right to appoint if
> it's necessary, in the majority of cases an election will be the preferred
> solution.

Agreed.

> This will happen, when there is a clearly governed subteam of
> Ubuntu members who can vote the new board or council members. For example:
> 
>  * ~ubuntu-dev would vote new ~techboard members
>  * ~ubuntu-dev would vote new ~developer-membership-board members
>  * ~ubuntumembers would vote new ~communitycouncil members
>  * etc.
> 
> An example where it's not quite clear who would vote is the LoCo Council.

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.

> = Announcing and planning an election =
> 
> If you coordinate the restaffing of a board or council, you might want to
> give the nomination part special thought. Make sure you make the list of
> responsibilities and the type of personalities you are looking for are
> quite clear when announcing the nomination period. Self-nominations,
> nominations by others, both? Which information do you want nominees to
> include? Will you need to short-list the number of nominees (if you're
> having an election)? Please also make sure that you leave at least 1-2
> weeks for that nomination period and make sure the relevant people know
> about it.

This is an area where I think we should be more prescriptive.  There are too
many options, too many different ways to do this.  Why don't we say:

 * the team should have established guidelines for the necessary
   qualifications for its members, and the person running the
   election should provide these to help with nomination

 * the normal nomination period is 2 weeks but can be adjusted if
   circumstances warrant it

 * nominations should generally be open to anyone with the necessary
   qualifications (as established by the team), though the team may
   choose to do differently (e.g. the CC)

I don't think it's necessary to limit the number of nominees; Condorcet
voting seems to handle this well.

> You might want to ask the (probably short-listed) nominees to write
> something about their ideas and plans on their wiki pages, so voters will
> be better informed about who they vote.

I think this is essential; without this information, if voters are not
personally acquainted with the candidate, then it's just name.  This should
be due from each nominee by the start of the election.

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

-- 
 - mdz