Re: Review panel's role

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

 



On Thu, 4 Aug 2005, Spencer Dawkins wrote:
My point is that each of these DISCUSSes kept a specification from being approved for at least one two-week telechat cycle. I believe, in the absence of data, that adding delays to a project makes it easier to stretch out other delays, so "two weeks" is the minimum amount of time one would wait before a specification would be reballoted, but if a document editor is on vacation for a week and doesn't provide updated text immediately, the actual delay can be longer.

Documents don't need to be reballoted [in IESG] to be approved (after being revised). This is up to the nature of the comments/changes and the AD's confidence that the discusses have been addressed to the satisfaction of commenters, and that new text doesn't have issues.

If time is of the essence, the chair or whoever could certainly take up the document from the editor; I've done so personally in a couple of cases.

On Thu, 4 Aug 2005, Henning Schulzrinne wrote:
I think it would be useful to analyze the nature of current DISCUSS comments before drawing conclusions from the 70% figure. They apparently range from simple typos ("expand acronyms") to differences of opinion ("WG chose X, AD prefers Y; both X and Y are at least plausible") to adding various disclaimers to fundamental design problems ("broken").

Exactly. As I read it, the review panel proposal included "yes" and "no". If you say "yes", the document is shipped as-is.

It is (IMHO) important to be able to fix problems, even if relatively minor, even if you would like to say "yes" or would have confidence that the problems could be fixed in a day or two.

There are many levels of issues, for example:
 - "there is a significant architectural problem in the doc", NO (or
   big discuss)
 - "there are major issues which require at least significant
   clarification/discussion"
 - there are relatively important issues which need to be fixed but
   are so straightforward that the WG (and the editor in particular)
   can probably do it without further dialogue.
 - there are typos or other things affecting readability, and
   sometimes even the clarity of the document.
 - probably a lot more different classes of issues..

To me, having reviews which wouldn't report any issues would meant that with high probability, such reviews wouldn't be sufficiently indepth. Finding issues is one sign of a good review -- if the issues found are minor, this is also often a sign of a document in a good shape. Discarding the issues doesn't seem good, though if they are minor, the amount of dialogue/energy needed should be minimized.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]