Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] second set of amendments to voting policy

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Jeremy Blosser <jblosser-smgl AT firinn.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] second set of amendments to voting policy
  • Date: Sun, 16 Jul 2006 01:07:17 -0500

On Jul 15, Andrew [afrayedknot AT thefrayedknot.armory.com] wrote:
> On Sat, Jul 15, 2006 at 10:06:05PM -0500, Jeremy Blosser wrote:
> > On Jul 15, Andrew Stitt [afrayedknot AT thefrayedknot.armory.com] wrote:
> > > > + the interpretation motion. If more than 50% of the Lead
> > > > Developers move that
> > > > + a question of interpretation cannot be resolved with an Issue
> > > > Vote, the
> > > > + interpretation WILL be determined solely by the Project Lead
> > > > without
> > > > + possibility of veto.
> > >
> > > Can you explain the rationale behind this? why is it necessary?
> >
> > It prevents the project deadlocking if some weird question of
> > interpretation comes up that can't be decided non-recursively. We can
> > hope
> > we provide for everything well enough to not run into those, but we can't
> > know we have everything perfect. If something does come up this provides
> > a
> > short-circuit way to skip the deadlock and let the PL just decide. This
> > kind of thing is generally required for projects that want to incorporate
> > some way (as a non-profit or otherwise).
>
> So as a hypothetical example, say the voting process itself is contested
> and thus we cannot vote on how to rectify it, we can have the PL make
> some decision so we can move forward?

Yes. As long as a majority of leads agree that's what has to happen to
resolve it (and they only have to "move", ie agree, they don't have to
actually vote on it since that may not be possible).

> I'm not entirely sure I understand "can't be decided non-recursively",
> I think examples might solidify it for others (not suggesting to put
> examples in the wording, but for the benefit of those voting on this).

I agree examples would help but if we knew parts of the policy were open to
this kind of thing we'd fix them. :-) But suppose we were foolish and set
up the policy so that a majority was defined as "50%". Then suppose we had
12 leads, and 6 voted yes on a motion, and 6 voted no. The policy wouldn't
be clear on who won. We could try another vote to clarify it, but maybe
that would result in the same 6/6 split. We could keep trying a vote to
resolve the previous vote but it wouldn't be likely to go anywhere but
infinite recursion. So this would allow the PL to just resolve it. (This
example is flawed because it specifically talks about the question of a
majority and the solution itself requires a majority, but it's just an
example and we don't have that problem of mis-defining a majority.)

> > Anyway, we can add another line something like:
> > - An Issue Vote which would ONLY change the Mailing List used for future
> > voting MAY be moved, seconded, and voted on in any medium accessible by
> > a
> > simple majority of Project Leads.
>
> You mean lead developers?

Yes.

> > (Note this is only making explicit what was the original intent, so it's
> > not clear if the existing policy has this problem, but the amendment
> > removes the question.)
>
> Yes, I think its better to be explicit. I have an aversion to appealing to
> original intent, I dont know your intent when you drafted this, if
> something was intented a certain way, it should be recorded somewhere.

I don't disagree.


As for the other stuff, I'll try to make time for a PolicyFAQ or something.

Attachment: pgpJyeo2l4CGV.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page