sorting bugs

[Thomas Ward]

Just adding my perspective:

On 01/29/2015 10:03 AM, Walter Lapchynski wrote:
> 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.
To clairfy: generic all-hardware bugs rather than hardware-specific bugs
are likely to be better starting points for new triagers.  However, keep
in mind my comments later on here (READ MY COMMENTS!).
>> 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.
This is true, however, this is why we should have bug controllers
lurking ready to set importance.  HOWEVER, we need to have additional
clarification from a non-controller triager who wants a specific
importance as to *why* it qualifies for that importance.  This has been
part of triage from day one if someone can't set importance and has to
ask: they need to have a justification.
>
>>  > 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!
Alberto, Walter here is part of Lubuntu QA (if not the lead). 
Therefore, their primary focus is Lubuntu packages and stuff directly
impacting Lubuntu itself, rather than more generic bugs in Universe
packages and such (except for ones used in Lubuntu, but if they're on
the image, they should probably not be in Universe)
>
>>  > 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.
Echoing this.  The "easiest to fix" bugs are sometimes the least
priority, most insignificant bugs.  Examples are typos in a translation,
or a typo in the packaging's description in debian/control, or such. 
When we look at 'easiest to fix' bugs, we also have to look at how
widely the bug impacts something - if it's going to fix a segfault in a
package in Vivid or fixes functionality that is highly desired by a
majority (say, for example, php5-fpm's permissions which were broken in
a security update a while ago and needed additional changes to fix
issues), then it obviously needs to be handled faster and more
expediently than a minor typo in a package's description which doesn't
actually need to be fixed.



And because an email came in later I'm going to copy in Brian Murray's
email to here:

On 01/29/2015 10:31 AM, Brian Murray wrote:
> On Wed, Jan 28, 2015 at 05:30:35PM -0800, Walter Lapchynski wrote:
>> One thing I've struggled with in trying to get new bug triagers on
>> board is helping them find which bugs to work on.
> If these are people brand new to bug triage, then I'd have them work on
> a piece of software that interests them. Let's say I like hiking (true),
> so I use gpsprune and pytrainer to manage my gps tracks. Subsequently,
> I'm likely to be familiar with both pieces of software and in a position
> to better recreate any bugs reported about them. Additionally, I have a
> personal interest in making the software better so will be more
> motivated to do the right thing and work conscientiously.
>
> Then when people have the principles down have them move onto things
> that they are less familiar with and which may be more complicated.
>
> --
> Brian Murray
> Ubuntu Bug Master
I second Brian here - if someone is brand new to triage, they may want
to start on a piece of software that interests them.  This is a good way
to get into triage.  With me, this was the ZNC and NGINX packages, as
well as some PHP packages.  Granted, these are server packages and not
typically on the Papercuts project's radar, but that's how I got started
in triage as something I do regularly.


------
Thomas