Public SourceMage Discussion List

[Eric Sandall <eric AT sandall.us>]

Quoting Andrew <afrayedknot AT thefrayedknot.armory.com>:
> On Wed, Apr 13, 2005 at 05:53:55PM -0700, Eric Sandall wrote:
> > Quoting Andrew <afrayedknot AT thefrayedknot.armory.com>:
> > <snip>
> > > I have a few questions.
> > >
> > > How are process changes accepted into the voting process? Do we vote on
> > > the changes to the voting process?
> >
> > I looked, but didn't see any documentation on this. ;0 We should probably
> > writeup a formal method for changing our policies (voting, social 
> > contract,
> > etc.). I'll write up a proposal for that and send it to the list. :)
> >
> > > For the current team leads, when does the 1 year term start/end? For 
> > > most
> > > of the team leads its already been a year since they've been in office,
> > > so assuming the above is accepted, would we wait one year for 
> > > re-election
> > > from that date, or have all the existing lead positions (except 
> > > security)
> > > open for nomination shortly thereafter? I suppose its irrelevant since
> > > at anytime someone can nominate a replacement. The first point is really
> > > a special case of the first one.
> >
> > I'd say the 1 year term starts the day the person is announced to have the
> > position. The day the term is up is when the voting should start (the
> > nominations should already be in). Should we have the voting and
> nominations
> > done /before/ the day is up?
>
> So in other words, for all the incumbant leads we'd be holding
> re-elections basically now since most of us have been in for over a
> year (which is fine with me btw, Im just wanting clarification).

I was thinking we'd be grandfathered in and our years term would start once 
this
rule is in place. Or we can have "scheduled" votes for each team lead 
(staggered
so that our "management" doesn't all go at once) and avoid having to try and
figure out when a year is up for the person. If we do go with adding limits to
terms then I'd prefer the scheduled methodology.


> > > Also, should there be some sort of rate-limiting for how often
> > > a request to vote-out someone can occur (like once a month)? The case Im
> > > addressing is if a group of two people repeatedly nominate themselves
> > > then second the nomination, thus forcing an election to ensue. They
> > > could presumably be unhappy with the results and keep renominating
> > > themselves. Of course, its unlikely that they'd win with that tactic,
> > > and the whole election process seems to take about a week (several days
> > > for nominations plus a 72 hour voting period). So maybe the problem
> > > solves itself...
> >
> > How about we say a re-election can only be initiated once a year for each
> Team
> > Lead position?
> >
>
> Seems too restrictive to me, since thats basically the term-limit
> procedure. A year is a long time...

Right, but that means that a person can only be put up for ousting once in 
their
term, and if they stay in they stay for the rest of the term. This way they
wouldn't have to continually "defend" themselves if a minority didn't like
them.

> I suppose another exploit to this process is, a crowd of people show
> up and join the development team (more than the current development
> team), then nominate some folks amoungst themselves to be team leads,
> and since theres more of them, they can effectively vote people in
> through their majority that could deliberatly sabotage the project.

> Of course, that could happen with our existing voting guidelines, but
> currently only when a lead deliberatly steps down.
<snip>

Given a large enough group no voting system stops this, that I know of.

-sandalle

--
Eric Sandall                     |  Source Mage GNU/Linux Developer
eric AT sandall.us PGP: 0xA8EFDD61  |  http://www.sourcemage.org/
http://eric.sandall.us/          |  SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/  #196285  |  http://www.shock.wsu.edu/

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.