Re: [RAI] Back to the topic : Reducing Delays

["Pete Cordell" <[e-mail]>]

----- Original Message From: "Hannes Tschofenig"
> It does not take too long until the discussion derails and the entire 
> group
> spends a fair amount of time discussing something else (often related).

I find that even when discussions stay on topic they often just seem to 
fizzle out with out a real conclusion.  I think it would really help if each 
major thread ended with an email that attempts to capture consensus.  I 
guess it would fall to a chair to either write, or (more likely) invite one 
of the participants to write up a consensus on the discussion.  This would 
have to include what each party thought, where there was agreement, where 
there was disagreement, and possibly what the road ahead was.

I would suggest that such e-mails have [Consensus Proposal] in the subject 
line.  If necessary that could be argued over, and when all parties are 
happy (which may involve the e-mail recording their unhappiness!), a final 
e-mail is submitted with the subject line including [Consensus].  Among 
other things, I think this would greatly help finding conclusions to 
discussions in the mail archives at a later date.

I think it could also be a useful tool for chairs to bring discussions back 
on topic.

On a related matter, I was wondering if you can use xml2rfc's <cref> tag to 
include explanatory text in addition to author questions.  For example, you 
could then do something like <cref>See "[Consensus] Impossible Problem" on 
SIP list dated 10 Feb 1998</cref> to record why a particular approach has 
been taken.  This could then be displayed in the working drafts, but not in 
the final RFC.  Or maybe it would be better to use a different tag with the 
same functionality but having a different semantic meaning.

HTH,

Pete Cordell
----- Original Message ----- 
From: "Hannes Tschofenig" <[e-mail]>
To: <[e-mail]>
Sent: Saturday, March 07, 2009 9:44 AM
Subject: [RAI] Back to the topic : Reducing Delays


>
> This discussion thread shows another issue that can often be observed in
> IETF discussion.
>
> There is a problem that has to be solved (often a more difficult technical
> aspect, in our case it is more about problems that showed up in the way we
> work). A discussion is started.
>
> It does not take too long until the discussion derails and the entire 
> group
> spends a fair amount of time discussing something else (often related).
>
> Particularly problematic is the case when a document is about to get
> finished but then some other new proposal comes along and the entire group
> focuses their time on the new hot topic instead of completing the previous
> document. Ads and chairs often try to control this behavior by saying that
> no new work gets added to the group unless the existing stuff is finished
> but typically that does not help. We get distracted far too easily.
>
> Coming back to previous topic:
> http://www.ietf.org/internet-drafts/draft-tschofenig-rai-reducing-delays-00.
> txt
>
> Is the analysis about the reasons for delay roughly correct? Anything
> missing? Something wrong?
>
> Regarding the suggestions: Do you have additional ideas?
> Many of the suggestions are currently targeting working group chairs and
> area directors. What could **YOU** contribute?
>
> I am surprised not to hear more comments given that in my work in the 
> Nomcom
> I got a lot of feedback about folks being unhappy with the current way of
> working. I would like to hear what should be done to improve things.
>
> Ciao
> Hannes
>
> _______________________________________________
> RAI mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rai
>