Unity 7 & Compiz bug triage

[Brian Murray]

On Mon, Aug 17, 2015 at 11:46:00AM +0100, Will Cooke wrote:
> Dear bug squad,
> 
> We've had a little shuffle around recently and I've been very fortunate to
> add Marco, Eleni and Andrea to the desktop team.  This means that we have
> taken on the planning and execution of the direction for Unity 7, Compiz
> and Nux.  With the 16.04 LTS release firmly on the horizon I want to start
> focusing on that release as soon as possible, and to that end I have done
> some poking around in the Unity 7 and Compiz bugs.
> 
> In order for us to best target our efforts we need to have a clear view of
> which bugs are causing the biggest pain points.  Heat is a useful metric
> here, but while we have around 800 bugs which are just "NEW" in Unity 7 we
> could find ourselves not being able to see the wood for the trees [1].

The idea behind bug heat was to identify those bug tasks with a New
status that should be looked at first using attributes of the bug[1].
Not every attribute I was using made it into bug heat though, and its
been a while since it was implemented. Having said that I still think
there is value using the criteria I had designed to help sort a pile of
new bug reports.

> And there will also be a large number of bugs which are now invalid but
> still block our view of the real bug situation in Unity 7 (and Compiz, etc).
> 
> Talking with the team, we came up with a few options including:
> 
> a)  Automatically marking all bugs which have been open for more than 1
> year as "Incomplete" and asking the user to try and recreate on the 15.10
> daily, or 15.04 for that matter.  We would then filter these out, and if
> not responded to in, say, 6 weeks, mark them as invalid and ask the
> reporter to open a new bug if they need to, along with instructions on how
> to do that properly.

If by "open" you mean bugs that are in the status New, Confirmed,
Triaged, In Progress, or Fix Committed - I think that is a bit unkind.
What I mean is that if a bug task is Triaged, as an example, some work
has gone into that bug report and just blindly flipping it to Incomplete
devalues any work that has gone into that bug. If you were to limit open
to just bug tasks that are New, and maybe Confirmed, that seems more
reasonable to me. Although, I might exclude crashes reported by apport,
that were successfully retraced, from this process.

> b) Leave the situation as it is and just use filters and sorting to help
> identify the best candidates for targeting in the 16.04 cycle.

I believe that there are plenty of ways to filter and sort bugs in
Launchpad and that one may find more useful bug reports by filtering for
those reported by apport and by using release tags - which apport
includes automatically. Filtering and sorting is how I manage bug
reports for the Foundations team.

> c) Organising a global bug jam or hug day in association with the community
> team and ask people pick a bug and try to reproduce it on 15.10.  If it
> can't be reproduced, then tag it with $SOMETHING, and if it can be, then
> tag with $SOMETHINGELSE.  We can then use the tags to do something like
> option A, where we close the bugs which can't be reproduced and include
> information on how to report a new bug.

We have not had a hug day in a while, so I am not certain how much
involvement there would be in one.

> Before we embark on any of these efforts though, I wanted to seek your
> advice and guidance.  We have a *lot* of bugs which need to be tidied up
> before we can make the most efficient use of our engineering time for
> 16.04.  I want to kick that process off as soon as possible.
> 
> I'd love to hear any suggestions you have for how we can get this rolling.

--
Brian Murray
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20150818/497afe67/attachment.pgp>