Re: infrastructure team rules
On 16/10/07 at 09:28 +0200, Josip Rodin wrote:
> On Tue, Oct 16, 2007 at 06:31:30AM +0200, Lucas Nussbaum wrote:
> > > * Infrastructure teams are groups of developers who deal with project
> > > infrastructure and have access to resources in ways other than
> > > the standard practice of uploading Debian packages.
> >
> > Which teams do you currently have in mind? That applies to DSA,
> > obviously, ftp-master, but also well-functionning teams such as the
> > release team?
> > But it could also apply to every team that has a unix group, even if
> > it's used to maintain a very small part of Debian infrastructure.
>
> Yes. They should all have a mechanism to stop them from calcifying.
I really don't think that the qa group, the webwml group, the list
admins, etc need such bureaucracy ... According to your definition, your
proposal apply to them too (they have a unix group, and have access to
resources in ways other than the standard practice).
> > > [...]
> > > * Intervention by Debian Project Leaders is not a practical solution
> > > to resolve issues with infrastructure teams.
> >
> > Before acknowledging that, it would be great to know the status of the
> > discussions between the DPL and DSA members.
>
> Frankly, no. This is a specific instance of a problem (that may require a
> specific solution, too), but that is orthogonal to the general problem we
> have, and that is that there are no written guidelines or rules about the
> topic, so when things get broken, and fixing them requires non-trivial
> action, we get stuck in a limbo.
So your proposal aims at solving the problem at the meta level, which
might (or might not) help to solve the DSA problem ? Wouldn't it be
better to solve the DSA problem first, learn from that, and then make
sure that this doesn't happen again?
> > > * It is necessary to define a modicum of procedure for how developers
> > > can join the infrastructure teams in order to improve them while
> > > maintaining fairness towards all.
> >
> > I'm not sure that fairness towards all is even a good goal here: the old
> > team members will have to work with the new team members. We are not
> > electing a commitee, where it is good if people disagree because of
> > diversity of opinions. I'm OK with some teams being cabal-ish if they
> > work properly.
>
> I am absolutely not OK with that! A promise of fairness of teams towards
> the general developer body and vice versa is absolutely essential for each
> others to even begin to have respect for each other.
>
> I'm thinking we may not be thinking of the same definition of the word
> 'fairness'...
I'm talking about fairness in the choice of new members: teams are
likely to work better when people inside them aren't ennemies. Of
course, the "service" should be provided in the same way to all
developers.
> > > Debian developers resolve the following:
> > >
> > > [...]
> >
> > I'm wondering whether we really need all that bureaucracy. Wouldn't it
> > be possible to resolve something like:
> >
> > Debian developers resolve that some teams (pick up at least one
> > amongst DSA, ftpmaster, DAM) are not functionning properly, and
> > empower the DPL to take all necessary actions to restore normal
> > behaviour.
>
> What will that ad hoc intervention accomplish in the long run?
> Does the history of teams persistently losing activity/members
> teach us nothing?
We know we have a problem with teams losing activity/members. But we
don't know what will be the good solutions to that problem, or how to
avoid that proactively. Your proposal is just one possible solution:
maybe not the best one, and maybe it won't even work. What leads you to
think that your proposal will work better than another one?
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: