Robert Collins wrote: > On 16 December 2013 23:56, Thierry Carrez <thie...@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) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
