Open Stack

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)