At the mid-cycle meet-up yesterday we spent some time looking at our bug 
dashboard ( 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.

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.

2.  Also - when a bug has all abandoned reviews, we should automatically set 
the bug to new and remove the assignee.

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

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.

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.

  *   Confirmed means someone has looked at the bug, saw there was enough into 
to start to diagnose, and agreed it sounds like a bug.
  *   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.

If we do implement 1 and 2 I’m hoping the infra team can help – I think dims 
volunteered ;-)

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

OpenStack-dev mailing list

Reply via email to