Re: [RAI] Making RAI work better

[Dan York <[e-mail]>]

Being a relative newcomer to the IETF process in that I've only been  
attending IETF meetings for the past couple of years, I have to second  
Adam's comments here (and also say that it gave me quite a laugh).

At the first IETF I attended, IETF 66 up in Montreal, I was rather  
amused to see that as I travelled around from WG to WG in what would  
become the RAI Area, it was basically the same people attending the  
same WGs... more or less the same people standing up in front  
presenting the slides... essentially the same people standing up at  
the microphone asking questions or debating points... and some of the  
same people at the tables as chairs.  From reading the mailing lists,  
I had gathered a sense that there was a small core of folks who were  
the most actively involved, but it wasn't until attending a meeting  
that I realized just how many of folks from one RAI WG were just as  
active in almost every other RAI WG.  (And yes, in subsequent  
meetings, I, too, have been one of the "RAI groupies" who travels from  
room to room to whatever the current RAI group is, and who stands up  
at the microphone or is in the Jabber chat room.)

Having long been involved in leading various volunteer nonprofit  
organizations, I've definitely learned that you seem to inevitably  
wind up with a core of maybe 20% of the volunteers doing probably 80%  
of the work.  It just seems to be a fundamental part of human nature  
in organizations.  The tricky part is scaling and growing that core as  
the workload and agenda of the organization grows. Or in Adam's terms,  
growing the number of CPU cores.

It does seem like the "RAI" area is "CPU bound". And I think as more  
and more people in the wider industry want to do more and more with  
SIP, there are only going to be *increasing* demands on the RAI group  
as a whole.  I agree with comments flowing in that there are probably  
several steps we need to take:

1. RE-ORGANIZING/FOCUSING WGs - I agree with Deans' points that many  
of the existing WGs have become so large and are taking on so many  
issues that they *can't* adequately address all those issues. I think  
we do need to re-org into WGs that have smaller, focused, *attainable*  
charters, where WGs can start up, bite off an attainable bit of work,  
accomplish that, and then shut down. (And yes, I realize that sounds  
rather idealistic.)

2. FIGHTING WG SCOPE CREEP - Part of that would seem to require trying  
more to limit the "scope creep" of the WG's activities. Perhaps  
limiting discussion at meetings to (gasp!) only documents on the WG  
charter or those that, through mailing list debate, are viewed as  
strong candidates to be on the WG charter - rather than what often  
seems to be whatever documents WG members feel need to be discussed.

3. RECRUITING CO-AUTHORS - As Adam indicated, the pool of "key  
participants" who write the documents, champion the documents, etc. is  
rather small.  Yet at any meeting I've been at, any of the RAI WGs  
usually have 100 or more people in the room (sometimes many more than  
that).  Could there not be people out there in that group who could  
assist in this?  If there are key participants trying to handle 4 or 5  
major documents (or 10 or 12), could there not be a way to spin some  
of those out to other people to champion?  Yes, it would mean the  
document author would have to "let go" a little bit and let someone  
else in.  Yes, that new person might need time to come up to speed...  
but in the end might the result not be more people being able to work  
on more documents? (And as a bonus, the "key participant" might be  
able to better focus on the documents he/she is most interested in.)  
Could we somehow find a way to recruit more co-authors?

4. RECRUITING CO-CHAIRS - Similarly, could we find a way to recruit  
more co-chairs?  Dean and any number of the others in this thread have  
talked about the blocking going on by the lack of administrative  
resources.... about the fact that  chairs have too high a load.   What  
skills are we seeking in co-chairs?  I've often seen in the past that  
the skills that make someone an excellent chair/facilitator/group- 
leader are not necessarily the same skills that make someone an  
excellent technical leader (or document developer).  Out of the 100s  
that attend RAI sessions, could we find some folks there with great  
facilitation/administrative skills who can take on co-chair roles?   
Perhaps they would not have the deep technical knowledge (or have  
authored multiple RFCs), but they may be able to run WG sessions and  
mailing lists in professional manner and move the agenda along.  I  
realize that this, of all the items here, may be the hardest to  
consider as there is a certain understandable amount of prestige  
associated with being a "WG Chair".  Still, it may actually be one of  
the easier ways to bring people in and increase the size of the RAI  
core.  There's also the fact that if you create *more* RAI WGs that  
are smaller and more focused, this would provide an opportunity to  
bring in more co-chairs... and partner veteran co-chairs with newer  
participants.

I don't see the demand from the outside industry decreasing... the  
good news is that after 10 years SIP is finally getting some serious  
market attention... and more and more uses are being found for it -  
many of which then feed back into needing some standardization in some  
way.

I think ultimately RAI *does* need to figure out how to grow the  
number of key participants and, in Adam's terms, increase the number  
of CPU cores.

Separately, though, I think Adam has another point toward the end in  
that all of these various working groups *are* increasingly  
interconnected.  The reason we all are RAI groupies that move from WG  
to WG is that in many ways the issues of one WG do in fact relate to  
those of another (in many cases, anyway).  Perhaps a re-org like what  
Dean suggests could help reduce this inter-WG interconnection.   
Perhaps not.  Perhaps it's just an inherent part of RAI and we have to  
figure out some way outside of cloning the ADs to keep the different  
WG's in sync.

My 2 cents,
Dan



On Sep 30, 2008, at 10:31 PM, Adam Roach wrote:

> I think the problem is that we're constantly increasing the number  
> of threads (documents) we're working on, while the number of CPU  
> cores (key participants) remains fairly constant. We're CPU bound.  
> Increasing the number of processes (working groups) so that they can  
> each have fewer threads in them (but still the same number of  
> threads overall) doesn't change the fundamental problem that we're  
> simply out of CPU cycles.
>
> Given that we don't know how to increase the number of processor  
> cores, the only thing we can usefully play around with is thread  
> scheduling. Do we throw all the threads on the processor cores at  
> once, so that they all make progress all the time, but take five to  
> ten years each to complete? Or do we strictly limit the number of  
> threads so that each one completes fairly rapidly and gets out of  
> the way for the next one?
>
> I think the latter approach would be far more productive. When I  
> move between work items, I know I have to swap information back into  
> my head to just have the context to think about the related  
> problems. For the past few years, most of my IETF work has been  
> characterized by thrashing, in which I spend much more time re- 
> learning the context for a piece of work than I do actually thinking  
> about the problems related to that work. This is 100% because  
> there's too much going on, and it's all too tightly interconnected  
> to focus on small niches.
>
> Robert has pointed out that we can never say "no," only say "not  
> now." I agree with this statement; however, I would go one step  
> further to argue that we don't even say "not now" nearly often  
> enough. And we've become highly inefficient for it.
>
> /a
>
> Dean Willis wrote:
>>
>> The main problem we have with RAI is that some of our working  
>> groups have dozens of documents. Both the brainspace of the WG and  
>> the attentions of the management team (aka, Keith and I, for SIP)  
>> are  consumed with swapping between documents trying to give "fair"  
>> treatment to all. Hence, the urgent is balanced against the  
>> important, and we end up more and more fragmented.
>>
>> We have huge, eternal working groups that don't focus well. Our  
>> meetings can't focus, our mailing lists can't focus, our management  
>> can't focus, and our participants can't focus. We're like three- 
>> year-olds in a three-ring circus, too busy gawking at the other  
>> clowns to get any work done.
>>
>> Several years ago, I proposed a reorganization (slides at http://www.ietf.org/proceedings/06mar/slides/raiarea-3/sld1.htm) 
>> . The consensus at the time was simply to have more rigorous  
>> chairs. We added Keith, who is  quite a rigorous chair, and it  
>> helped, but not enough. We've also tried more organized chairs,  
>> like Mary, in SIPPING.  Again, this helped, but not enough.
>>
>> I maintain that what is needed is to reduce the size of a chair's  
>> job so that it can be done well in a reasonable 4-6 hours per week,  
>> rather than done badly with a workload more like 30 hours per week.  
>> The easiest way to do this is to divide the problems up across more  
>> chairs. Of course, getting rid of a few problems would help too.
>>
>> Towards this end, I recently suggested a reorganization (see http://www.ietf.org/mail-archive/web/sip/current/msg23692.html) 
>> .
>>
>> This reorg proposed replacing SIP and SIPPING with a couple of  
>> smaller working groups with narrow charters, including (not nec. in  
>> this order):
>>
>> 1) RAI Maintenance: Essential corrections to existing RFCs. No  
>> semantic or functional changes, just bug fixes.
>>
>> 2) SIP Draft Standard: Whatever is needed to move the SIP spec  
>> family to draft standard
>>
>> 3) Real-Time Operations: Deals with the questions of how to do "x"  
>> with SIP and related specs
>>
>> 4) Real-Time Policies: Session policies, SAML, etc.
>>
>> 5) real-Time Identity Expression, for which I proposed a charter:
>> http://www.ietf.org/mail-archive/web/sip/current/msg23899.html
>>
>> There are some other things that SIP is close to finishing and  
>> should just be left there. I suspect the same is true of SIPPING.  
>> When done, we close those nuthouses down.
>>
>> Big, complex documents that have a lot of things depending on them  
>> belong in their own dedicated working groups with a dedicated  
>> management team.
>>
>> Related sets of documents with tight interdependencies also belong  
>> in their own working groups. For example, the SIP Consent Framework  
>> and the half-dozen drafts detailing how to use contact-lists for  
>> various SIP requests  might have made for a reasonably chartered  
>> working group with a reasonable 2-year lifespan. A working group  
>> that could actually finish, go away, and free up resources for new  
>> work.
>>
>> Here's how I envision this working: If somebody dreams up a new SIP  
>> extension that does something the RTOps group can't figure out how  
>> to do reasonably with what we have, then we run a BOF and see if it  
>> is worth working on. If so, then we charter a working group, If  
>> not, we either pursue AD-sponsored individual informational  
>> (assuming it does not need to be a STD track), or we don't work on  
>> it.  If we have more WGs than meeting slots, some WGs don't meet,  
>> and we don't charter new ones until the schedule is relieved.
>>
>>
>> -- 
>> Dean
>>
>>
>>
>> _______________________________________________
>> RAI mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rai
>
> _______________________________________________
> RAI mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rai

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [e-mail]
Phone: [phone]  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free





_______________________________________________
RAI mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rai