Public SourceMage Discussion List

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

On Jun 27, Andrew [afrayedknot AT thefrayedknot.armory.com] wrote:
> On Tue, Jun 27, 2006 at 12:56:29PM -0500, Jeremy Blosser wrote:
> > On Jun 27, seth AT swoolley.homeip.net [seth AT swoolley.homeip.net] wrote:
> > > Restating my motion for clarity:
> > > 
> > > Stable grimoire release can be approved one of two ways.
> > > 
> > > Way one is for a unanimous vote of the following team members:
> > > Project Lead
> > > Grimoire Lead
> > > Grimoire QA Assistant
> > > 
> > > Way two is for a vote of the General Leads as per the existing issue
> > > vote procedures, however this is expected to be done only in the case of
> > > an absense of one of the above team members (although, technically an
> > > issue vote may be brought for any reason).
> > > 
> > > This shall be entered into the record of Administrative Policies and
> > > effective upon its passing.
> > 
> > When this vote is called I'll vote -1 on it, because:
> > 
> > The current policy is that the Component Lead over Grimoire (Arwed) makes
> > the decisions for his component, but can be overruled by an Issue Vote.
> > All we really need to do to make a release right now in his absence is an
> > Issue Vote.  If that's what we want to do, we can call that vote without
> > needing to implement new policy.  Our stated goal in setting up this 
> > voting
> > system was to provide a way to move things forward if discussion wasn't
> > doing it, but to my knowledge there's been no discussion of this one prior
> > to a motion to amend policy.
> 
> A stated goal of the policy is to have redundancy. That said, any issue
> can be taken to the floor for a vote, such as a vote to release the
> grimoire. All this does is solidify and explicitly specify what could
> already be done. I think for the sake of clarity and transparency it
> should be specified. Its obvious this doesnt change anything, so theres
> no reason to vote no on it other than because it adds an explicit special
> case to our policy.

To the last point you made: "Its obvious this doesnt change anything, so
theres no reason to vote no on it other than because it adds an explicit
special case to our policy," let me narrow this to clarify what I'm
objecting to.  This:

> > > Way one is for a unanimous vote of the following team members:
> > > Project Lead
> > > Grimoire Lead
> > > Grimoire QA Assistant

is definitely new project policy.

1) We do not have an official positiion of "Grimoire QA Assistant" that I'm
aware of.  Arwed is of course free to name any such position at will, but
including its existence in project policy dictates that we always have
that position filled or we can't do a "normal" release (or else we amend
project policy again later on).

2) The existing project policy makes the grimoire component lead the
authority over their component and lets them set release times and
policies.  This dilutes that, explicitly dictating how the grimoire lead
can do releases by default.  I don't believe we need this dilution.  If a
component lead fails in their duties we have the Issue vote to fall back
on, but this "way one" changes even the default release procedure.


Note, I don't object to Arwed making either of these the way he works.
That's his area.  I do object to making them project policy, because it
ties the hands of the component lead and tells them how to run their show.
It's micromanagement.


To the questoin of redundancy, again, that's why we do have the Issue vote
to fall back on.  If we need to clarify we can use that for releases or
something, we can try to clarify that.  But it's the dictating of default
policy to the component leads that I primarily object to.

Attachment: pgpUjHCzE3Jiw.pgp
Description: PGP signature