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: Andrew Stitt <afrayedknot AT thefrayedknot.armory.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Component Lead Nominations: Tome Lead
  • Date: Wed, 20 Sep 2006 09:03:08 -0700

On Wed, Sep 20, 2006 at 04:09:57PM +0200, Flavien Bridault wrote:
> Le mercredi 20 septembre 2006 ? 08:47 -0500, David Kowis a ?crit :
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > Juuso Alasuutari wrote:
> > > I hereby nominate Matthew Clark (MaffooClock) for Web/Tome Component
> > > Lead.
> > >
> >
> > I hate to be the bearer of bad news, but a Component Lead must be
> > selected from amongst the list of Lead Developers. [0]
> >
> This rule is quite weird... I don't get the point because I don't see
> anywhere when the Lead Developers are elected.

First, before my technical explaination recall that anyone can do
the work, you don't have to be lead of the tome component to do tome
work. Being tome component lead simply grants "primary responsibilty for
and daily authority" over that component. Lacking a component lead the
defacto fallback is the lead developers. They are going let whomever
is doing the work continute to do the work. Anyone who wants access has
been given access as far as I know. In other words, Matthew already has
control over docs by default because he's the only one actively working
on them anyway.

Most of the lead developers were elected here starting here:
https://lists.ibiblio.org/sympa/arc/sm-discuss/2006-May/014326.html

The relavent line from the policy[0] (which we all voted for) reads:
Project and Component Leads:
* are elected from among the Lead Developers by a simple majority
vote of the General + Lead Developers.

New lead devs can be elected at any time:
Lead Developer Votes:
* A General Developer MAY be nominated for Lead Developer at
any time by any other Developer


The cauldron component lead vote was postponed so people had an opportunity to
elect more lead developers[1]. There is a precedent for postponing if people
really want to elect matthew, or any other candidate who isnt already
a lead.

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.

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.

Also recall it is difficult to remove a component lead. Its written in
the policy that we can do it, and written in the policy before that. But
it has never happened, doing it is generally a politically bad thing anyway.
Once they're in, they're in.

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

-Andrew

[0] http://www.sourcemage.org/DeveloperOrganization
[1] https://lists.ibiblio.org/sympa/arc/sm-discuss/2006-May/014327.html
[2] http://www.sourcemage.org/VotingPolicy

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

Attachment: pgpiQ7gqxCpkT.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page