On Sun, Mar 23, 2008 at 07:28:37PM +0100, Christoph Berg wrote:
> Re: Josip Rodin 2008-03-22 <[EMAIL PROTECTED]>
> > I've been composing a proposal regarding how Debian's infrastructure teams
> > operate. It would be a good idea if the interested members of teams take
> > a look at it and contribute their insight.
> >
> > The last version of the text is at:
> > http://lists.debian.org/debian-project/2007/10/msg00142.html
>
> Isn't that overly generic and overly complicated at the same time?
> Which specific existing problem does it attempt to solve? (I.e. which
> problem do you expect to be easier to solve post-GR?)
I guess I should do a bit of summarization, because it's probably
unreasonable to expect everyone to read another 100 messages of the previous
threads...
The present situation is such that the DPL probably has authority to do
all sorts of things with a typical infrastructure team, but typically
it's been hard to get the leader to do anything much in that regard.
Which is fine, really, because most teams work just fine without any
intervention by the leader. However, occasionally we need to have the
option of someone doing something when things become dysfunctional for
some reason. For package maintenance, we have some established procedures
in these cases, but for infrastructure teams, it's pretty sketchy to say
the least.
This proposal tries to set some ground rules - first off, introducting
many concepts that may or may not all be known to everyone, and declaring
how we don't want to screw with things that work. However, things that don't
work, such as teams which become stale, can be monitored and nudged by
the leader, even if the time frames and obligations are very lax and
usually flexible.
The proposal isn't meant to be inclusive - it allows changes in team rosters
to be made the old way, in an attempt to avoid causing new problems.
It doesn't enumerate all possible reasons and rationales when some change in
team composition would be necessary - it can't really attempt to do all
that. We can and should try to tackle the most apparent problem now - the
teams which idle too much. If we see other unforeseen problems later on, we
can have another general resolution once we have the right information.
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
