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: Sat, 15 Jul 2006 22:06:05 -0500

On Jul 15, Andrew Stitt [afrayedknot AT thefrayedknot.armory.com] wrote:
> I mostly agree with these ammendments, but want to make sure I understand
> them, commentary inline below.
>
> On Sun, Jul 09, 2006 at 01:41:35PM -0500, Jeremy Blosser wrote:
> > Things not in this diff that we may want to add (these have had some
> > discussion already, but not as much consensus):
> > - A provision for changing votes on issue votes before the vote ends.
>
> This appears to be in the diffs below
> +- Votes MAY be changed before the scheduled end of the vote by
> notification to
> + the designated email address.
> Also, that wording is not clear on voting for leads, issues, or both.

The quoted section is under the section with the heading "Lead Voting
Process" (that's noted in the diff but maybe not in the most obvious way).
So that quoted bit would allow changing votes for leads, but not issues.
Hence the open question of do we want to allow changing votes on issues.

Rationale for *not* adding changing of issue votes even if we add changing
of lead votes would be that only Leads are voting on issue votes, and it's
arguably more reasonable to expect them to have thought something through
before voting on it. Also, lead votes last for a defined time and cannot
end early, while issue votes can end early. Issue votes were given this
property so that they could be used to decide issues quickly when necessary
instead of dragging out for weeks. Again, the assumption is that we can
expect more of Leads, eg if it's appropriate to vote quickly on something
(like the previous amendment to fix the definition of "majority") or if
they should hold their vote to the end. If we allow changing issue votes
we'd necessarily lose this property since votes would have to always go
their full run so they could be changed.

> > - More explicit language that issue votes can be used to decide things for
> > component leads who are absent.
> What are the possible downsides of enacting this?

It's superfulous language -- the argument for adding it isn't that the
existing policy doesn't cover these cases, it's that these cases aren't
explicitly listed. The more language we add the longer the policy gets and
the harder it is for people to understand what's going on.

I'd frankly argue we already have more language than most can hold in their
heads given the number of times people have said "we need to handle this"
and I've pointed out the section that handles that which they didn't know
was there. It could be argued what we have is somehow not clear or simple
enough and that's the reason for this, but so far the response has just
been "oh I didn't know that part was there". I think it would be prudent
to let people get a bit more used to how the processes work before adding a
bunch of explicit cases to the policy docs themselves.

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

> > +- The Project Policy supercedes all other published or practiced Source
> > Mage
> > + policies.
>
> Just seeing if I understand this. The rationale here is to prevent for
> example, a component lead from creating a policy that says that he can
> do whatever they want regardless of issue votes?

Yes. If some other practice or doc conflicts with the Project Policy, the
Project Policy always wins. Since the Project Policy defines core things
like who the developers are and how decisions are made, this protects the
interest of the developers from being "routed around".

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

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

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

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.

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.

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

Attachment: pgppIZvfM8iyS.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page