CC Meeting: Election/Appointment processes
daniel.holbach at ubuntu.com
Thu Feb 25 17:03:10 GMT 2010
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
> 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:
Yes, this was part of the governance check at UDS. Every council/board
should have them set now.
>> 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.
I was working on a "governance tracker" that would initially list
expiring members and later on could handle nominations.
Unfortunately I didn't have the time in the last weeks/months to work on it.
>> 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.
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
If I missed anybody or didn't portray reality correctly please let me know.
>> = 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)
Sounds good to me. Any other opinions?
> 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. :-)
>> 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.
I'll make this more prominent.
>> * 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
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.
Thanks a lot for the feedback.
Have a great day,
More information about the Team-council-members