== Open Week -- Bug Triaging: Do's and Do not's -- hggdh -- Fri, Oct 15 == {{{#!IRC [18:01] Logs for this session will be available at http://irclogs.ubuntu.com/2010/10/15/%23ubuntu-classroom.html following the conclusion of the session. [18:01] Hello. My name is Carlos de-Avillez. I am one of the administrators for the BugSquad and BugControl teams on Ubuntu. I have been around bugs for pretty much all my professional life -- causing them, or finding them, or fixing them (or all three in sequence ;-). [18:01] I started with Ubuntu in 2006, when I was trying to find a Linux distribution that I felt more confortable with, and that did not need me to spend a lot of time tweaking the kernel, etc. And guess what... Ubuntu won! :-). I then joined the community, and started being active beginning of 2007. [18:02] Now, as usual, questions should be asked on the #ubuntu-classroom-chat channel. If you want to ask a question, write it there, and precede it with 'QUESTION:'. For example: [18:02] QUESTION: what does 'hggdh' mean? [18:02] Let's get into the class now. [18:02] First, who we are (https://wiki.ubuntu.com/BugSquad) [18:03] The BugSquad is the team responsible for *triaging* bugs opened against Ubuntu and its packages. The term 'triage' is pretty much taken from medicine -- determining the priority of treatments based on the severity of a condition (see http://en.wikipedia.org/wiki/Triage). [18:03] Different from medical triage, though, we do not expect human death as a consequence of delayed treatment. [18:04] But we still need to triage: there are many more bugs than triagers; we have to be able to prioritise the bugs; we _should_ be able to address _all_ bugs eventually. [18:05] For us, then, triage is the process of analysing a bug, collecting enough data to completely describe it, marking the bug 'Triaged', and give it an importance. [18:05] Triage ends there -- it is not our responsibility to *solve* the bug: once the issue is identified, and all necessary and sufficient documentation has been added to the bug, triaging *ENDS*, and the bug goes on to a developer/maintainer to be worked on. [18:06] sebsebseb asked: Why do Ubuntu developers hardly ever, if ever, fix upstream bugs? [18:07] We do... ideally our corrections/patches should be submitted to the upstream for analysis and acceptance. Sometime, though, we do not have the time or expertise to deal with it [18:07] and we, then, rely on upstream's knowledge to solve it [18:09] also, a lot of times we end up submitting our fixes upstream without any indication it was fixed by Ubuntu contributors -- which causes others to think we do nothing :-( [18:09] sebsebseb, did it help? [18:10] Back to the class: Again: triaging *ends* when a bug status is set to Triaged (see https://wiki.ubuntu.com/Bugs/Status). [18:10] This does not mean we do not solve bugs ourselves. Most of us wear a lot of hats, on (possibly) more than one project. But _triaging_ ends when the bug is set to Triaged. [18:10] sebsebseb, ^heh ;-) [18:11] Now, another important point is being able to differentiate between bugs (errors in a programme/package) and support issues (how to use a programme/package, how to set up something). We only deal with *bugs*. [18:11] Support requests should be redirected to one of the appropriate fora: http://askubuntu.com/, https://answers.launchpad.net/, http://ubuntuforums.org/, an appropriate IRC channel, etc. [18:11] jledbetter asked: Can anyone triage? Say, for example, I see a bug that is new can I -- random user -- 'confirm' it? Anything I can do to help? [18:12] yes, anyone can help (and we *do* hope we will have help) [18:13] if one can confirm a bug -- exact same scenario, reproduced/reproducible, then marking the bug confirmed will help [18:13] also, please add a comment stating how you reached the conclusion that you could confirm [18:14] With that in mind... [18:14] DO: follow the advices and recommendations from jledbetter's class (that just ended): they can be used not only for finding more about your own issues, but *ALSO* for triaging somebody else's bugs. [18:15] DO: read https://wiki.ubuntu.com/BugSquad/KnowledgeBase. Really. No kidding. [18:15] These pages give us a summary of all we learned during all the time we worked on triaging, what can be done, etc [18:16] DO: read the Code of Conduct (http://www.ubuntu.com/community/conduct). A nice exposition of the CoC is also at https://wiki.ubuntu.com/CodeOfConductGuidelines. [18:16] (if you wish to be a member of the BugSquad, we require that you sign it.) [18:17] This -- the CoC -- is perhaps the major difference between Ubuntu and other projects: we try very hard to live by it. *NOT* signing it does not free one from been required to be civil. So... [18:18] DO: be nice. Say 'please', and 'thank you'. It does help, a lot. Follow the Golden Rule (http://en.wikipedia.org/wiki/The_Golden_Rule), *always*. [18:19] DO: keep in mind that English is the official language on https://bugs.launchpad.net, but _many_ UBuntu bug reporters are *not* native speakers of English. This means that many times we will get bugs that are badly written in English (or not in English at all). [18:20] DO: Try to understand. Ask for someone else to translate it if you do not speak (er, read) the language (hint: the #ubuntu-translators and #ubuntu-bug channels will probably have someone able to translate). Be nice -- always. "I cannot understand you" is, most of the times, *not* nice ;-) [18:21] But, if you really cannot understand state something like: "I am sorry, but I cannot understand , could you please expand on yadda yadda and so on?" [18:22] (notice the "I am sorry", "please", etc) [18:22] Of course, "I am sorry, but you are an " does NOT do the trick. [18:23] DO: ask for help on how to deal with a bug if you are unsure. Nobody knows it all, and we all started ignorant on bug triaging (and, pretty much, on everything else ;-). We have a mailing list (Ubuntu-bugsquad@lists.ubuntu.com), and we are always at the #ubuntu-bugs channel on freenode. [18:24] We will be more than happy to help out on procedures and requirements. [18:24] Please note that we do not _triage_ bugs there -- we will answer and help on procedures and requirements. We will, though, point out deficiencies and missing data, and suggest actions. [18:25] DO: _understand_ the problem. A lot of times we see a bug where a _consequence_ is described, but not the _cause_. The triager should do her/his best to understand which is which, and act accordingly. This may mean changing the bug's package, or rewriting the description, etc. [18:26] But... if we do not understand what is the problem, then how can we correct it? [18:26] There are many ways to do that; most will require learning ;-) [18:27] most, also have never been really ported/adapted to computing (differential diagnosis -- medicine --, fault trees -- nuclear reactors, rockets --, etc). So... right now, the best way is to learn more. To keep on learning. With time you will be able to _intuitively_ see a consequence. [18:27] -> keep in mind that *correlation is not causation* (see http://en.wikipedia.org/wiki/Correlation_does_not_imply_causation). [18:28] DO: Try to ask and find answers for some questions: WHAT did happen? WHY did it happen? WHICH COMPONENTS are involved? HOW did it happen? HOW can it be REPEATED? What has CHANGED (if it worked before)? [18:29] So... you go on, aks the questions you fell pertinent, change the bug status (to Incomplete/New/Confirmed/Whatever). Now: [18:30] DO: add a comment on every action you take on the bug (changing status, importance, package, etc). Although for you it may be crystal-clear the reasons for taking an action, this may not be true for others (in fact, a lot of times it is not clear, at all...). [18:30] On the other hand... [18:30] DO NOT: add comments like "me too", "I also have it", "also a problem here", etc. These comments just pollute the bug, making it more difficult to find out what happened, where we are, and what is the next step. INSTEAD: [18:31] DO: just mark the bug as "affects me too" (and subscribe to it, if you wish to know when the issue is resolved). [18:32] DO: if you are starting on triage, browse the open bugs (there are about 80,000 of them) and look for one you feel _comfortable_ with (or less uncomfortable ;-). Ideally, you should be able to reproduce it. It does help if you start with bugs on packages you yourself use. [18:32] And [18:33] DO: get on to #ubuntu-bugs, and ask for help there when in doubt. We do not bite... :-) [18:33] Oh, since we are here: [18:33] DO NOT: change a Triaged bug to New/Incomplete/Confirmed -- a triaged bug is OUT OF SCOPE for triaging. It is not our problem anymore (while wearing the triager's hat). [18:34] (or course, if I am the developer/maintainer of a package affected by a bug, I can move it out of Triaged if I understand the bug is missing critical data) [18:35] DO NOT: assign yourself (or any other person) to a bug. Bug assignment is a clear, official, signal that "the assignee is actively working on resolving this issue". Nobody else -- including the developers/maintainers -- will touch this bug anymore. Instead... [18:35] DO: so... if you are triaging, and have asked a question/requested action from the OP (Original Poster), *subscribe* to the bug. Nothing is worse than a fire-and-forget action. [18:36] DO NOT: confirm your own bugs. The fact that you see/experience a bug does not necessarily _make_ it a real bug. It may be something on your setup... [18:36] DO: follow suggested actions. For some packages we have more detailed 'howtos'. These are described under the https://wiki.ubuntu.com/DebuggingProcedures page. It is always a good idea to check them (and update/correct as needed). [18:37] Now, a lot of the packages we offer on Ubuntu come from different projects -- Debian, Gnome, GNU, etc. We call these projects -- where real development usually takes place -- "upstream". By the same reasoning, we say we are "downstream" from them. [18:37] The ideal scenario is we have our packages identical to what upstream provide, no local patches (except, probably, for packaging details). [18:38] Having local changes increases the delta (the difference between what we provide and what upstream provides), and makes updates/upgrades more costly. So our patches, ideally, should be provided to the upstream project, and discussed there (and hopefully accepted). [18:39] Bugs affecting upstream projects have to be communicated upstream. This usually means doing a similar triage as we do here for a specific upstream (looking for an identical bug on the upstream project, and opening one if none is found). So. [18:40] DO: Look upstream, and open a new bug if needed; then *link* this upstream bug to ours (and ours to theirs). [18:40] For example, for Gnome applications, the upstream BTS (Bug Tracking System) is at http://bugzilla.gnome.org. [18:41] Many upstreams have different rules on how to open/work with/close a bug. Ergo, [18:42] DO: follow upstream's processes when working upstream (in an old saying, "when you enter a community, abide by its laws"). [18:43] Please note that this goes hand-in-hand with the CoC/Golden Rule. The fact that (in my original country) I could get to the beach wearing a speedo, does not make it nice (or even accepted) in the US (where I live). [18:44] autif asked: absolutely silly question, bust asking just because you have not covered it in your chat - what bugs are you talking about - Ubuntu bugs? Do they include other derivatives like xubuntu, kubuntu etc? Where are the stored? [18:45] I am talking primarily about Ubuntu bugs; but, of course, all official Ubuntu derivatives (i.e., those that have the BTS on https://launchpad.net) would be dealt in the same way [18:46] this applies, for example, to Xubuntu, Mythbuntu, Kubuntu, etc. But some of those derivatives may have their own particular way of dealing with bugs [18:47] IIRC, for a while (at least) Kubuntu suggested opening K* bugs directly upstream. === autif1 is now known as autif [18:48] But, even if they have special procedures, all I am stating here still applies in *full*. These DO/DONOT are really generic [18:49] Any other questions? I am almost done... [18:50] autif -- for some of the derivatives, you "assign" a bug to it by adding the project to the bug (for example, with Mythbuntu) [18:50] IdleOne asked: IF we are affected by a bug that has been open for a long time and there doesn't seem to be any work going on with it, what can we do? [18:51] There are 10 minutes remaining in the current session. [18:51] First, the short answer: *help* [18:51] Now, the longer one: [18:52] there are many more bugs than there are triagers. We need all help we can get. So, triaging an old bug (even if on self-interest) _still_ helps [18:52] checking upstream, opening upstream, etc. Confirming it is still present on the current Development/ or last published Stable release helps [18:53] but, please not something like "I am tired of waiting for you slackers to get this resolved" [18:53] This will not really help. No real new data, confirmation it still happens, etc. [18:54] and indeed, a comment on a bug will bring it back up to those subscribed to it (I, for example, subscribe to all server packages) [18:54] and there was a old one that has just being brought back to my attention this way [18:55] with this said, and no more questions... [18:55] Thank you. I am glad you were here, and I hope you help us out. And we are always (er, at least there is always someone logged it, we also have a life) available to help and discuss triaging work. [18:56] There are 5 minutes remaining in the current session. [19:01] Logs for this session will be available at http://irclogs.ubuntu.com/2010/10/15/%23ubuntu-classroom.html }}}