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 | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
