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

Re: Technical committee workflow

On Wed, Dec 31, 2008 at 05:35:48PM +0000, Ian Jackson wrote:
> But having thought about it some more I think that part of it might be
> a problem of the psychological dynamics of committees.  We all have
> joint responsibility and that means that sometimes we all do nothing
> and sometimes we all nitpick.

> I have an approach which I'd like the committee to consider trying as
> an experiment:

>  * When an issue comes in, the first TC member to get to it and claim
>    it becomes primarily responsible for it.  We'll call them the
>    Rapporteur.

Having designated committee members be responsible for shepherding
individual issues is a good idea.  I believe we were at least nominally
trying this at one point; I'm not sure if any of the issues assigned this
way were followed through to completion, but none of the bugs currently on
http://bugs.debian.org/tech-ctte appear to have bug owners, which ought to
be part of the procedure if it isn't already.

>  * The Rapporteur discusses the issue - off the main TC list - with
>    the various parties.  debian-devel might be a good place, with
>    an initial CC to other lists and the bug of course.  Other TC
>    members could participate there if they had time available.
>    Other Developers could show their usefulness as future TC
>    candidates by their contributions to these discussions.

I also think this discussion should take place in the bug report, which is
subsequently proxied to the TC list.  The full rationale should be readily
available for inspection, whether or not other members of the TC have time
to participate in the discussion.

>  * The Rapporteur would issue a report which explains
>      - relevant facts
>      - the arguments made by all sides, including those
>        arguments the Rapporteur rejects
>      - the Rapporteur's conclusions
>      - a decision about what should happen and a timeframe
>    and if they don't do this within 14 days then they can be
>    relieved by any other TC member.

I don't know that a 14-day time limit is all that much of a stick.  Why is
this better than letting members pass on bugs in an ad-hoc manner when they
need to?

> We'd have to have some rule to avoid a fast-replying TC member from
> getting all of the business: perhaps, if you're the person who took
> the last issue, you must wait 72 hours before claiming a new one; if
> you're the person who took the second-last one, you must wait 48
> hours.

Why?  Surely if a member of the committee is able to resolve these issues to
everyone's satisfaction, there's no need to rate limit?

For the most part I think the workflow described is reasonable, but no
amount of good process will make up for TC members simply not spending time
on the outstanding issues.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Reply to: