Open Stack

After closing the old (>18months) bug reports nobody is working on a few
days ago [1], it became clear that the "in progress" reports are the
majority [2]. After asking Gerrit how long it usually takes to get a fix
merged [3], this is the result:

    number of merged bug fixes within the last 365 days: 689
    merged within ~1m : 409 (~59%)
    merged within ~2m : 102 (~14%)
    merged within ~3m :  57 (~ 8%)
    merged > 3month   : 121 (~17%)

    Note: This doesn't reflect the time a patch might be marked as
    "WIP". It also doesn't add up to 100% as I rounded down the
    percentages.

This made me thinking about ways to increase the review throughput of
bug fix changes, especially the bug fixes in the "~2m" and "~3m" area. I
*assume* that the fixes in the ">3m" area had inherent problems or
waited for basic structural changes, but that's just guesswork.

The proposal is this:
* have a TBD list with max 10 items on it (see list possibilities below)
* add new items during nova meeting if slots are free
* Change owners must propose their changes as meeting agenda items
* drop change from list in nova meeting if progress is not satisfying

List possibilities:
1) etherpad of doom? maintained by (?|me)
    + easy to add/remove from everyone
    - hard to query
2) gerrit: starred by (?|me)
    + easy to add/remove from the list maintainer
    + easy to query
    - No additions/removals when the list maintainer is on vacation
3) gerrit: add a comment flag TOP10BUGFIX and DROPTOP10BUGFIX
    + easy to add/remove from everyone
    + easy to query (comment:TOP10BUGFIX not comment:DROPTOP10BUGFIX)
    - once removed with a comment "DROPTOP10BUGFIX", a repeated
      addition is not practical anymore.
4) gerrit: tag a change
    + easy to add/remove from everyone
    + easy to query
    - not yet available in our setup

Personally I prefer 3, as it doesn't rely on a single person and the
tooling is ready for that. It could be sufficient until one of the next
infra Gerrit updates brings us 4. I'd like to avoid 1+2.

My hope is, that a focused list helps us to get (few) things done faster
and increase the overall velocity. Is this a feasible proposal from your
point of view? Which concerns do you have?

References:
[1] http://lists.openstack.org/pipermail/openstack-dev/2016-July/098792.html
[2] http://45.55.105.55:3000/dashboard/db/openstack-bugs
[3]
https://github.com/markuszoeller/openstack/blob/master/scripts/gerrit/bug_fix_histogram.py


-- 
Regards, Markus Zoeller (markus_z)