On Thu, Apr 11, 2013 at 5:27 PM, Fred Baker (fred) <fred@xxxxxxxxx> 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