On 07/29/2014 11:43 AM, Tracy Jones wrote: > 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??
I don't think blueprint are appropriate for tracking requests. They should only be created when someone is proposing actually doing the work. I think Wishlist is fine for keeping a list of requests. That's what I've been using it for. > 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. We should be careful not to conflict with the guidelines set for all OpenStack projects here: https://wiki.openstack.org/wiki/BugTriage For example, that page says when a bug should be set to Confirmed or Triaged. In most cases, it's Confirmed. Triage is when there is a known solution. -- Russell Bryant _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
