[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Technical committee resolution

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

>         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.


Attachment: signature.asc
Description: Digital signature

Reply to: