> -----Original Message----- > From: iesg <iesg-bounces@xxxxxxxx> On Behalf Of Warren Kumari > Sent: 09 August 2020 17:33 > To: Barry Leiba <barryleiba@xxxxxxxxxxxx> > Cc: IESG <iesg@xxxxxxxx>; Michael Richardson <mcr+ietf@xxxxxxxxxxxx>; IETF > discussion list <ietf@xxxxxxxx>; Benjamin Kaduk <kaduk@xxxxxxx> > Subject: Re: dealing with AD reviews in the week before the IESG call > > On Sun, Aug 9, 2020 at 11:29 AM Barry Leiba <barryleiba@xxxxxxxxxxxx> > wrote: > > > > Speaking only for myself: I would always prefer to be reviewing the > > latest version available at the time I'm reviewing, and I don't care > > whether it's not the same version that another AD reviewed, nor that I > > might start reviewing one version and see another posted before I'm > > done. > > > > In other words, I'd rather have updates posted when the judgment of > > the authors, working groups, and sponsoring ADs says they should be. > > > > Me too! Update early, update often. If I comment on an older version, > and the issues have already been addressed, thats perfectly fine / > preferred... [RW] Agreed. As long as the authors accept that some reviews/comments may be against older versions, then responsive authors fixing the text as the reviews come in generally seems like a good thing. If an AD is reviewing a document closer to the telechat deadline, then generally any improvements that have already been made to the text normally makes the document easier/quicker to review. Regards, Rob > > W > > > Barry > > > > On Sat, Aug 8, 2020 at 9:35 PM Michael Richardson > <mcr+ietf@xxxxxxxxxxxx> wrote: > > > > > > > > > Hi, > > > > > > I have heard that revising IDs in the week before they are on the IESG > call > > > makes Area Directors *grumpy*, because they wind up reviewing > different > > > versions. > > > > > > On the other hand, I would prefer to clear all DISCUSSes > > > make it clear that COMMENTs, are being dealt with. > > > ADs have, I think, limited L1 CPU cache and responding to them as fast > as > > > possible seems to be a good idea. > > > > > > It seems that the answer is to: > > > 1) reply ASAP, with git commits/diffs attached. > > > 2) do not publish new IDs until all the changes from all reviews are > > > collected. > > > 3) publish a revised ID sometime on Thursday morning. Just before > > > the meeting? Or just after? > > > > > > Asking for a friend. :-) > > > > > > -- > > > Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works > > > -= IPv6 IoT consulting =- > > > > > > > > > > > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf
