Public SourceMage Discussion List

[Jeremy Blosser <jblosser-smgl AT firinn.org>]

On Sep 20, Andrew Stitt [afrayedknot AT thefrayedknot.armory.com] wrote:
> Although in this case thats almost irrelevant because there are no
> other candidates, and lacking any candidates there wont be component
> lead election. However from the voting policy[2]:
> 
>     Project and Component Lead Votes:
>         If at ***any time*** a Project or Component Lead position is empty
>         (due to lack of available candidates, etc.), the Project Lead
>         (or any Lead Developer, in the case of a Project Lead vacancy)
>         MAY schedule a new vote for a temporary Lead to fill the position
>         until the next scheduled election. The vote will continue as
>         described above.
> 
> *** added for emphasis
> 
> In other words, lacking any candidates, we'll just hold the election
> later when matthew (or anyone else) is eligable.

Exactly.  It is unfortunate we'll be without a Tome Lead for a bit, but we
have a means to fill the position at any time once it is vacated.  If
people want to get Matthew in there, nominate him as a General Lead.  If he
wins that election he can immediately be nominated as Tome Lead, and the
entire process should take less than a month.

> So, thats why I think this isn't a big deal. What follows is why I think
> we have the rule in question.
> 
> <disclaimer>
> Before you read this digression, please be aware that none of this applies
> directly to Matthew, I think Matthew is a fantastic developer/writer. This
> is written from more of an abstract viewpoint and should not be taken
> personally by anyone.
> 
> The reasons below may not be the officially endorsed or intended reasons
> for the policy wording. These are some of *my* reasons agreeing to the
> wording in the policy.
> </disclaimer>
> 
> One reason for the rule is to prevent people walking in "off the street"
> and getting elected. This has happened in the past. We've had
> multiple "lame-duck" leads, who got elected and then proceeded to do
> nothing. Simply holding the position leaving the team's workers without
> leadership.

FWIW, the original intent when I wrote it that way was more pragmatic than
anything.  We were primarily dealing with the issue of letting developers
self-select between those that wanted a vote and those that didn't, and
once we did that it only made sense to have component leads get elected
from the former group instead of going directly from a non-voter to a full
component lead.  But what you note is an (intended) side effect, and an
important one because...

> Consider instead of a lame-duck lead someone off the street with
> malicious intent. They get elected and then proceed to subtly damage
> our distribution (say they're from a competing distro and they just
> can't quite seem to fix that rm -rf / bug). This sort of event would most
> likely follow 1) a general popularity surge 2) an exodus of developers
> from a competitor to our developer pool. Its easy to become a general
> developer (intentionally so). Requiring that extra step provides a
> barrier of entry to a hostile takeover. (Again Im not saying that will
> happen here, but it could happen).

...this has happened to other distros, and is not just theoretical.  It's
important we protect ourselves against it, as we have.

Attachment: pgpew7DrEc0Qh.pgp
Description: PGP signature