[openstack-dev] [bugs] definition of triaged
thierry at openstack.org
Fri Dec 20 10:01:52 UTC 2013
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 :)
Daily tasks - second layer - -core current and previous members
1. Assess the proposed approach in Confirmed+High bugs
1.1. If good, move to Triaged
1.2 If not, suggest what would make the approach good
2. If appropriate add low-hanging-fruit tag
IIUC that means going through each and every Confirmed+High 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)
More information about the OpenStack-dev