Re: infrastructure team rules
On Tue, Oct 16, 2007 at 02:29:08PM +0200, Lucas Nussbaum wrote:
> > > 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).
Well, let's put it this way - do you think that the hordes of people anxious
to see changes in the design of the web site think that we should keep the
webwml group as it is? :)
Seriously though, let's examine a more pertinent example - the listmaster
team needed such bureaucracy a while ago, as you can see from the recent
announcement. We had numerous latent members - I'm one of them :) and it
took a fair few years to make significant progress. The change came from
within in that case, but that was practically a stroke of luck. The project
infrastructure shouldn't depend on luck...
> 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?
But with DSA, we're way beyond learning anything new, aren't we? :)
> > > 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.
Well, they can discard candidates that they think are "enemies" using this
process. They can mark them invalid, explaining how they are enemies,
and that's fine. :)
> > 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?
Well, what other proposal is there?
We have different kinds of practices in place, but I'm not aware of any
other deterministic methods or proposals for unblocking teams that are
already blocked up.
--
2. That which causes joy or happiness.
Reply to: