On Mon, Mar 10, 2008 at 01:00:08PM -0500, Manoj Srivastava wrote: > On Mon, 10 Mar 2008 17:49:02 +0100, Joerg Jaspert <joerg@debian.org> said: > Where is the use case for added churn and loss of institutional > memory? Old members can advise new members if they wish, and new members can read the public archives of previous deliberations. There's no need to lose any institutional memory here. (The same thing happens with the Project Leadership hat -- old DPLs who're still around offer advice to the new DPL, who then gets to decide whether it's good advice or not, without having to worry about being accused of backflipping or hypocrisy when trying something different to previous DPLs) > With new members added routinely, is there any mechanism to > ensure the new members are indeed technically competent, and not just > chums of the DPL? Yes: there's the DPL elections, where prospective DPLs have to explain their ideas and defend them; there's also the ease with which the DPL's decisions can be delayed and possibly overriden by general resolution; and there's also the regular turnover in DPLs, ensuring that one group of friends won't monopolise ctte appointments without the project's ongoing support. Is there any mechanism to ensure new members are currently technically competent, and not just chums of the current committee? Or to ensure existing members remain competent over the five or ten years they remain members? > Are these changes actually addressing the problems or > dysfunction of the tech ctte, or we just making chnages for changes > sake? Which particular dysfunction is being addressed? Do we have > reason to believe that churn will solve that dysfunction? Having the same people doing the same job year in year out blocks innovative changes in two ways: first, if you're going to do the same thing over a long period you develop habits: things happen the same way, so you stop thinking about them, and there's no chance for them to change even if they're not great. Second, once you've tried doing something, if it doesn't work, you tend to still be psychologically tied to it and thus resist making big changes later, even if they'd be necessary. > Why is the DPL the proper mechanism to bring forth this change? The technical committee is the *wrong* group to do it, because that makes external input impossible; the only other options are the DPL, or project wide vote; and DPL appointment's a lot easier and backed by an annual vote anyway. Cheers, aj
Attachment:
signature.asc
Description: Digital signature