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... 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
