Open Stack

Robert Collins wrote:
> On 16 December 2013 23:56, Thierry Carrez <thierry at openstack.org> wrote:
>> 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
> 
> So, I'm trying to reconcile:
>  - the goal of moving bugs into 'triaged'
>    - which really is:
>      - keeping a pipeline of low hanging fruit as an onramp
>      - apparently some documentation needs too, though I'd rather push
> /all/ those into DocImpact tags on changes, + those bugs that are
> solely documentation issues.
>  - the goal of identifying critical bugs rapidly
>  - the goal of steering bugs to the right subteam (e.g. vendor interests)

Agree on your 3 goals. But I would argue that, in our setting, the value
of the second and third goal is much higher than the value of the first
one. We need *some* easy/analyzed bugs in the onramp pipeline, but we
don't need all of them.

> [...]
> I'm *entirely* happy with saying that anyone with the experience to do
> it can move things up to Triaged - I see no problem there, but there
> is a huge problem if we have any step in the process's inner loop that
> requires O(bugs) tasks.
> [...]

I completely agree. I felt like *your* approach for the second phase was
O(bugs), which is why I disagreed with it :)

You proposed:

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

IIUC that means going through each and every Confirmed+High[1] bug to
check if there is a proposed approach in them, and move them to
"Triaged" if it's any good. This is O(confirmedbugs).

My proposal (and the current state of things) is like this:

Anyone can propose an approach to a random bug and set the bug to
Triaged when he does. Anyone.

This is not an O(bugs) effort, this is 0 effort for your core members.

I assert there is not enough value in "assessing the proposed approach"
for it to be worth core time. Anyone should be able to propose a
solution and, if they are sure enough about it, set the bug to Triaged.
That creates enough Triaged bugs for your on-ramp pipeline. Code review
will be there to catch the corner case bad solution.

Core developers are just human beings that sign up to do a lot of code
reviews. Not deities that need to vouch every proposed solution in every
bug before a human may be tempted to solve it.

-- 
Thierry Carrez (ttx)