On Thu, Apr 11, 2013 at 5:27 PM, Fred Baker (fred) <fred(_at_)cisco(_dot_)com>
wrote:
In my opinion, some individual ADs seem to, from their behavior, feel that
they have not done their jobs unless they have raised a "discuss". The one
that took the cake for me personally was a "discuss" raised by a particular
AD (who shall remain nameless) that in essence wondered what he should raise
a "discuss" about in my document. There were a couple of errors in that; he
told me later that what he had done was opened the comment tool and typed
that question, and subsequently accidentally hit the equivalent of "send" -
the question wasn't intended to go out. But the question itself is telling:
the issue was not "does the document meet the requirements of BCP 9", it was
"what comment shall I raise"?
Also, in my opinion, IESG review that raises a certain number of issues
should not result in the document sitting in the IESG's queue for a few
months while the authors go back and forth with the AD or the GEN-ART
reviewer pounding the document into someone's idea of "shape" without working
group involvement. I personally would prefer that simple matters get sorted
out between the ADs and the author, but complex changes or additional content
requested by the AD should result in the document being sent back to the
working group.
Many of us can change the acronyms and describe a similar experience.
I would say "We don't have the authority to make that decision
without asking the WG" a lot.
But this is a 2nd order problem.
The real issue is the way the IESG manages WGs.
Good management doesn't fall out for free.
It is yet another continuous integration progress.
The IESG is the overworked bottleneck in the system
and the review process is the main reason.
The ADs that own a WG should be the main IESG members
that get involved at the details for any possible issue,
and hopefully make these comments/changes as early
in the WG process as possible.
During IESG review, the ADs from other areas should
restrict their comments to issues related to their area.
The final review should avoid changes made
which are feature redesigns or feature enhancements,
and limit changes to bug fixes only.
Andy