Re: infrastructure team procedures (fourth edit)
On Tue, Oct 30, 2007 at 02:11:48PM +0000, Ian Jackson wrote:
> I'm sorry to come into this at this late stage but I have a couple of
> questions.
Well, it might be late for the pace I'm hoping for, but really, it's only
been two weeks in discussion :)
> The first is: have you, as the person driving this process, made sure
> to bring it to the attention of the current infrastructure teams and
> ask their opinions ? Do they basically approve or disapprove ?
I haven't done any explicit scouting for opinions now. I suppose another
mail to teams listed in www.d.o/intro/organization couldn't hurt.
> > * If the team fails to make any additions or removals as described above,
> > the Debian Project Leader is allowed to do the minimum required additions
> > instead. The Leader decides the validity of candidates according to
> > the procedure described above, adds new team members and communicates
> > that decision to the developer body. Such new team members can also be
> > rescinded by the Debian Project Leader, unless they get confirmed
> > as valid and accepted into the team by team consensus.
>
> The second question is: who gets to decide whether the team have
> `failed to make any additions or removals as described above', and
> what exactly does this phrase mean ? Whose opinion is relevant for
> deciding what the `minimum required additions' are ?
Well, the DPL. All points of contacts are either the DPL or the developers
in general (in that order), so these two would be able to respond.
The DPL can respond by decision and the developers can respond by a GR -
obviously the former is a much more sane default, I hope we don't have to
explicate that.
> * A team has not `failed to make any additions or removals' if it has
> changed its composition at all (over some relevant period - what
> period?).
The relevant period is the one for which actions are defined, and that is
two years.
Note that I'm implying here that because this will be decided by a GR,
hopefully with a broad consensus, the time periods aren't future, i.e.
the most basic requirements would be applicable retroactively.
I pondered at one point if this should be made explicit, but forgot to
post anything about it.
> If a team therefore changes its composition, the DPL
> cannot act even if the DPL feels that the changes were not `as
> described above' or not adequate to meet the described goals.
You didn't quote that clause fully. It says "if the team fails to make any
additions or removals as described above". The "as described above" part is
integral, it's not logical to disconnect it and make it optional, is it?
At the same time, yes, the team can change its composition on its own
(that's another one of those rules defined above) during a two year period,
so a "rogue" team could e.g. remove an old member and add a new member who
would perpetuate the... rogueness :) But that kind of a thing can't be fixed
without making the whole thing much more intrusive, and I didn't want to
make it overly intrusive because IMHO we don't need anything more intrusive
than this.
--
2. That which causes joy or happiness.
Reply to: