<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Arial, sans-serif;">
<div><br>
</div>
<div>At the mid-cycle meet-up yesterday we spent some time looking at our bug dashboard (<a href="http://54.201.139.117/nova-bugs.html">http://54.201.139.117/nova-bugs.html</a>) and talking about things we can do to help focus on bugs. We came up with the
following ideas. I’d like folks to weigh in on these i if you have some ideas or concerns.</div>
<div><br>
</div>
<div><br>
</div>
<div>1. Start auto-abandoning bugs that have not been touched (I.e. Updated) in the last 60 days. We would have something (a bot?) that would look at bugs that have not been updated (nor their review updated) in the last 60 days. The bug would be set to
the “new” state and the assignee would be removed. This would cause the bug to be re-triaged and would be up for someone else to pick up.</div>
<div><br>
</div>
<div>2. Also - when a bug has all abandoned reviews, we should automatically set the bug to new and remove the assignee. </div>
<div><br>
</div>
<div>3. We have bugs that are really not bugs but features, or performance issues. They really should be a BP not a bug, but we don’t want these things to fall off the radar so they are bugs… But we don’t really know what to do with them. Should they be
closed? Should they have a different category – like feature request?? Perhaps they should just be wish list??</div>
<div><br>
</div>
<div>
<div>4. We should have more frequent and focused bug days. For example every Monday have a bug day where we focus on 1 area (like api or compute or networking for example) and work on moving new bugs to configured, or confirmed bugs to triaged. I’ll talk
with Michael about when to schedule the 1st “focused” bug day and what area to address.</div>
</div>
<div><br>
</div>
<div><br>
</div>
<div>In generate we need to tighten up the definition of triaged and confirmed. Bugs should move from New -> Confirmed -> Triaged -> In Progress. JayPipes has updated the wiki to clarify this.</div>
<ul>
<li>Confirmed means someone has looked at the bug, saw there was enough into to start to diagnose, and agreed it sounds like a bug. </li><li>Triaged means someone has analyzed the bug and can propose a solution (not necessarily a patch). If the person is not going to fix it, they should update the bug with the proposal and move the bug into Triaged. </li></ul>
<div><br>
</div>
<div>If we do implement 1 and 2 I’m hoping the infra team can help – I think dims volunteered ;-)</div>
<div><br>
</div>
<div>I made a note to add review stats to the bug page to make it easier to see how far along a bug is in review</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div id="MAC_OUTLOOK_SIGNATURE"></div>
</div>
</body>
</html>