sorting bugs

[Walter Lapchynski]

On Thu, Jan 29, 2015 at 5:58 AM, Alberto Salvia Novella
<es20490446e at gmail.com> wrote:
> Walter Lapchynski:
>  > One thing I've struggled with in trying to get new bug triagers on
>  > board is helping them find which bugs to work on. I tend to follow the
>  > Pareto rule: work on the 80% you can get to right away since the other
>  > 20% are likely to take 80% of your time.
> That's a good beginning, but it's not enough. The key aspect is getting bugs
> fixed one by one; so you are putting all your work where it will get a fix,
> and there's a constant flow of value.

What I mean is working on things you can contribute to right away,
e.g. that doesn't require a bunch of research or special hardware.
Something where you can do _something_ right away. The idea is
focusing on things you can do to move bugs forward. If you hesitate,
or lack something, then that should be saved for later.

> For that the first step should be setting priority to each bug that is
> confirmed, and not to do anything else before that. Then work on the bug
> with the highest priority and heat:

Which is a task reserved for bug control members, so not everyone can do this.

>  > So there are several strategies I have considered:
>  >   * focus on invalidating or moving along New bugs
>  >   * focus on moving Confirmed bugs upstream (but many involve EOL
>  >     releases)
>  >   * focus on high heat bugs
>  >   * look through newest bugs
>  >   * focus on bugs Lubuntu Packages Team is notified about
>  > But I still haven't found one that's really good. Any suggestions?
> That's already solved in
> <https://wiki.ubuntu.com/One%20Hundred%20Papercuts/Work-flow>. You are
> welcomed to use it, and to suggest improvements.

Aren't they essentially triaged by the time they hit Papercuts?

>  > Going forward, I think I'm going to work at trying to tag all bugs
>  > dealing with LXDE (and eventually LXQt) "lubuntu" since a lot of the
>  > bugs we get notified about are not so much about our core system, if
>  > you will. For example, if Abiword isn't behaving (it's often not),
>  > that's not as critical as lxsession misbehaving. I'd consider iBus to
>  > be something not specific to LXDE, but essential to our core system,
>  > so I'd include that. Does that seem like it makes sense? Is there
>  > some way to use the Launchpad API to automate this?
> Why distinguishing packages specific of Lubuntu?

Because that is the focus of our team. We have very, very few
triagers. We must have some sort of focus and priority or we'll never
get anything useful done. For that matter, we only have a few
developers!

>  > I've found the priorities we have to be extremely broad.
> You can use
> <https://wiki.ubuntu.com/One%20Hundred%20Papercuts/Work-flow/Importance>
> instead.

I'm not solely concerned with the easiest to fix bugs.

-- 
@wxl
Lubuntu Release Manager, Head of QA
Ubuntu PPC Point of Contact
Ubuntu Oregon LoCo Team Leader