Robert Collins wrote: > https://wiki.openstack.org/wiki/BugTriage is a 10 step process: thats > not something we can sensible do over coffee in the morning.
Totally agree with that. The idea of those 10 steps was not meant as something you could ever complete, it was more a way to state there is no point in doing step 8 unless step 1 is covered. I agree that splitting the process into separate daily / cycle-y processes (as you propose below) is a better way to ever get it done. > [...] > And turn it into something like this: > Daily tasks - first- layer - need to be broadly familiar with Nova but > doesn't require -core knowhow > 1: Prioritize unprioritized bugs (bug supervisors) > 1.1 set bugs to Invalid if questions > 1.2 set bugs to Incomplete if questions asked > 1.4 patches are immediately directed to Gerrit > 1.5 subject area tags are applied > 1.3 output is Confirmed or Triaged + Priority set > 2: Review Incomplete-with-response bugs > 3: Review: In progress bugs without an assignee > > Daily tasks - second layer - -core current and previous members > 1. Assess the proposed approach in Confirmed+High[1] bugs > 1.1. If good, move to Triaged > 1.2 If not, suggest what would make the approach good[2] > 2. If appropriate add low-hanging-fruit tag > > Per-release: > 1: Review stale In Progress bugs (anyone) > 2: Review Critical/High bugs (bug supervisors) > 3: Review Medium/Low bugs (bug supervisors) > 4: Deprecate old wishlist bugs (bug supervisors) I like the first and third parts. Not really convinced with the second part, though. You'll have a lot of "Confirmed" bugs without proposed approach (like 99% of them) so asking core to read them all and scan them for a proposed approach sounds like a waste of time. There seems to be more value in asserting that "there is a proposed approach in the bug", rather than "there is a core-approved approach in this bug". Furthermore, I'm not convinced we really need to spend core time "assessing the proposed approach". You can spend core time on suggesting a proposed approach (i.e. turning Confirmed into Triaged), though. You basically have the following states for a bug: A - Brand new B - WAT (incomplete, ask the reporter for more info) C - I don't have the expertise to judge (but I can add tag) D - Yes this is definitely a bug, here is its priority E - This is a bug and here is a suggested approach to fix it F - I'm core and I bless that way to fix it G - I started working on that fix H - The fix is in code review I - The fix landed in master J - The fix landed in a milestone K - The fix landed in a release That is way too many states, especially if you rely on humans to set them. My experience is that humans deal with 3 bug states correctly, but start to fail doing it consistently if you ask them to set 4 or more. In the current setup (constrained by what Launchpad supports) we use tags for C, we ignore F, we combine G+H, and we combine J+K: A - New B - Incomplete C - (New + tagged) D - Confirmed E - Triaged F - (Triaged + comment) G - In progress H - In progress (automatically set) I - Fix committed (automatically set) J - Fix released (automatically set) K - (Fix Released + remilestoning) (automatically set) I think less states (and more consistency) is better than plenty of states that nobody sets correctly, so you can't rely on them. If you take "In progress" for example, it's a mess: people don't set it when they start working on it, or don't unset it if they stop, there is no consistency enforced with "assignee", and it prevents you from using it purely to mean there is a code review in progress. We end up having to spend triaging time fixing it. Better use the assignee as a way to assert you should work on something, and then have a "In review" state automatically set. In a ideal system I'd personally not track F, J and K. Not totally convinced there is value in trying to track E and G since it relies on devs setting it (and they usually don't). So that would give: A - New B - Incomplete C - (New + tagged) D - Prioritized E/F - (Prioritized + comment) G - (Prioritized + assigned) H - In review (automatically set) I - Fix merged (automatically set) J/K - (Fix merged + branch set) 3 human-set states, topic tags, and 2 states set by Gerrit links. Yes it's simplistic, but I think that would not work better (less detail but more accuracy). -- Thierry Carrez (ttx) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
