Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Component Lead Nominations: Tome Lead

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] Component Lead Nominations: Tome Lead
  • Date: Wed, 20 Sep 2006 13:08:57 -0500

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




Archive powered by MHonArc 2.6.24.

Top of Page