Re: infrastructure team rules
On Tue, Oct 16, 2007 at 06:53:26PM +0200, Lucas Nussbaum wrote:
> > 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?
TWAJS.
But let's give it some thought - webwml has many members, but that's a
*group*, not a *team*. debwww is the Unix group that designates the web
team, and that one hasn't significantly changed in years.
> > 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/ ?
How do you know you have those people, and what do you do when you don't? :)
> > > > 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" ?
Judging by history, I don't think our current approach is exactly
flourishing. We've mentioned sysadmins, list admins, web admins, all of
those had breakages. We haven't mentioned bug admins, ftp admins, docs
admins, key admins, account admins, but all of them had fairly major
issues too. It's hard for me to recall any other major infrastructure
team in Debian where I can point and say that they have always functioned
fine, i.e. they only had technical issues (rather than manpower issues).
> > 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?
A solution where you empower more people to do things and make processes
transparent should be a social solution, I don't know why you'd think that
those things are just bureaucratic technicalities.
Indeed, perhaps the calcification of teams stems from people having the view
where a deterministic approach to social organization is frowned upon,
because that serves as a general excuse, and so things end up falling
through the cracks. "We're all buddies here. Writing things down is
bureaucracy, screw that. We can solve any problem on the fly. Except when
we can't." :)
--
2. That which causes joy or happiness.
Reply to: