From noreply at ubuntu.com Sun Aug 2 00:25:10 2015 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Sun, 02 Aug 2015 00:25:10 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Bugs/Triage=22_by_tdaitx?= Message-ID: <20150802002510.8801.48137@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Bugs/Triage" page has been changed by tdaitx: http://wiki.ubuntu.com/Bugs/Triage?action=diff&rev1=169&rev2=170 Comment: Fix importance link in 'confirmed bugs' section Only if '''ALL''' of these conditions are satisfied, you can set the status of the bug report to 'Triaged'. To do this: * Change the "Status" field to "Triaged". - * If not done yet, assign the appropriate [[Bugs/Bug importance|importance]]. + * If not done yet, assign the appropriate [[Bugs/Importance|importance]]. * Click "Save changes". In order to set bug statuses to 'Triaged' you need to be a member of the [[UbuntuBugControl|Ubuntu Bug Control]] team. If you are not a Bug Control member, and you find a bug you believe is ready to be marked as Triaged, then please join the #ubuntu-bugs channel on irc.freenode.net and provide a link to the report. A Bug Control member can then examine the report and, if it is ready, mark it as Triaged for you. From will.cooke at canonical.com Mon Aug 17 10:46:00 2015 From: will.cooke at canonical.com (Will Cooke) Date: Mon, 17 Aug 2015 11:46:00 +0100 Subject: Unity 7 & Compiz bug triage Message-ID: 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]. 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. 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. 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. 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. Cheers, Will Ubuntu Desktop Engineering Manager 1: Too British? http://idioms.thefreedictionary.com/can't+see+the+wood+for+the+trees -------------- next part -------------- An HTML attachment was scrubbed... URL: From es20490446e at gmail.com Mon Aug 17 12:04:08 2015 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Mon, 17 Aug 2015 14:04:08 +0200 Subject: Unity 7 & Compiz bug triage In-Reply-To: References: Message-ID: <55D1CDB8.3000702@gmail.com> Will Cooke: > 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. Set importance first and do everything else later. Then the effort will go to the optimal place: Also if the software is in production and frequently used, focus on confirmed bugs for the latest releases. Everything else usually is just noise, and usually users confirm themselves bugs that are really important for them. The idea behind this is that doing 90% well is better than doing 100% well, as that additional 10% usually takes greats amounts of extra work. There's never time for doing everything, but always time for doing the important things: Simple and straightforward, over correct. Go dirty testing new approaches, just go dirty piece by piece and it will be both innovative and stable. Will Cooke: > Heat is a useful metric here. The ideal solution is shorting by importance first, and then by heat: Thank you! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6472 bytes Desc: S/MIME Cryptographic Signature URL: From stephen.webb at canonical.com Tue Aug 18 12:26:44 2015 From: stephen.webb at canonical.com (Stephen M. Webb) Date: Tue, 18 Aug 2015 08:26:44 -0400 Subject: Unity 7 & Compiz bug triage In-Reply-To: <55D1CDB8.3000702@gmail.com> References: <55D1CDB8.3000702@gmail.com> Message-ID: <55D32484.9080604@canonical.com> On 15-08-17 08:04 AM, Alberto Salvia Novella wrote: > Will Cooke: >> 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. > > Set importance first and do everything else later. Then the effort will go to the optimal place: > > > Also if the software is in production and frequently used, focus on confirmed bugs for the latest releases. Everything > else usually is just noise, and usually users confirm themselves bugs that are really important for them. Unfortunately in the case of the Unity 7 stack, this is simply not scalable advice. With well over 3000 bugs in the entire stack, just a simple linear iteration for an individual to determine the importance of a bug is untenable. Most of these bugs are in the form 'Unity mysteriously crashed for no reason' and has been autoconfirmed because someone saw it and clicked 'affects me' -- they also saw a crash window pop up for no reason. To do a full and complete bug triage of every single extant bug, something that can take many minutes of set up, and would take about 2 full-time months of work. Just for setting priorities. I know, I've tried. It's just not really a practical goal. Focusing on simply setting importance or on confirmed bugs is not working well enough for Unity. That's why Will has asked for feedback and tagging from the Unity 7 community, so his team can focus on what seem to be the biggest problems. -- Stephen M. Webb From walter.garcia at upf.edu Tue Aug 18 15:28:00 2015 From: walter.garcia at upf.edu (Walter Garcia-Fontes) Date: Tue, 18 Aug 2015 17:28:00 +0200 Subject: Unity 7 & Compiz bug triage In-Reply-To: References: Message-ID: <20150818152800.GA9654@upf.edu> * Will Cooke, will.cooke at canonical.com [17/08/15 12:46]: > 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. IMHO, this a) option is the best. It seems to me that it is almost impossible to work on these bugs if you don't have a collaborative user responding to requests and being able to reproduce the issue. -- Walter Garcia-Fontes From brian at ubuntu.com Tue Aug 18 16:07:53 2015 From: brian at ubuntu.com (Brian Murray) Date: Tue, 18 Aug 2015 09:07:53 -0700 Subject: Unity 7 & Compiz bug triage In-Reply-To: References: Message-ID: <20150818160753.GH32053@murraytwins.com> 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: From es20490446e at gmail.com Tue Aug 18 16:50:22 2015 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Tue, 18 Aug 2015 18:50:22 +0200 Subject: Unity 7 & Compiz bug triage In-Reply-To: <55D32484.9080604@canonical.com> References: <55D1CDB8.3000702@gmail.com> <55D32484.9080604@canonical.com> Message-ID: <55D3624E.6060007@gmail.com> Stephen M. Webb: > Focusing on simply setting importance or on confirmed bugs is not > working well enough for Unity. When the software is under as much use as Unity 7 is, nearly all new bugs are false or minor. If you want to make sure the incoming Ubuntu release is stable, it's rather productive to ask people to have a look around it, try to break Unity on it in every corner, and to confirm the bugs they see. More productive than confirming a pool of hundreds of false reports. Stephen M. Webb: > Most of these bugs are in the form 'Unity mysteriously crashed for no > reason' and has been autoconfirmed because someone saw it and clicked > 'affects me' -- they also saw a crash window pop up for no reason. What I'm suggesting is setting importance without validating the bug. Because its status will still be untriaged and everyone will understand nobody has validated it. Then the prioritization will give a guide on where to start validating. Stephen M. Webb: > With well over 3000 bugs in the entire stack, just a simple linear > iteration for an individual to determine the importance of a bug is > untenable. That's why I'm suggesting working in confirmed bugs or also tagged with supported releases. On these we have the following scenario: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6472 bytes Desc: S/MIME Cryptographic Signature URL: From will.cooke at canonical.com Tue Aug 18 17:46:44 2015 From: will.cooke at canonical.com (Will Cooke) Date: Tue, 18 Aug 2015 18:46:44 +0100 Subject: Unity 7 & Compiz bug triage In-Reply-To: <20150818160753.GH32053@murraytwins.com> References: <20150818160753.GH32053@murraytwins.com> Message-ID: On 18 August 2015 at 17:07, Brian Murray wrote: > > 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. > Yeah, I think targeting NEW bugs is a better approach. Perhaps when all of those are dealt with we could move on to the others, starting with Confirmed. Certainly where some work has already been done it would be silly to throw that away unnecessarily. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.cooke at canonical.com Tue Aug 18 18:23:22 2015 From: will.cooke at canonical.com (Will Cooke) Date: Tue, 18 Aug 2015 19:23:22 +0100 Subject: Unity 7 & Compiz bug triage In-Reply-To: References: <20150818160753.GH32053@murraytwins.com> Message-ID: On 18 August 2015 at 18:46, Will Cooke wrote: > Yeah, I think targeting NEW bugs is a better approach. Perhaps when all > of those are dealt with we could move on to the others, starting with > Confirmed. Certainly where some work has already been done it would be > silly to throw that away unnecessarily. > > Having just spent a couple more minutes poking around in LP I'm starting to think that I would class bugs which are "confirmed" by LP janitor because they affect multiple people AND have a low heat as NEW in the above scenario. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.cooke at canonical.com Tue Aug 18 18:28:28 2015 From: will.cooke at canonical.com (Will Cooke) Date: Tue, 18 Aug 2015 19:28:28 +0100 Subject: Unity 7 & Compiz bug triage In-Reply-To: <55D3624E.6060007@gmail.com> References: <55D1CDB8.3000702@gmail.com> <55D32484.9080604@canonical.com> <55D3624E.6060007@gmail.com> Message-ID: On 18 August 2015 at 17:50, Alberto Salvia Novella wrote: > > Stephen M. Webb: > > Most of these bugs are in the form 'Unity mysteriously crashed for no > > reason' and has been autoconfirmed because someone saw it and clicked > > 'affects me' -- they also saw a crash window pop up for no reason. > > What I'm suggesting is setting importance without validating the bug. > Because its status will still be untriaged and everyone will understand > nobody has validated it. Then the prioritization will give a guide on where > to start validating. > > In order to set an importance someone would need a good understanding of the Unity 7 project and a bug's real importance vs how a particular user views it. We have a big enough pool of experts to allow us to complete this in a timely manner. I think we need to shoot for a process which can be be performed by anyone, without training, and done quickly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at ubuntu.com Tue Aug 18 18:28:54 2015 From: brian at ubuntu.com (Brian Murray) Date: Tue, 18 Aug 2015 11:28:54 -0700 Subject: Unity 7 & Compiz bug triage In-Reply-To: References: <20150818160753.GH32053@murraytwins.com> Message-ID: <20150818182854.GK32053@murraytwins.com> On Tue, Aug 18, 2015 at 07:23:22PM +0100, Will Cooke wrote: > On 18 August 2015 at 18:46, Will Cooke wrote: > > > Yeah, I think targeting NEW bugs is a better approach. Perhaps when all > > of those are dealt with we could move on to the others, starting with > > Confirmed. Certainly where some work has already been done it would be > > silly to throw that away unnecessarily. > > > > > > Having just spent a couple more minutes poking around in LP I'm starting to > think that I would class bugs which are "confirmed" by LP janitor because > they affect multiple people AND have a low heat as NEW in the above > scenario. Yes, although keep in mind that the apport-retracer automatically duplicates bug reports which would make the status "Confirmed" so it'd be worthwhile to separate those out. Here's an example. http://launchpad.net/bugs/1438210 -- Brian Murray -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: From es20490446e at gmail.com Thu Aug 20 11:06:17 2015 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Thu, 20 Aug 2015 13:06:17 +0200 Subject: Unity 7 & Compiz bug triage In-Reply-To: References: <55D1CDB8.3000702@gmail.com> <55D32484.9080604@canonical.com> <55D3624E.6060007@gmail.com> Message-ID: <55D5B4A9.1010701@gmail.com> Will Cooke: > I think we need to shoot for a process which can be be performed by > anyone, without training, and done quickly. If the process is in a wiki that is written in such a way that anyone could understand it, and it is broken into steps and short pages so people read exactly the amount of information they need in that moment in time, then it would do the job. You can also provide the adequate links to which bugs you want people to work on in Launchpad, so they don't need to figure out how to use the advance search feature themselves. Also if you provide some way of visually measuring process you will see that people gets much more motivated. In fact this is why everyone is that hanged to social networking today; because everything from likes, friends, and messages are quantified. When you see this figures going where you want, you get motivated by design. Just keep in mind we are doing things easier for any kind of people. Perhaps in this case not as much diverse people as following, but you will get the idea: Thank you. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6472 bytes Desc: S/MIME Cryptographic Signature URL: From will.cooke at canonical.com Thu Aug 20 11:33:06 2015 From: will.cooke at canonical.com (Will Cooke) Date: Thu, 20 Aug 2015 12:33:06 +0100 Subject: Unity 7 & Compiz bug triage In-Reply-To: <55D5B9DA.9070409@canonical.com> References: <55D1CDB8.3000702@gmail.com> <55D32484.9080604@canonical.com> <55D3624E.6060007@gmail.com> <55D5B4A9.1010701@gmail.com> <55D5B9DA.9070409@canonical.com> Message-ID: On 20 August 2015 at 12:28, Stephen M. Webb wrote: > Now there's an interesting suggestion: gamify the triaging system. > Anyone up for writing a mobile app for triaging > bugs? Publish daily high scores! Add a little bit of braincandy music > and pleasing sound whenever a bug goes from NEW > to some other status and some fancy animations, grab their attention then > keep them hooked. Seriously. > > I love this! It should be accessible from the U7 desktop as well, since that's where people will be doing the work. Maybe a web app would make things easier? -------------- next part -------------- An HTML attachment was scrubbed... URL: From es20490446e at gmail.com Thu Aug 20 12:12:30 2015 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Thu, 20 Aug 2015 14:12:30 +0200 Subject: Unity 7 & Compiz bug triage In-Reply-To: References: <55D1CDB8.3000702@gmail.com> <55D32484.9080604@canonical.com> <55D3624E.6060007@gmail.com> <55D5B4A9.1010701@gmail.com> <55D5B9DA.9070409@canonical.com> Message-ID: <55D5C42E.9050309@gmail.com> Will Cooke: > Maybe a web app would make things easier? Only if it will allow to easily make changes in the process if interesting. Just keep in mind that a process becomes efficient not because being well designed from the beginning only, but also because making small improvements day by day. Wikis are very useful for that because you can make these improvements very easily. And still provide plenty of visuals that can even be updated remotely and automatically, like graphs. But if you find a way of doing those changes easily in an app, then it could be okay too. Just I cannot figure it out myself, because one interesting question would be who could make those improvements. Sometimes the most rudimentary solutions are the ones which works the best, as they are the easiest to change. On the other hand I see most people contributing much more if the experience was more interactive. Been the process undefined at this time, I would put it into a wiki for the moment and make it as interactive as possible. Rather than written like a document, like an interface: broken into steps and small pages, with images and visual cues on progress. You can put this cues on a folder synced in the cloud, and let a script update these automatically or even do it manually. Then when that wiki looks somehow matured, you can evaluate if to pour it into an app. If done before probably you will be constantly reworking the app. Thanks ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6472 bytes Desc: S/MIME Cryptographic Signature URL: From stephen.webb at canonical.com Thu Aug 20 11:28:26 2015 From: stephen.webb at canonical.com (Stephen M. Webb) Date: Thu, 20 Aug 2015 07:28:26 -0400 Subject: Unity 7 & Compiz bug triage In-Reply-To: <55D5B4A9.1010701@gmail.com> References: <55D1CDB8.3000702@gmail.com> <55D32484.9080604@canonical.com> <55D3624E.6060007@gmail.com> <55D5B4A9.1010701@gmail.com> Message-ID: <55D5B9DA.9070409@canonical.com> On 15-08-20 07:06 AM, Alberto Salvia Novella wrote: > Will Cooke: >> I think we need to shoot for a process which can be be performed by >> anyone, without training, and done quickly. > > If the process is in a wiki that is written in such a way that anyone could understand it, and it is broken into steps > and short pages so people read exactly the amount of information they need in that moment in time, then it would do the > job. > > You can also provide the adequate links to which bugs you want people to work on in Launchpad, so they don't need to > figure out how to use the advance search feature themselves. This is an excellent suggestion: even something as simple as a link from a "how can I help" page to a pre-canned Launchpad bug search would be a start. It is in fact difficult right now for an outsider to easily fund some way to contribute. > Also if you provide some way of visually measuring process you will see that people gets much more motivated. In fact > this is why everyone is that hanged to social networking today; because everything from likes, friends, and messages are > quantified. When you see this figures going where you want, you get motivated by design. Now there's an interesting suggestion: gamify the triaging system. Anyone up for writing a mobile app for triaging bugs? Publish daily high scores! Add a little bit of braincandy music and pleasing sound whenever a bug goes from NEW to some other status and some fancy animations, grab their attention then keep them hooked. Seriously. -- Stephen M. Webb