Public SourceMage Discussion List

["Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>]

On Apr 18, Eric Sandall [eric AT sandall.us] wrote:
> 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)?

It keeps the veto in the hands of the majority of the full project, which
is the real point.  There's no need IMO to create an artificial check that
says the non-leads always have to have final say even if they are a small
minority of the whole project.  That's treating it like a regular
representative system, and as Seth has pointed out that analogy only goes
so far.  That kind of approach only makes sense when you know that the
ratio of non-leads to leads is going to be > 1.  We don't know how that
ratio will end up for us, and it's probably unduly complicated to make the
policy adapt based on the current ratio when we can just clarify the
overall policy to match the intent: leads want and earn more of a say and
responsibility, but the full project retains the final veto of how things
are run and by whom.

> 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.

Right, it means the veto doesn't exist as soon as there are more leads than
non-leads, and that's not the point.  The veto always exists and is
primarily a way to add the non-lead votes in for a count of the entire
project.

Attachment: pgpKxG6f8hgjn.pgp
Description: PGP signature