<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 2, 2015 at 8:07 AM, Duncan Thomas <span dir="ltr"><<a href="mailto:duncan.thomas@gmail.com" target="_blank">duncan.thomas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Why do you say auto-abandon is the wrong tool? I've no problem with the 1 week warning if somebody wants to implement it - I can see the value. A change-set that has been ignored for X weeks is pretty much the dictionary definition of abandoned</div></blockquote><div><br></div><div>+1 this</div><div><br></div><div>I think Tom's suggested "help us help you" is a great pre-abandon warning.  In swift as often as not the last message ended with something like "you can catch me on freenode in #openstack-swift if you have any questions"  </div><div><br></div><div>But I really can't fathom what's the harm in closing abandoned patches as abandoned?</div><div><br></div><div>If the author doesn't care about the change enough to address the review comments (or failing tests!) and the core reviewers don't care about it enough to *fix it for them* - where do we think the change is going to go?!  It sounds like the argument is just that instead of using abandoned as an explicit description of an implicit state we can just filter these out of every view we use to look for something useful as "no changes for X weeks after negative feedback" rather than calling a spade a spade.</div><div><br></div><div>I *mostly* look at patches that don't have feedback.  notmyname maintains the swift review dashboard AFAIK:</div><div><br></div><div><a href="http://goo.gl/r2mxbe" target="_blank">http://goo.gl/r2mxbe</a></div><div><br></div><div>It's possible that a pile of abandonded-changes-not-marked-as-abandonded wouldn't actually interrupt my work-flow.  But I would imagine maintaining the review dashboard might occasionally require looking at ALL the changes in the queue in an effort to look for a class of changes that aren't getting adequate feedback - that workflow might find the extra noise less than helpful.</div><div><br></div><div>-Clay</div></div></div></div>