On 16 December 2013 23:56, Thierry Carrez <thie...@openstack.org> wrote: > Robert Collins wrote: >> https://wiki.openstack.org/wiki/BugTriage is a 10 step process: thats >> not something we can sensible do over coffee in the morning. > > Totally agree with that. The idea of those 10 steps was not meant as > something you could ever complete, it was more a way to state there is > no point in doing step 8 unless step 1 is covered. > > I agree that splitting the process into separate daily / cycle-y > processes (as you propose below) is a better way to ever get it done.
Ok, cool. > 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) > be more value in asserting that "there is a proposed approach in the > bug", rather than "there is a core-approved approach in this bug". The definition of Triaged on the Bugs wiki page is 'Triaged The bug comments contain a full analysis on how to properly fix the issue ' Fundamentally for a process to work at scale we can't depend on 'all triagers naturally figure out which bugs need to be Triaged and which only need to be Confirmed'. *regardless* of definition of triaged, we need a system where we don't exhaust people every few weeks reviewing *every open bug* to figure out which ones have been missed. 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. > Furthermore, I'm not convinced we really need to spend core time > "assessing the proposed approach". You can spend core time on suggesting > a proposed approach (i.e. turning Confirmed into Triaged), though. So if I rephrased Daily tasks - second layer - -core current and previous members 1. Review Confirmed+High bugs 1.1. If there is a full analysis on how to properly fix the issue move to Triaged 1.2 If not, add one. 2. If appropriate add low-hanging-fruit tag You'd be happy? The reason I didn't write it like that is that this burns *more* core time. I was trying to propose a process where we can scale a competent but non-core team up without demanding that -core commit to boiling the ocean. The different between the phrasing I had and the one you seem to be proposing is that rather than promoting and guiding on bugs, -core are being asked to /do/ on every bug. That places a lot of load on -core, *or* it means we get many less bugs triaged. If we say that anyone with reasonable competency can do it, we could say: Daily tasks - second layer - more experienced folk 1. Review Confirmed+High bugs 1.1. If there is a full analysis on how to properly fix the issue move to Triaged 1.2 If not, add one. 2. If appropriate add low-hanging-fruit tag > You basically have the following states for a bug: > > A - Brand new > B - WAT (incomplete, ask the reporter for more info) > C - I don't have the expertise to judge (but I can add tag) > D - Yes this is definitely a bug, here is its priority > E - This is a bug and here is a suggested approach to fix it > F - I'm core and I bless that way to fix it > G - I started working on that fix > H - The fix is in code review > I - The fix landed in master > J - The fix landed in a milestone > K - The fix landed in a release > > That is way too many states, especially if you rely on humans to set > them. My experience is that humans deal with 3 bug states correctly, but > start to fail doing it consistently if you ask them to set 4 or more. I would quibble about that list - for instance tagging and expertise to judge project impact tag properly are IME the same. There are many dimensions of input to bugs, and what you're calling states there are really the combination of things from different dimensions. Timeline interactions for instance, don't change the state of a bug, but they change whether we want it to show up in bug searches. > In the current setup (constrained by what Launchpad supports) we use > tags for C, we ignore F, we combine G+H, and we combine J+K: > > A - New > B - Incomplete > C - (New + tagged) > D - Confirmed > E - Triaged > F - (Triaged + comment) > G - In progress > H - In progress (automatically set) > I - Fix committed (automatically set) > J - Fix released (automatically set) > K - (Fix Released + remilestoning) (automatically set) > > I think less states (and more consistency) is better than plenty of > states that nobody sets correctly, so you can't rely on them. If you > take "In progress" for example, it's a mess: people don't set it when > they start working on it, or don't unset it if they stop, there is no > consistency enforced with "assignee", and it prevents you from using it > purely to mean there is a code review in progress. We end up having to > spend triaging time fixing it. Better use the assignee as a way to > assert you should work on something, and then have a "In review" state > automatically set. I agree - automation and simple assessments are really good. > In a ideal system I'd personally not track F, J and K. Not totally > convinced there is value in trying to track E and G since it relies on > devs setting it (and they usually don't). So that would give: > > A - New > B - Incomplete > C - (New + tagged) > D - Prioritized > E/F - (Prioritized + comment) > G - (Prioritized + assigned) > H - In review (automatically set) > I - Fix merged (automatically set) > J/K - (Fix merged + branch set) > > 3 human-set states, topic tags, and 2 states set by Gerrit links. Yes > it's simplistic, but I think that would not work better (less detail but > more accuracy). To me this is exactly what I was getting at when I asked about the definition of triaged. :). The difference between 'confirmed' and 'triaged' in this ideal system is nil, since it's priority-set + comments. And thats what I'd really like to do :) We ran that for LP itself, and while there was some bikeshedding, as a process and a way to make sure the things that folk need to work on were really visible, it worked fantastically. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev