Re: infrastructure team rules
On 16/10/07 at 14:46 +0200, Josip Rodin wrote:
> 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? :)
Do you think that the reason why the website isn't changing is because
there's a lack of new team members in webwml?
> 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...
s/luck/reasonable decisions from intelligent people who didn't need
another level of bureaucracy to take those decisions/ ?
> > > 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?
The "statu quo proposal", i.e "things aren't that broken in most
teams, we can just solve problems in an ad-hoc fashion where problems
occur" ?
> 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.
My point can be summarized as "do we need a deterministic method or
proposal to solve problems inside teams?" Aren't you trying to find a
technical/bureaucratical solution to a social problem?
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: