Re: [RAI] RAI processes for handling work effectively

Harald Alvestrand <> Sun, 28 July 2013 10:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC4D721F9E3F for <>; Sun, 28 Jul 2013 03:32:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7qkaKy-zLHO8 for <>; Sun, 28 Jul 2013 03:31:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CCB2521F9E27 for <>; Sun, 28 Jul 2013 03:31:57 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 535AD39EEE2 for <>; Sun, 28 Jul 2013 12:31:53 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GT7-YxebiGAy for <>; Sun, 28 Jul 2013 12:31:52 +0200 (CEST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 37CE139EC67 for <>; Sun, 28 Jul 2013 12:31:52 +0200 (CEST)
Message-ID: <>
Date: Sun, 28 Jul 2013 12:31:50 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [RAI] RAI processes for handling work effectively
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 28 Jul 2013 10:32:02 -0000

On 07/28/2013 10:48 AM, Martin Thomson wrote:
> On 27 July 2013 11:49, Harald Alvestrand <> wrote:
>> All of this points to a need for careful review. What it does not point
>> out is any need for a *slow*, *inconsistent* and *unpredictable* review
>> process - which is what I feel the "standing working groups" are giving
>> us now.
> Isn't that just a natural by-product of using SDP, with all that
> baggage Hadriel describes?

Well - I could have made a lot of the same comments about AVTCORE and
the RTP issues we are facing, but MMUSIC just felt like a more current
example :-)

> I don't think that you get any better review if you make new working
> groups.  In fact, you get even slower, less consistent and possibly no
> review at all.  One virtue of the long-standing working group is that
> over time it accumulates a following of people who know stuff about
> the work.  I saw this with the DHC WG, which was actually invaluable
> when it came to bringing work there.
That's where my thinking about review teams, directorates and other
possible constructs comes in. I think one core point here is that for
any question asked, there needs to be some identified "someone" who's
charged with coming up with "the answer" (or "the information needed to
make sense of the question") - and is able to do so on a relatively
short timeframe.

Quite hard to achieve consistently in a volunteer organization, but I
don't think it's impossible to try something that might work better than
the WG format.

> Again, not an indictment of your thesis about more focused working
> groups, just an observation about this particular problem.
> _______________________________________________
> RAI mailing list