Pete Resnick <presnick@xxxxxxxxxxxxxxxx> writes: > On 5/3/13 7:59 AM, Thomas Narten wrote: > > Like everyone, I wish things moved more quickly, but every attempt > > I've ever seen that tries to speed things up ends up reducing the > > quality or having some other undesirable side effect. > > > Can you talk a bit more about this, including some examples? Sorry, what I had in mind here was what I'll call process tweaks. Attempts at changing the process to speed reviews, dispense with reviews, overlap reviews, etc. No, our processes aren't perfect. But we have bigger problems that are not due to process that we'd do better to focus on rather than trying to tweak the process in (IMO) minor ways. We should focussing more on *root* *causes* and what concrete, pragmatic steps can be taken to mitigate them. > I'm trying to reconcile the concern that we "end up reducing the > quality" Again, I was thinking of proposals for process (or operational) changes that attempt to shorten things by overlapping or removing reviews or steps, trying to get the IESG to do less review (e.g., "ADs should only review looking at topics that are defined by their area") and otherwise focus on the *process* as being the problem. > and that we "NOT neglect longer-term stuff that will have real > and significant, but not immediate benefits." ADs have finite resources > and can't accomplish both immediate and longer-term stuff maximally all > of the time. My inclination would be to say, "If they are in conflict, > weight the longer-term over the immediate, even if that might result in > some reducing of quality on any single document." Am I over-reading your > earlier message to say that you think the weighting should go toward the > immediate? You have it right. And I meant "longer-term stuff" in a general sense. There are many topics that are not immediate, but could be important long term. Spend enough time on long term so that it is not neglected. You have to do both. But you must also MUST do long term stuff. > I think we agree that doing the longer-term stuff will end up > with increased quality over the long term, but doing more of the > longer-term stuff is sure to reduce the amount of time spent on > immediate, which means document reviews and therefore some short term > lowering of quality. Is that OK, or is that an example of the kind of > thing we've attempted that ends up with bad results? It's easy to fall back to the comfort zone, which is doing the bi-weekly document reviews and such. I.e., the day-to-day operational stuff. What's more important to the IETF? Spending time on one questionable (but quite possibly irrelevant) document to make it better before it gets published? Or getting the IETF as a whole to work better and more efficiently and produce better product? Thomas