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 <[EMAIL PROTECTED]>
>
> 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 <[EMAIL PROTECTED]> wrote: > > Good Morning, > > > > On Fri, 23 May 2008 19:26:40 +0200 > > > > Stefan Potyra <[EMAIL PROTECTED]> 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 -- Ubuntu-motu mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
