Public SourceMage Discussion List

[Seth Woolley <swoolley AT panasas.com>]

Eric Sandall wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tue, 18 Apr 2006, Jeremy Blosser (emrys) wrote:
>
> > On Apr 17, Jeremy Blosser (emrys) [jblosser-smgl AT firinn.org] wrote:
> >
> > > That's the summary of this proposal, and I think it's accurate.  The full
> > > docs are attached.
> >
> > A couple of things have come up in discussion:
> >
> > - A fatal flaw, if we have eg 23 developers and 20 of them are leads and 3
> > of them are not, 2 of the 3 non-leads have all the veto power.  To fix
> > this, I'm amending the proposal to allow leads to vote in vetos.  The
> > intent of the veto is to allow a super majority of the full project to
> > overrule the leads, so I think this is appropriate.
>
>
> While this would mean that if general developers are in the minority
> they won't get to dictate decisions for the majority, doesn't it
> remove the general developers' veto power by adding the Lead votes
> (whom have presumably already voted in a way that the general
> developers did not want)?
>
> Perhaps adding a clause that veto votes require at least 51% of the
> total number of developers (lead + general) to be valid, though this
> means that if the general developers are at all in the minority no
> vetos would ever pass, which is almost the same issue as above.

This would be true if leads voted 100% the same way.  The idea is that 
it may be controversial and 51% of leads vote for something -- when you 
add in general developers who may be 100% opposed to that, you can enact 
a veto.  A veto isn't supposed to be able to overturn any possible 
decision, just the narrow and controversial ones.  Typically a body can 
immune itself from a veto in code, like how congress can override a veto 
by passing an item by supermajority.  (That's normally how vetos are 
done where you have a huge variation in the number of persons in the 
balancing powers (president versus the entire congress), which we don't 
need because we are already honoring one person one vote, but merely 
increasing the franchise when needed).

Seth

> > - Removal Votes require a super majority to pass.  This is so that Leads
> > can't just easily throw out a new elected Lead they don't like that the
> > General Developers have elected.  However, it means that if someone comes
> > up for a removal vote through inactivity, it would still take a super
> > majority to confirm their removal.  To fix this I'm amending the proposal
> > so that the automated removal votes *pass* unless a simple majority votes
> > opposed to them.
>
>
> Sounds good.
>
> Thanks!
>
> - -sandalle
>
> - --
> Eric Sandall                     |  Source Mage GNU/Linux Developer
> eric AT sandall.us                  |  http://www.sourcemage.org/
> http://eric.sandall.us/          |  SysAdmin @ Inst. Shock Physics @ WSU
> http://counter.li.org/  #196285  |  http://www.shock.wsu.edu/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
>
> iD8DBQFERRltHXt9dKjv3WERAkl6AJ41tx6Z0+IYIW9qE0JhBzW5c2AcTgCePart
> FQ5c+5hKe6K+ViSIqwS+2os=
> =Ynul
> -----END PGP SIGNATURE-----
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss


--
Seth Alan Woolley
Software Engineer
Accelerating Time to Results(TM) with Clustered Storage

www.panasas.com
swoolley AT panasas.com
510-608-4382