== Dev Week -- Bug Triage Class -- Carlos de-Avillez - Pedro Villavicencio -- Fri, Jul 15th, 2011 == {{{#!irc [18:02] 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, and not necessarily in the this order ;-). [18:02] I started with Ubuntu in 2006, when I was trying to (yet again) 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:03] Hola, My name is Pedro Villavicencio and i'm also one of the admins for BugSquad and BugControl teams on Ubuntu, I work as a Defect Analyst for the Desktop Team (so if you have bugs related to that please ping me) [18:04] 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:04] QUESTION: what does 'hggdh' mean? [18:04] Let's get into the class now. [18:04] First, who we are (https://wiki.ubuntu.com/BugSquad) [18:04] 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:05] Different from medical triage, though, we do not expect human death as a consequence of delayed treatment. [18:05] 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, verifying it indeed seems to be a valid bug, collecting enough data to completely describe it, and marking the bug 'Triaged', and give it an importance. [18:06] 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] Again: triaging *ends* when a bug status is set to Triaged (see https://wiki.ubuntu.com/Bugs/Status). [18:06] 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:07] 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:08] Support requests should be redirected to one of the appropriate fora: https://answers.launchpad.net/, http://askubuntu.com/ , http://ubuntuforums.org/, an appropriate IRC channel, etc. [18:08] With that in mind... [18:08] DO: follow the advices and recommendations from https://wiki.ubuntu.com/BugSquad/KnowledgeBase: they can be used not only for finding more about your own issues, but *ALSO* for triaging somebody else's bugs. [18:09] DO: read https://wiki.ubuntu.com/BugSquad/KnowledgeBase. Really. No kidding [18:10] DO: read the Ubuntu Code of Conduct (http://www.ubuntu.com/community/conduct). A nice exposition of the CoC is also at https://wiki.ubuntu.com/CodeOfConductGuidelines. [18:11] (if you wish to be a member of the BugSquad, we require that you sign it.) [18:12] 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:13] Yes, remember that at the other side of the Computer there's a person , so please be nice [18:14] There's nothing much that you didn't learned before : [18:14] 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:15] 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:16] And there's also Triagers who are not native English speakers, ie: myself and hggdh [18:17] and plenty more, so if you're triaging and not sure if your english is good enough, don't worry there's plenty of people to ask in #ubuntu-bugs about a comment you'd like to add to a bug report [18:17] try to do your best: [18:17] 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-bugs channels will probably have someone able to translate). Be nice -- always. "I cannot understand you" is, most of the times, *not* nice ;-) [18:18] and if you're unsure about something? [18:18] 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) : https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad, and we are always at the #ubuntu-bugs channel on freenode [18:20] You can ask either at the mailing list or at our IRC channel, there's plenty of folks there willing to help in a 24/7 [18:20] Please note that we do not _triage_ bugs on #ubuntu-bugs, or the ML -- we will answer and help on procedures and requirements. We will, though, point out deficiencies and missing data, and suggest actions. [18:21] DO: _understand_ the problem. A lot of times we see a bug where a _consequence_ is described, but not the _cause_. [18:21] 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:22] The point here is: if we do not understand what is the problem, then how can we correct it? [18:22] There are many ways to do that (er, _understand_, not solve); most will require learning [18:23] most processes & procedures for understanding a problem 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:23] Also, it is important to keep in mind that *correlation is not causation* (see http://en.wikipedia.org/wiki/Correlation_does_not_imply_causation). [18:25] (and, on the correlation <-> causation issue, there is this very good xkcd strip, from today: http://xkcd.com/925/ ) [18:25] so [18:26] 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:27] 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:27] ok. There are only positive 'DO's so far. Enough is enough. [18:28] 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. [18:28] yes! Finally something to, ah, not do... [18:29] INSTEAD, just mark it as "affects me too" (and subscribe to it, if you wish to know when the issue is resolved). [18:29] DO: if you are starting on triage, browse the open bugs (there are about 80,000 of them) and look for one you feel _confortable_ with (or less unconfortable ;-). Ideally, you should be able to reproduce it. It does help if you start with bugs on packages you yourself use. [18:30] We collected a set of Easy Tasks at: https://wiki.ubuntu.com/Bugs/EasyTasks/ ; that is a really good start if you don't know where to look at it first. [18:31] And do get on to #ubuntu-bugs, and ask for help there when in doubt. We do not bite... [18:31] Oh, since we are here: [18:32] 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:33] And one of my favorites : [18:34] 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:34] 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:35] I've seen a few new triagers doing that, so remember that DO / DO NOT, is *really* important [18:35] Other that is on my list of favorites is : [18:35] 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 patchs (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:38] 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:39] DO: Look upstream, and open a new bug if needed; then *link* this upstream bug to ours (and ours to theirs). If you want to see how that process is done, please check https://wiki.ubuntu.com/Bugs/Watches [18:40] Many upstreams have different rules on how to open/work with/close a bug. Ergo, [18:41] DO: follow upstream's processes when working upstream (in an old saying, "when you enter a city, abide by its laws and customs"). [18:42] DO NOT: Forward bugs upstream if you're unsure of the root cause, some bugs could be caused by an Ubuntu patch. [18:42] If you want to see if a package is patched by Ubuntu or not as a first clue look at http://patches.ubuntu.com/ [18:42] And.. [18:42] DO: Forward bugs upstream if you sure that is not caused by an Ubuntu patch. We have a set of instructions on how to do that at : https://wiki.ubuntu.com/Bugs/Upstream/ [18:43] So... we triaged a bug, eventually a developer/maintainer got to it, and fixed it -- or so they say ;-) --.Our job now, is to check if the fix provided indeed: [18:44] (1) *does* fix the bug; [18:44] (2) does *not* introduce a regression (see http://en.wikipedia.org/wiki/Software_regression) [18:45] For Ubuntu, a bug (on a stable release) is fixed by a SRU -- Stable Release Update, see https://wiki.ubuntu.com/StableReleaseUpdates. SRUs have to be tested and confirmed to follow (1) and (2) above. So... [18:46] DO: test SRUs. This helps on allowing timely updates to the user base. [18:46] Doing SRU Testing in most of the cases is an easy task to do, we always need help to deal with the queue: http://people.canonical.com/~ubuntu-archive/pending-sru.html [18:47] If you're really new to Triage and Ubuntu but you want to help: [18:47] DO: Consider requesting a Mentor, The BugSquad has a great program for that and you can find more info at : https://wiki.ubuntu.com/BugSquad/Mentors, or... [18:48] DO: consider joining #ubuntu-bugs, and asking for help there. We -- the (so called) experienced triagers -- are all there. [18:49] (I personally think going to #ubuntu-bugs to be more productive, since what I do not know (and there is a LOT of it) may be known by somebody else) [18:49] BUT... please remember: [18:49] DO NOT: Start doing triage work by your own, its always better to ask first to the people who know about it. [18:50] and read the documentation we pointed to above ;-) [18:50] #ubuntu-bugs is open 24/7 so if you're unsure please ask there first. We *will* answer, probably in the same hour :-) [18:51] Finally... (and this is not a DO/DO NOT): [18:51] Please help. We need triagers, and we need triaging. [18:51] thank you. [18:51] is there any questions? [18:54] seems not. Thanks all and remember if you have doubts about bugs just ask in #ubuntu-bugs ; we don't bite [18:54] thanks again! [18:57] we really do not bite, those more dangerous are kept in a special enclosure, and well-fed ;-) }}}