Open Stack

On 12.07.2016 18:19, Chris Friesen wrote:
> On 07/12/2016 01:59 AM, Markus Zoeller wrote:
>> 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
> 
> What do we hope to gain from this?  Is the hope that random developers will see 
> this list and review the proposed patches?  Or that nova-core developers will 
> focus their attention on these issues?
> 
> Chris

My hope is that subject matter experts and nova-cores will focus on
those. It's also about getting commitment of the bug fix owners to
create new patchsets faster after getting reviews.
My basic assumption behind the proposal is, that the "mental context
switches" of change authors|reviewers, while they wait for the other
group and start working on other items, costs a lot of time.

-- 
Regards, Markus Zoeller (markus_z)