00:00 < Riddell> txwikinger is our ace beastie squisher
00:00 < Riddell> here to tell you how to help out with the millions of bugs we have, it's txwikinger!
00:01 < txwikinger> ok..let's look a little into our bug treatment
00:01 < txwikinger> I am not so famous like some others here.. so just a little bio
00:02 < txwikinger> === About Me ===
00:02 < txwikinger> * Free software enthusiast and advocate
00:02 < txwikinger> * Computer Science and law degrees
00:02 < txwikinger> * Started computing on unix
00:02 < txwikinger> * Worked as developer, system and network admin, and consultant in Telecom, Finances and Education industries.
00:02 < txwikinger> * Computer Science Lecturer at University
00:02 < nosrednaekim> txwikinger: law degree...... so I won't get sued by PETA for squashing bugs?
00:03 < txwikinger> yep.. that's the idea :)
00:03 < txwikinger> * Involved in Ubuntu/Kubuntu for nearly 1.5 years now and lately also a little bit for Debian.
00:03 < txwikinger> well.. I use Kubuntu since hoary, I believe
00:03 < txwikinger> * Doing advocacy, community stuff, bug triage and some packaging
00:04 < txwikinger> * Email me at txwikinger@ubuntu.com if you like
00:04 < txwikinger> or talk to me where I hang around in irc
00:04 < txwikinger> ok.. but now to the topic
00:04 < txwikinger> === What is bug triage? ===
00:04 < txwikinger> The word triage comes from the French word trier which means sorting, sifting (see http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=triage)
00:04 < txwikinger> Commonly it is used in the field of medicine, especially in the context of emergency rooms, disaster situations, basically when limited resources must be allocated to a high number of patients.
00:05 < txwikinger> This in an analogy that also describes what we do with bug-reports. When they are submitted, they must be checked if the adhere to a certain standard, contain all the necessary information that they can be fixed and be sorted and classified in order to get the right "resource" to work on it.
00:05 < txwikinger> In some way someone who triages bugs is something like a facilitator or arbitrator. You work with the reported in order to retrieve as much information as possible.
00:06 < txwikinger> reporter that is
00:06 < txwikinger> You also work with the developers for kubuntu and ubuntu as well as upstream distributions like KDE and debian and others in providing the information or finding out what information is needed.
00:06 < txwikinger> Due to the fact that all of this concerns people it is very important that bug triage is done with a lot of patience and humility.
00:07 < txwikinger> There are sometimes different interests that need to be mitigated when decisions are made, and it is always the best to be as polite as possible to everybody around (see also Ubuntu CoC https://launchpad.net/codeofconduct/1.0.1)
00:07 < txwikinger> The bug triage happens on launchpad https://bugs.launchpad.net/ In order to be able to triage bugs effectively, you must have an account on launchpad.
00:07 < txwikinger> Ok.. so far the theory...
00:08 < txwikinger> Let's see what is really done
00:08 < txwikinger> === There are different elements to triaging bugs ===
00:08 < txwikinger> ==== 1) Cleaning up bug reports: ====
00:08 < txwikinger> Bugs are often submitted by reporters that do not understand fully the process.
00:08 < txwikinger> On the other hand, the people working with the bugs need efficient access to the information.
00:09 < txwikinger> Therefore it can be very important to clean up the bugs summary to soemthing that is meaningful that in a list of reports someone already understand the main issue of every report in the list.
00:09 < txwikinger> It can also be helpful if certain important information is added to the description of the report, since this is the first thing after the summary one would read.
00:11 < txwikinger> Lets look at bug #240242
00:11 < txwikinger> Is this report well described?
00:12 < txwikinger> What would be helpful to know?
00:13 < txwikinger> yes.. good idea
00:14 < txwikinger> A developer probably would like to know exactly the build of firefox
00:14 < txwikinger> So it would be good to ask the reporter for the package version
00:15 < txwikinger> It would be interesting if firefox is the only app for which this happen
00:15 < txwikinger> So as you can see... lots of additional information is interesting and should be added
00:16 < txwikinger> This can also be done by the triager if it can be reproduced
00:16 < txwikinger> We also like to add workarounds if we know them into the description
00:16 < txwikinger> This way others who has this problem can easily work around them until they are fixed
00:17 < txwikinger> ==== 2) Colleting more information in order to be able to triage and/or reproduce and fix a bug ====
00:17 < txwikinger> This is in my opinion the most important step of bug triage. In an ideal world, a bug report has a description that allows anybody following it to immediately reproduce the bug.
00:17 < txwikinger> It is good practice to see if the description given is sufficient to reproduce or see the problem and if necessary add additional information if the problem is found.
00:18 < txwikinger> Here is an example, I have worked on: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/102979
00:19 < txwikinger> This was the original description: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/102979/comments/0
00:19 < txwikinger> I have made it a little more readable and have added the workaround I found
00:20 < txwikinger> I also added a question to the submitter and explained some more how to reproduce the problem
00:21 < txwikinger> Another important task:
00:21 < txwikinger> ==== 3) Sorting tasks. ====
00:21 < txwikinger> ===== 3a) Assigning the report to the right package =====
00:21 < txwikinger> Often reports are submitted without a package assigned to it
00:21 < txwikinger> An important part of the sorting of the reports is to assign them to the right package. The allows the right people to look at the bugs.
00:22 < txwikinger> Here are good instructions on how to find the right package to assigne a bug to:
00:22 < txwikinger> https://wiki.ubuntu.com/Bugs/FindRightPackage
00:22 < txwikinger> Sometimes it is not easy to understand from the beginning which the right packages is
00:23 < txwikinger> However, reports can easily be assigned to multiple packages, or packages can later be changed
00:23 < txwikinger> This is done by clicking on the Status value
00:23 < txwikinger> The opens up the fields that can be edited
00:24 < txwikinger> The first field is for the package
00:24 < txwikinger> there is also a search function if the complete name of the package is not known
00:24 < txwikinger> (Choose)
00:25 < txwikinger> In the same part the next task can be performed:
00:25 < txwikinger> ===== 3b) Entering the correct status: =====
00:25 < txwikinger> https://wiki.ubuntu.com/Bugs/CommonTasks#head-6e435bd3f0413458778d4688ea2f4983e90e6ab4 gives an overwiew of the different states a report can have.
00:25 < txwikinger> For the triage, the essential states are New, Incomplete, Confirmed and Invalid.
00:26 < txwikinger> very report start with the state New. When somebody starts to triage it and more information is necessary it will be set in the state incomplete until all the information is in the report.
00:26 < txwikinger> When all the information is in the report and the bug can be reproduced it will be set to the state Confirmed.
00:26 < txwikinger> A lot of reports will turn out either not to be bugs, or it is impossible to collect the necessary information that the report has a positive effect, i.e really helps to solve a problem.
00:27 < txwikinger> Sometimes reporters will not respond for request for the information needed, and it is not feasible or possible to recreate it yourself.
00:27 < txwikinger> In these cases the state will be changed to invalid.
00:27 < txwikinger> With all those state changes always keep in mind the consequences. We do not want to unnecessarily mark reports invalid because of laziness.
00:28 < txwikinger> A report might contain crucial information to solve a problem, sometimes not understood to the person that triages it.
00:28 < txwikinger> I am talking about bug triage at the moment, so yes :)
00:29 < txwikinger> Therefore, we do not close report lightly in this way. We always want to make sure the report has all the necessary information to be set for the next state.
00:29 < txwikinger> No problem :)
00:29 < txwikinger> Reports with missing information are set to Incomplete
00:29 < txwikinger> However, there should also always be instruction put in a comment how the reporter can collect the necessary information that is missing
00:30 < txwikinger> Another important task is to find:
00:30 < txwikinger> ==== 4) Duplicates ====
00:30 < txwikinger> While reporters are encouraged to first look for similar or identical problems in the bug tracker, it is inevidable that we get a lot of duplicate reports.
00:30 < txwikinger> Therefore a very important step during the information collection is to see if there is already another report.
00:31 < txwikinger> If this is the case, the report is linked to the original report (more here: https://wiki.ubuntu.com/Bugs/CommonTasks#head-170e00a7154fcfc87f0fc50f65bba9cff7ab27fe)
00:32 < txwikinger> ==== 5) Upstream reports: ====
00:32 < txwikinger> Often we will deal with issues that are problems in upstream packages.
00:32 < txwikinger> We are working very close with the upstream distros and it is a mutual benefit for everybody to get bug fixes introduced as high upstream as possible.
00:33 < txwikinger> For Kubuntu, KDE is in particular of interest. Here is an example of this https://bugs.launchpad.net/kdebase/+bug/96151
00:34 < txwikinger> In such cases you either find an already existing report in the upstream bugtracker and add it to the report, or you create a new report in the upstream bug tracker and add that one.
00:34 < txwikinger> Here are the instructions how to do this https://wiki.ubuntu.com/Bugs/HowToTriage#head-ab0eb9d7731fa877b5fc866eedc4c312dab50ee7
00:34 < txwikinger> Basically you choose the upstream project (KDE in this case) an add the url to the particular bug in their tracker.
00:35 < txwikinger> launchpad will then update periodically the state of the report in the upstream tracker.
00:35 < txwikinger> Actually this part takes a lot of my time when I am triage
00:36 < txwikinger> As faster we get reports to the proper places, as faster we get fixes back through our upstream packages
00:36 < txwikinger> Ok... I am breezing here a little fast through some of the steps
00:37 < txwikinger> The urls are supposed to give you references to look at when you get stuck while triaging
00:37 < txwikinger> hehe
00:37 < txwikinger> Well.. if you have a question, ask
00:38 < txwikinger> Or feel free to ask someone while you triage
00:38 < txwikinger> One of the really helpful things are:
00:38 < txwikinger> ==== 6) Standard Responses ====
00:39 < txwikinger> One thing that helps a lot, especially to maintain a polite and collaborative atmosphere are standard responses that can be adjusted to the particular situation.
00:39 < txwikinger> Here are lots of such responses for various situations: https://wiki.ubuntu.com/Bugs/Responses
00:39 < txwikinger> In particular I would like to raise the attention for this one:
00:39 < txwikinger> https://wiki.ubuntu.com/Bugs/Responses#head-6ee6466fdaac8c81274185f0316afd794d2ee0b6
00:40 < txwikinger> This can be used when the reporter does not responds (usually within a month) to the requests for more information and the existing information does not help to reproduce the problem.
00:40 < txwikinger> Another issue we often see is the following
00:40 < txwikinger> Look ast bug #240261
00:41 < txwikinger> Is this really a bug?
00:42 < Sundance> Okay, gotta go. Thank you all, thank you txwikinger and thank you Riddell. :)
00:42 < txwikinger> katastrophe: Yes.. I think this is rather a
00:42 < txwikinger> ==== 7) Support Requests ====
00:42 < txwikinger> Sometimes bug reports turn out to be really support requests.
00:42 < txwikinger> Reporters should be gently nudged to the support tracker in launchpad.
00:42 < txwikinger> It is certainly beneficial if inexperienced users are guided by the people that help to support them to filter out all the issues that are not really bugs.
00:43 < txwikinger> It is very easy to create a bug report linked to an existing question if it turns out to be such.
00:44 < txwikinger> In order to convert the report to a question, there is a link in the left margin of the report page
00:44 < txwikinger> "Convert to question"
00:44 < txwikinger> The Standard reposes above have a text that can be put into the field
00:44 < txwikinger> responses
00:45 < txwikinger> The questions can all be found at https://answers.launchpad.net/ubuntu/
00:46 < txwikinger> Ok.. this is all the issues I want to go through about how to deal with the reports during the triage process
00:46 < txwikinger> Now some fun things:
00:46 < txwikinger> ==== 8) Bug Days ====
00:46 < txwikinger> We have currently, I believe, weekly bug days where there is special focus on a particular class of bugs. Information can be found here: https://wiki.ubuntu.com/UbuntuBugDay
00:47 < txwikinger> I believe on Tuesday there will be OpenOffice reports that are particularily looked at
00:48 < txwikinger> We often have also in parallel specific KDE/Kubuntu packages that we focus on
00:48 < txwikinger> It is always lots of fun to work together on those lists and see them getting finished
00:49 < txwikinger> Questions can always be asks on ==== 9) The IRC channel: #ubuntu-bugs ====
00:50 < txwikinger> Dholbach has also started a nice motivational tool to do a little bit every day
00:50 < txwikinger> ==== 10) Five-a-day Teams ====
00:51 < txwikinger> https://wiki.ubuntu.com/5-A-Day
00:51 < txwikinger> Here are the stats for it http://daniel.holba.ch/5-a-day-stats/
00:52 < txwikinger> The idea is, to try to do a couple of bugs every day which over time gets a lot done
00:52 < txwikinger> ok.. coming to the end:
00:52 < txwikinger> ==== 11) Wrap up ====
00:52 < txwikinger> lways remember that we are working here in a team.
00:52 < txwikinger> Always remember that we are working here in a team.
00:52 < txwikinger> Therefore, we help each other. It is always good to ask questions if you are not sure how to proceed.
00:53 < txwikinger> Even for the most seasoned people it can be in tricky cases very helpful to have a second opinion.
00:53 < txwikinger> So if your are not sure about something ask somebody.
00:53 < txwikinger> I am often around on the IRC channels as txwikinger or txwikinger2
00:53 < txwikinger> Feel free to see me if I can help you.
00:54 < txwikinger> Here some more links with lots of helpful information:
00:54 < txwikinger> https://wiki.ubuntu.com/HelpingWithBugs
00:54 < txwikinger> https://wiki.ubuntu.com/BugSquad/KnowledgeBase
00:54 < txwikinger> https://wiki.ubuntu.com/DebuggingProcedures
00:54 < txwikinger> In particular for Kubuntu and KDE:
00:55 < txwikinger> https://wiki.kubuntu.org/Kubuntu/Bugs/Reporting
00:55 < txwikinger> https://wiki.kubuntu.org/DebuggingKDE
00:56 < txwikinger> https://wiki.kubuntu.org/Kubuntu/Bugs
00:57 * nosrednaekim clpas for txwikinger
00:58 < txwikinger> I hope you will all enjoy bug triage in the future
00:58 < txwikinger> It is a lot of fun !!!!!
00:58 < txwikinger> Riddell: yes.. if there aren't any questions
01:30 < Riddell> thanks seele, Nightrose, txwikinger
01:31 < txwikinger> thanks Riddell