Ubuntu Wiki

   1 [18:02] <hggdh> 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 ;-).
   2 [18:02] <hggdh> 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.
   3 [18:03] <pedro_> 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)
   4 [18:04] <hggdh> 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:
   5 [18:04] <hggdh> QUESTION: what does 'hggdh' mean?
   6 [18:04] <hggdh> Let's get into the class now.
   7 [18:04] <hggdh> First, who we are (https://wiki.ubuntu.com/BugSquad)
   8 [18:04] <hggdh> 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).
   9 [18:05] <hggdh> Different from medical triage, though, we do not expect human death as a consequence of delayed treatment.
  10 [18:05] <hggdh> 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.
  11 [18:05] <hggdh> 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.
  12 [18:06] <hggdh> 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.
  13 [18:06] <hggdh> Again: triaging *ends* when a bug status is set to Triaged (see https://wiki.ubuntu.com/Bugs/Status).
  14 [18:06] <hggdh> 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.
  15 [18:07] <hggdh> 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*.
  16 [18:08] <hggdh> 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.
  17 [18:08] <hggdh> With that in mind...
  18 [18:08] <hggdh> 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.
  19 [18:09] <hggdh> DO: read https://wiki.ubuntu.com/BugSquad/KnowledgeBase. Really. No kidding
  20 [18:10] <hggdh> 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.
  21 [18:11] <hggdh> (if you wish to be a member of the BugSquad, we require that you sign it.)
  22 [18:12] <hggdh> 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...
  23 [18:13] <pedro_> Yes, remember that at the other side of the Computer there's a person , so please be nice
  24 [18:14] <pedro_> There's nothing much that you didn't learned before :
  25 [18:14] <pedro_> 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*.
  26 [18:15] <pedro_> 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).
  27 [18:16] <pedro_> And there's also Triagers who are not native English speakers, ie: myself and hggdh
  28 [18:17] <pedro_> 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
  29 [18:17] <pedro_> try to do your best:
  30 [18:17] <pedro_> 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 ;-)
  31 [18:18] <pedro_> and if you're unsure about something?
  32 [18:18] <pedro_> 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
  33 [18:20] <pedro_> 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
  34 [18:20] <pedro_> 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.
  35 [18:21] <pedro_> DO: _understand_ the problem. A lot of times we see a bug where a _consequence_ is described, but not the _cause_.
  36 [18:21] <pedro_> 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.
  37 [18:22] <pedro_> The point here is: if we do not understand what is the problem, then how can we correct it?
  38 [18:22] <pedro_> There are many ways to do that (er, _understand_, not solve); most will require learning
  39 [18:23] <pedro_> 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.
  40 [18:23] <pedro_> Also, it is important to keep in mind that *correlation is not causation* (see http://en.wikipedia.org/wiki/Correlation_does_not_imply_causation).
  41 [18:25] <hggdh> (and, on the correlation <-> causation issue, there is this very good xkcd strip, from today: http://xkcd.com/925/ )
  42 [18:25] <hggdh> so
  43 [18:26] <hggdh> 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)?
  44 [18:27] <hggdh> 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...).
  45 [18:27] <hggdh> ok. There are only positive 'DO's so far. Enough is enough.
  46 [18:28] <hggdh> 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.
  47 [18:28] <hggdh> yes! Finally something to, ah, not do...
  48 [18:29] <hggdh> INSTEAD, just mark it as "affects me too" (and subscribe to it, if you wish to know when the issue is resolved).
  49 [18:29] <hggdh> 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.
  50 [18:30] <hggdh> 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.
  51 [18:31] <hggdh> And do get on to #ubuntu-bugs, and ask for help there when in doubt. We do not bite...
  52 [18:31] <hggdh> Oh, since we are here:
  53 [18:32] <hggdh> 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).
  54 [18:33] <pedro_> And one of my favorites :
  55 [18:34] <pedro_> 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...
  56 [18:34] <pedro_> 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.
  57 [18:35] <pedro_> I've seen a few new triagers doing that, so remember that DO / DO NOT, is *really* important
  58 [18:35] <pedro_> Other that is on my list of favorites is :
  59 [18:35] <pedro_> 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...
  60 [18:36] <pedro_> 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).
  61 [18:37] <pedro_> 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.
  62 [18:37] <pedro_> The ideal scenario is we have our packages identical to what upstream provide, no local patchs (except, probably, for packaging details).
  63 [18:38] <pedro_> 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).
  64 [18:38] <pedro_> 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:
  65 [18:39] <pedro_> 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
  66 [18:40] <pedro_> Many upstreams have different rules on how to open/work with/close a bug. Ergo,
  67 [18:41] <pedro_> DO: follow upstream's processes when working upstream (in an old saying, "when you enter a city, abide by its laws and customs").
  68 [18:42] <pedro_> DO NOT: Forward bugs upstream if you're unsure of the root cause, some bugs could be caused by an Ubuntu patch.
  69 [18:42] <pedro_> If you want to see if a package is patched by Ubuntu or not as a first clue look at http://patches.ubuntu.com/
  70 [18:42] <pedro_> And..
  71 [18:42] <pedro_> 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/
  72 [18:43] <hggdh> 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:
  73 [18:44] <hggdh> (1) *does* fix the bug;
  74 [18:44] <hggdh> (2) does *not* introduce a regression (see http://en.wikipedia.org/wiki/Software_regression)
  75 [18:45] <hggdh> 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...
  76 [18:46] <hggdh> DO: test SRUs. This helps on allowing timely updates to the user base.
  77 [18:46] <hggdh> 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
  78 [18:47] <hggdh> If you're really new to Triage and Ubuntu but you want to help:
  79 [18:47] <hggdh> 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...
  80 [18:48] <hggdh> DO: consider joining #ubuntu-bugs, and asking for help there. We -- the (so called) experienced triagers -- are all there.
  81 [18:49] <hggdh> (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)
  82 [18:49] <hggdh> BUT... please remember:
  83 [18:49] <hggdh> DO NOT: Start doing triage work by your own, its always better to ask first to the people who know about it.
  84 [18:50] <hggdh> and read the documentation we pointed to above ;-)
  85 [18:50] <hggdh> #ubuntu-bugs is open 24/7 so if you're unsure please ask there first. We *will* answer, probably in the same hour :-)
  86 [18:51] <hggdh> Finally... (and this is not a DO/DO NOT):
  87 [18:51] <hggdh> Please help. We need triagers, and we need triaging.
  88 [18:51] <hggdh> thank you.
  89 [18:51] <pedro_> is there any questions?
  90 [18:54] <pedro_> seems not. Thanks all and remember if you have doubts about bugs just ask in #ubuntu-bugs ; we don't bite
  91 [18:54] <pedro_> thanks again!
  92 [18:57] <hggdh> we really do not bite, those more dangerous are kept in a special enclosure, and well-fed ;-)