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: Andrew <afrayedknot AT thefrayedknot.armory.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] second set of amendments to voting policy
  • Date: Sat, 15 Jul 2006 21:46:09 -0700

On Sat, Jul 15, 2006 at 10:06:05PM -0500, Jeremy Blosser wrote:
> On Jul 15, Andrew Stitt [afrayedknot AT thefrayedknot.armory.com] wrote:
> > > - More explicit language around the authority of the project lead over
> > > individual components.
> > such as?
>
> I don't really know, this is kind of open question to me. Maybe explicitly
> note the PL can act for any CL and can overrule them. Some language to
> list that the precedence is: issue vote > PL > CL. Assuming that's what we
> want. It's frankly not clear now that the PL has authority to do something
> like give a developer access to a component in place of the CL, all it says
> is the PL has "responsibility for the project as a whole".

I think its best to let things evolve on their own for now.


>
> > > + 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?

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

>
> > > +- The Mailing List used for voting is sm-discuss AT lists.ibiblio.org.
> > > +- A motion, vote, etc. reaches the Mailing List when it is accepted for
> > > + delivery by the mail exchanger for lists.ibiblio.org.
> >
> > I think we need a provision for what happens if lists.ibiblio.org fails.
> > As I read this, it would become impossible to vote on changes the policy
> > -- which would be required if a new mailing list server was necessary.
>
> First, note that this is exactly the kind of issue that could come up that
> would require the provision above this one where the PL can resolve a
> question that can't otherwise be solved.
Sounds like a candidate for the interpritations/remarks document I
mentioned in my other post.

>
> And you're right. Actually the current policy defines the list we're
> using and has the same problem. That first line shows up in the diff
> because it was moved to be by the other provision, which is the new one
> making explicit when a vote is defined as reaching the mailing list (there
> was a question if it reached the list when it reached the membership or
> just the MX).

I know it isn't new. It becomes more meaningful with the added provision.

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

>
> This should be all that's needed since even if that vote passed it wouldn't
> be active until it was published at the defined locations all developers
> can see.
>
> > >
> > > +- Issue Vote vetos are immune from the effects of the motion they
> > > apply to.
> > > - Veto votes are final.
> >
> > Can you explain what this means and the rationale behind it? Maybe an
> > example would help.
>
> Imagine the following Issue Vote passes:
> - Only Leads may vote in Veto votes.
>
> Without the above amednment, this is all that it would take for a majority
> of Leads to remove veto power from the developer community at large. The
> suggested amendment allows the community to still veto something like that.

Another good candidate for the interpritations/remarks document i suggested.

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

-Andrew

--
_________________________________________________________________________
| Andrew D. Stitt | acedit at armory.com | astitt at sourcemage.org |
| irc: afrayedknot | Sorcery Team Lead | ftp://t.armory.com/ |
| 1024D/D39B096C | 76E4 728A 04EE 62B2 A09A 96D7 4D9E 239B D39B 096C |
-------------------------------------------------------------------------




Archive powered by MHonArc 2.6.24.

Top of Page