policy for membership in MOTU key teams

[Scott Kitterman]

On Wednesday 02 July 2008 07:29, Cody A.W. Somerville wrote:
> Hello,
>
> On Tue, Jul 1, 2008 at 6:21 PM, Emilio Pozuelo Monfort <pochu at ubuntu.com>
>
> wrote:
> > Hi all,
> >
> > Emilio Pozuelo Monfort wrote:
> > > First draft for a policy for motu-{sru,release} membership:
> >
> > Sorry for the long delay. I've had a look again at the proposal and at
> > the comments, let's see if I can summarise them.
>
> Thanks for getting the ball rolling again. I've been doing some thinking
> about this and so I'm going to jot down some ideas to share :)
>
> > > 0/ The term of service for the motu-sru and motu-release teams is of
> > > one
> >
> > release
> >
> > > cycle (six months).
> >
> > It's been said this is too short, and that 1 or 2 years would be better.
> > It's
> > also been proposed that we could have a long term (e.g. 2 years) but with
> > "pings" from time to time (e.g. 6 months) to see who is not active and
> > then replace inactive members. That way you don't change the entire team
> > at the same
> > time.
> >
> > I personally think 2 years is too much, but one year would be fine with
> > me.
> >
> > And I don't think there will be problems regarding to changing the entire
> > teams,
> > as I expect some of the old members to reapply and be re-elected.
>
> It seems to me that it would be beneficial to define the terms in
> relationship to certain milestones in the release cycle instead of just
> saying "six months" or "one release cycle". This would ensure that we have
> individuals in place in case dates for said milestones change. For example,
> if a release cycle were to ever be extended again (like the first LTS), we
> don't want to be dealing with an election while we're trying desperately to
> wrap up a release. It would also give us tentative yet concrete dates to
> work with - no need to guess when "six months" or "two years" is up as we'd
> say: "ok, two weeks after the official release date we need to call
> election for xyz".
>
> As for length, I feel that members should serve for two release cycles.
> This will tie into my reply to Sherman's post in a minute.
>
> I also think the ping inbetween the two releases would be a good idea
> incase someone goes missing.

As long as not everyone expires at the same time this sounds fine.

> > > 1/ When the nominating time starts, people may nominate themselves
> > > (with
> >
> > a mail
> >
> > > to ubuntu-motu@). There's no restriction as to how many terms someone
> >
> > can
> >
> > > participate, but they need to reapply after each term ends.
>
> I think this should be clarified. Does this mean once elected, the
> individual can serve as many terms as they'd like as long as they "reapply"
> (ie. express their intention) or do they have to be re-elected? I think you
> mean the latter and I agree.
>
> > > 2/ When the nominating time ends, assuming there's any (even just 1,
> >
> > (s)he may
> >
> > > be rejected) candidature, the MC sets the polls in Launchpad (yes, it
> > > has
> >
> > a poor
> >
> > > interface, we need to file bugs if there aren't yet...), and the MOTU
> >
> > team is
> >
> > > given a week to vote.
>
> One week to vote seems fair and I think that having the election date in
> relation to a milestone as I propose above will help ensure we see optimal
> participation at the polls.
>
> Also, what does it mean to be rejected or approved? What voting system will
> we use? Are the candidates with the highest number of votes added until the
> team reaches capacity? Is it possible to vote *against* a candidate? Do
> candidates require a majority to be approved?

We should use an actual election system, not the botched system in Launchpad.  
My preference would be for http://en.wikipedia.org/wiki/Condorcet_method.  We 
can use something like http://www.cs.cornell.edu/andru/civs.html until 
Launchpad grows some useful functionality in this area.

> > > 3/ The MC adds the accepted candidates to the appropriate teams.
>
> Yup.
>
> > > 4/ If all the vacancies haven't been fulfilled, another call for
> > > members
> >
> > may be
> >
> > > done, after a time of one week.
>
> I think this point needs more clarification as well. Is the team allowed to
> move forward without a full "load"? What if the community at large doesn't
> think there is another willing candidate suitable and how would that be
> expressed/measured? What role does the MOTU council play in this situation?

Ask again for more volunteers.  It worked just fine for motu-sru this time.

 ... snip

I don't think we need to decide numbers in advance.

> Also, what do people feel about the MOTU council (either as a monolithic
> entity or individual members) being able to fill in as an acting member (or
> members) in situations where the minimum is unable to be reached? What
> about the MOTU council being able to extend an existing member's term to
> cover the same situation even if his or her re-election was unsuccessful
> (or, to clarify, maybe didn't meet the normal qualifying conditions which
> will be dependent on the voting system we decide to use). What ever your
> opinion, I feel this specification should enable the motu council the
> ability through certain processes to help push tough, stalled situations
> into moving, productive situations.

No.  I don't think they should do this.  They can help find solutions to 
disputes and encourage volunteers, but that's it.

> > > Things that aren't clear yet in that draft:
> > > - When the nomination period starts for each team (one week after the
> >
> > release
> >
> > > for motu-release and just after FeatureFreeze for motu-sru?).
>
> Although I've already given a few example dates/time lines in my discussion
> above, I feel is important that when deciding that the desire be to have
> these teams ready *for* action instead of becoming ready *in* reaction. To
> help facilitate this, I'd like to make the following proposal. Please allow
> me to quote Stephan Hermann's e-mail which came in as worked on this reply:
>
> On Wed, Jul 2, 2008 at 3:48 AM, Stephan Hermann <sh at sourcecode.de> wrote:
> > Good Morning,
> >
> > On Fri, 23 May 2008 19:26:40 +0200
> >
> > Stefan Potyra <sistpoty at ubuntu.com> wrote:
> > > Hi,
> > >
> > > as evolved by the discussion for motu-sru members, I guess it might
> > > make sense to have a good general policy.
> >
> > I would like to see a policy for:
> >
> > motu-sru / motu-release:
> >
> >        * Changing Members every release cycle
> >
> > Why? It would be a good practice for newer MOTUs to step up and learn
> > the "hard release work".
> >
> > Merging, fixing bugs, syncing for the actual development release is
> > good and gives knowledge, but knowing how hard some decisions are is
> > much better. Sure, re-elections of older members is possible, but I
> > really want to see young blood.
>
> I agree with Stephan that is important for us to get "young blood" up to
> the task with the "hard release work"(sic.) but I also feel that it is
> important the team remains effective at all times as I feel is the
> rationale behind other's desire for longer terms. I feel that both
> scenarios are possible via what I might call "rolling" (and also a process
> I think other bodies in Ubuntu already use). If we were to set the term at
> two releases (as I proposed earlier), we could elect a "minimum set" (this
> is where my idea for min, max, and nominal get messy) but at the end of the
> first release cycle we could elect even more individuals (ie. "new blood")
> to bring it up to a "nominal" (or a little bit above nominal). These new
> individuals would then have an opportunity to learn the tricks of the trade
> with the more senior, experienced members already settled in (giving them
> more time to help the more junior members). At the end of the second
> release cycle, the more senior members will be able to re-apply or retire
> knowing there is still a number of individuals serving who have came to
> know what they're doing. Furthermore, an added benefit would be in the case
> of some sort of electoral issue we aren't left high and dry.

Rolling changes are good.

> > > - How the voting works.
>
> Above I asked:
>
> what does it mean to be rejected or approved? What voting system will we
>
> > use? Are the candidates with the highest number of votes added until the
> > team reaches capacity? Is it possible to vote *against* a candidate? Do
> > candidates require a majority to be approved?
>
> This is probably the toughest part to figure out: "How the voting works".

...  snip

Actuall I think it's not.   There is a lot of research supporting  the 
http://en.wikipedia.org/wiki/Condorcet_method and services that support it.  
It's a little complex in the theory, but actual voting is just ranking your 
preferences.

Scott K