0:00:05.351,0:00:06.936
I'm Solveig.

0:00:07.961,0:00:10.115
Here you have my contact info.

0:00:12.555,0:00:18.888
I use Free Software and especially Debian[br]since quite some time now

0:00:19.130,0:00:22.095
and I also contribute to Tails

0:00:22.502,0:00:28.640
so my interests are in privacy…

0:00:44.255,0:00:47.336
No? Yes? Do you hear me?

0:00:53.360,0:00:56.690
I do some non-developer things

0:00:56.690,0:01:03.401
and in Debian I found a way to contribute[br]without coding

0:01:03.881,0:01:07.147
or maintaining packages which is to[br]triage bugs.

0:01:11.703,0:01:14.582
Bug triaging, it helps,

0:01:15.484,0:01:21.999
it's kind of non visible but it helps[br]Debian as a whole

0:01:22.195,0:01:26.907
because maintainers don't always[br]have the time to deal

0:01:26.907,0:01:28.371
with all their bug reports,

0:01:28.614,0:01:31.499
some packages have a lot of[br]bug reports,

0:01:31.824,0:01:35.968
like the kernel or Xorg.

0:01:39.700,0:01:44.822
Also, it's a good way to improve the[br]package quality.

0:01:45.147,0:01:50.306
When some packages have a lot of[br]bugs open against them,

0:01:51.974,0:01:57.051
it can make it harder for the maintainers[br]to know which ones are

0:01:57.051,0:02:03.136
solvable, actionable, and they can get a bit[br]over their head.

0:02:04.483,0:02:10.541
So when you triage bugs, you help[br]everybody have a better experience

0:02:10.541,0:02:11.839
with Debian.

0:02:13.584,0:02:15.694
So, you want to do it.

0:02:17.406,0:02:18.856
First, it's easy.

0:02:19.028,0:02:22.966
You don't need to learn any new tool[br]supposing you already know

0:02:22.966,0:02:25.320
how to read and write e-mail.

0:02:26.552,0:02:32.029
So that's a low threshold to start.

0:02:33.288,0:02:38.290
It's very rewarding, the maintainers are[br]happy when you help them,

0:02:38.290,0:02:41.450
even if you don't touch their packages,

0:02:41.450,0:02:49.433
if you sort their bugs, they'll be happy[br]and the users who submitted them

0:02:49.433,0:02:51.382
will be happy that somebody looked[br]at them

0:02:51.993,0:02:55.613
so it can be very joyful.

0:02:57.526,0:03:03.451
Also, you search random bugs for packages[br]you don't necessarily know,

0:03:04.181,0:03:07.793
so you learn about a lot of software[br]in Debian and

0:03:07.793,0:03:12.069
some of them are really really surprising[br]and you…

0:03:12.759,0:03:16.457
"Wha? What does this do?" and that's kind[br]of fun.

0:03:17.836,0:03:19.868
And of course, it saves kittens.

0:03:25.747,0:03:29.244
On this page, there's a…

0:03:30.710,0:03:36.154
The bug triage page is a howto page[br]I made some years ago, with tips

0:03:36.968,0:03:43.148
and this part, especially, has a list[br]of teams that added themselves

0:03:43.148,0:03:47.170
so that they want you to help[br]sort their bugs.

0:03:48.873,0:03:51.956
Those are the teams I worked with,[br]they're really really nice,

0:03:52.884,0:03:54.270
they don't bite.

0:03:56.546,0:03:59.031
They will let you know if you did an error,

0:03:59.031,0:04:02.603
they will answer your questions,[br]you can work together.

0:04:04.831,0:04:07.763
I don't recommend closing random bugs.

0:04:08.164,0:04:12.840
If you go and touch packages from people[br]you have not warned

0:04:12.840,0:04:17.077
or who are not willing to have somebody[br]touch their bugs,

0:04:17.077,0:04:20.445
you might have backfire.

0:04:22.517,0:04:28.290
To start, I think it's good to go packages[br]that you know people are happy

0:04:28.290,0:04:29.419
if you help with.

0:04:35.230,0:04:38.479
The first tool to triage bugs is UDD.

0:04:39.660,0:04:47.294
I don't know if you've ever tried it,[br]the interface is really great.

0:04:55.801,0:04:57.777
Here, I can show you.

0:05:02.151,0:05:04.112
Here, that's UDD.

0:05:06.546,0:05:08.504
So it's a bit arid like this, but

0:05:13.561,0:05:21.687
it allows you to select many many[br]types of packages,

0:05:23.107,0:05:25.667
we can see that later.

0:05:26.114,0:05:31.595
Then you can choose a team or[br]other criteria

0:05:32.694,0:05:38.021
and when you're happy about[br]your criteria, you search.

0:05:39.403,0:05:45.049
It will give you a list of packages[br]corresponding to your criteria

0:05:46.556,0:05:51.306
and you can select some more info[br]you want listed here.

0:05:53.718,0:05:55.628
So, that's UDD search.

0:06:02.455,0:06:08.505
I usually ignore the bug reports that[br]somebody has searched in the last year.

0:06:11.874,0:06:14.147
Probably somebody else will look at them,

0:06:14.147,0:06:18.005
let's look at those that are lost[br]in the limbos.

0:06:19.225,0:06:23.694
I select wontfix, moreinfo, upstream or[br]unreproducible.

0:06:23.978,0:06:27.593
Those are those that probably you can do[br]something on.

0:06:29.708,0:06:33.774
And then you chose a team, preferably[br]one of those that is listed

0:06:33.774,0:06:35.890
in the page we saw before.

0:06:45.329,0:06:50.247
Once you'll have selected a bug and[br]something to do on it,

0:06:50.247,0:06:52.523
you'll have to document what you do.

0:06:57.072,0:07:00.399
Because you can change many many stuff[br]on the bug,

0:07:00.399,0:07:07.108
you send the commands to[br]control@bugs.debian.org

0:07:07.352,0:07:12.433
but it's always nice to put a small[br]a small sentence, or 2 or 3

0:07:12.433,0:07:17.547
to say what made you conclude that is[br]the right change.

0:07:21.935,0:07:26.161
Also make sure the e-mail where you do[br]the commands is sent

0:07:26.161,0:07:31.811
to everybody interested, because[br]by default it only sends it

0:07:31.811,0:07:35.995
to the maintainer and the submitter[br]in some cases.

0:07:36.889,0:07:39.897
So if other people answered the bug[br]report saying

0:07:39.897,0:07:47.612
"Hey, I have the bug too" or if upstream[br]came by to explain something,

0:07:47.612,0:07:52.811
it's good to see all of those who[br]interacted on the bug report and

0:07:52.811,0:07:55.448
put them all in copy.

0:08:01.225,0:08:08.050
Ideally, people can receive the e-mail,[br]read what you're saying and

0:08:08.050,0:08:11.788
don't have to go back to the bug page[br]to read it again.

0:08:12.716,0:08:19.958
So that you should sum up the thread[br]if it was long and have them know everything.

0:08:28.821,0:08:35.239
If you do massive triage, you should have[br]a few generic messages

0:08:35.239,0:08:40.605
so you keep the messages and just[br]replace the words as needed.

0:08:41.454,0:08:43.531
It saves you a lot of time.

0:08:44.827,0:08:50.519
Also, it allows you to put a lot of[br]nice things in your generic e-mail

0:08:50.519,0:08:53.724
that people are always happy to read[br]without more effort.

0:08:54.608,0:08:58.237
You know, add a little "Thanks for[br]submitting the bug" or

0:08:58.237,0:09:04.339
"That was a very interesting discussion"[br]or something like that.

0:09:06.084,0:09:10.153
Let's keep the positive energy flowing.

0:09:13.001,0:09:17.838
There are many ways to triage.

0:09:18.366,0:09:21.417
One of them is trying to reproduce[br]bug reports.

0:09:22.065,0:09:26.169
In the UDD we saw earlier, if you select[br]'unreproducible'

0:09:26.453,0:09:30.113
Oh no… those that don't have the tag[br]'confirmed',

0:09:30.878,0:09:36.526
these are bugs that one person submitted[br]but nobody knows if they're really

0:09:36.526,0:09:42.217
still up to date or if it's just, somebody[br]submitted it but…

0:09:43.755,0:09:48.158
If it's confirmed, there's more chance[br]that the maintainer will look at them.

0:09:50.344,0:09:54.092
If they're really old, maybe they have been[br]corrected and nobody bothered

0:09:54.092,0:09:55.434
to close the bug.

0:09:57.181,0:10:03.233
If they're new, maybe you should have[br]them too, so see if it's the case.

0:10:04.252,0:10:06.973
If it's the case, you write to this adress

0:10:06.973,0:10:15.755
the 'nnn' is the number of the bug and[br]you add the tag 'confirmed'

0:10:17.455,0:10:22.550
That's how we interact with control@b.d.o

0:10:23.883,0:10:29.825
All the bug tracking is on a e-mail[br]interface

0:10:31.247,0:10:33.764
'found bugnumber versionnumber'

0:10:36.164,0:10:40.102
that's a command that control will[br]recognize,

0:10:40.386,0:10:43.226
you give the bug number and what version[br]you're running.

0:10:44.361,0:10:47.696
You add the tag 'confirmed'.

0:10:48.267,0:10:50.666
Since you found it, you're 2, so it's[br]confirmed.

0:10:51.073,0:10:56.391
And 'thanks', you always have to end[br]your e-mails to control with 'thanks'

0:10:56.391,0:10:59.810
or 'thank you' or whatever variation[br]of it you want.

0:11:00.782,0:11:06.233
The control is a very very polite beast[br]and likes you to be the same.

0:11:07.861,0:11:11.928
If you don't put politeness, it won't work.

0:11:13.383,0:11:16.803
Actually it's to tell them that the commands[br]are done, but

0:11:16.803,0:11:19.969
let's be polite also with machines.

0:11:26.598,0:11:35.176
If the bug was not confirmed, you tried[br]to reproduce it and you couldn't.

0:11:37.450,0:11:44.280
You could add the tag 'unreproducible' or[br]'moreinfo'

0:11:44.598,0:11:49.891
So, depending if you're quite sure that…[br]if you're not the first saying

0:11:49.891,0:11:54.743
"I can't reproduce it" or if you're sure[br]you have exactly the same setup as

0:11:54.743,0:11:56.091
the original submitter,

0:11:56.091,0:11:58.556
then you should put 'unreproducible'.

9:59:59.000,9:59:59.000
If it might be reproducible for other[br]people, but just not you,

9:59:59.000,9:59:59.000
then you should ask 'moreinfo' so that[br]the original submitter gives

9:59:59.000,9:59:59.000
more details on how to reproduce their bug

9:59:59.000,9:59:59.000
And it also requires you to be polite[br]at the end of the command.

9:59:59.000,9:59:59.000
An other very useful thing is to forward[br]them upstream.

9:59:59.000,9:59:59.000
Some upstream follow the Debian bug tracker

9:59:59.000,9:59:59.000
but a lot of them don't.

9:59:59.000,9:59:59.000
Maybe somebody reported the issue in[br]the Debian bug tracker but

9:59:59.000,9:59:59.000
upstream is not aware of it

9:59:59.000,9:59:59.000
and most Debian maintainers are not[br]gonna solve the bug themselves,

9:59:59.000,9:59:59.000
they're more probably gonna wait for it[br]to be corrected upstream,

9:59:59.000,9:59:59.000
so we need the bug to go back to where[br]it will be corrected

9:59:59.000,9:59:59.000
In a lot of cases, it can be because[br]upstream considers it not a bug,

9:59:59.000,9:59:59.000
so won't fix it, so let's say it on the[br]Debian bug too

9:59:59.000,9:59:59.000
or maybe upstream is not aware of[br]the bug so…

9:59:59.000,9:59:59.000
Ok, that's very tiny…

9:59:59.000,9:59:59.000
At least you have all.

9:59:59.000,9:59:59.000
Here you have the command to add[br]the upstream bug tracker number.

9:59:59.000,9:59:59.000
"forwarded bugnumber", you put the URL[br]in the upstream's bug tracker

9:59:59.000,9:59:59.000
and then you say thanks again.

9:59:59.000,9:59:59.000
So that's what I was saying before, you[br]can also report it upstream

9:59:59.000,9:59:59.000
if it hasn't been already.

9:59:59.000,9:59:59.000
Sometimes, the upstream bug tracker[br]is more up to date,

9:59:59.000,9:59:59.000
so in upstream it's fixed, so it's good[br]to let know to the Debian bug tracker

9:59:59.000,9:59:59.000
and add the tag 'fixedupstream'

9:59:59.000,9:59:59.000
and it's good to say in which version[br]so that the maintainer may be

9:59:59.000,9:59:59.000
motivated to update to the new version.

9:59:59.000,9:59:59.000
In lot of cases, the bug reports are tagged[br]'moreinfo', which is

9:59:59.000,9:59:59.000
somebody said "It doesn't work", which,[br]sorry for you, but there's no chance

9:59:59.000,9:59:59.000
it's gonna be fixed with that.

9:59:59.000,9:59:59.000
So in lots of cases, the bug is tagged[br]'moreinfo' to say

9:59:59.000,9:59:59.000
"This bug does not give enough info[br]to be solved"

9:59:59.000,9:59:59.000
Or sometimes, the maintainer[br]packages a new version

9:59:59.000,9:59:59.000
and you think probably the bug is[br]solved,

9:59:59.000,9:59:59.000
and you also need to ask the original[br]submitter if they still have the bug

9:59:59.000,9:59:59.000
Or somebody said "Oh I'm gonna to some[br]fix next weekend" and it's 2 years later

9:59:59.000,9:59:59.000
and you're not sure they actually did[br]the test they were saying they would do.

9:59:59.000,9:59:59.000
So, info were asked and it feels like[br]the bug is hanging.

9:59:59.000,9:59:59.000
In those cases, it's helpful, sometimes,[br]to send an e-mail to the person who said

9:59:59.000,9:59:59.000
"I'm gonna do something" or who needs to[br]answer if they still have the bug

9:59:59.000,9:59:59.000
and saying "Hey! that's a gentle ping"

9:59:59.000,9:59:59.000
"You said you would test" or "Can you still[br]reproduce a bug?"

9:59:59.000,9:59:59.000
so that you can update the status of the[br]bug on the bug tracker.

9:59:59.000,9:59:59.000
It's good to wait, like, a good amount of[br]time before bothering people

9:59:59.000,9:59:59.000
about this kind of thing.

9:59:59.000,9:59:59.000
I usually wait one year, like I told you,[br]probably shorter might be good,

9:59:59.000,9:59:59.000
but it's good also not to harass people,[br]they have a life.

9:59:59.000,9:59:59.000
Sometimes, the bugs have been tagged[br]'moreinfo' or 'wontfix' for a long time

9:59:59.000,9:59:59.000
The info is not given, or it's unlikely[br]that somebody else wants

9:59:59.000,9:59:59.000
this 'non-bug' fixed.

9:59:59.000,9:59:59.000
Different teams have different policies[br]but most of them will be happy

9:59:59.000,9:59:59.000
if you close the bugs that nobody is gonna[br]do anything about.

9:59:59.000,9:59:59.000
If the bug was tagged 'moreinfo' more than[br]a year ago and

9:59:59.000,9:59:59.000
nobody answered to give more info, or if[br]a major release came out and

9:59:59.000,9:59:59.000
probably the bug is fixed but the original[br]submitter doesn't answer

9:59:59.000,9:59:59.000
then it's good to close them, in most[br]cases, depending on the team.

9:59:59.000,9:59:59.000
But it's good to ping them before you[br]close

9:59:59.000,9:59:59.000
give them a reasonable amount of time[br]to try to test it again.

9:59:59.000,9:59:59.000
Ok, we don't have the bottom of the page.

9:59:59.000,9:59:59.000
The command to…

9:59:59.000,9:59:59.000
The command to close a bug is to write to[br]-done@control.b.d.o

9:59:59.000,9:59:59.000
Maybe I shouldn't have done that.

9:59:59.000,9:59:59.000
And closing the bugs is kind of one of[br]the most satisfying things to do.

9:59:59.000,9:59:59.000
Sometimes, I speak with my maintainer[br]friends and I say

9:59:59.000,9:59:59.000
"Hey, I closed 25 bugs today" and they're[br]kind of jealous because

9:59:59.000,9:59:59.000
when you have to actually work on the bugs[br]to close them,

9:59:59.000,9:59:59.000
you can rarely fix 25 in one day.

9:59:59.000,9:59:59.000
So it's kind of the perks of doing[br]bug triaging.

9:59:59.000,9:59:59.000
You know, less bugs on the bug tracker,[br]I'm very efficient today.

9:59:59.000,9:59:59.000
But don't close random stuff, but when[br]you find useless stuff to close,

9:59:59.000,9:59:59.000
it feels good.

9:59:59.000,9:59:59.000
Where am I?

9:59:59.000,9:59:59.000
We missed the last sentence earlier.

9:59:59.000,9:59:59.000
When trying to reproduce a bug, you[br]should pay particularly attention to

9:59:59.000,9:59:59.000
the games team.

9:59:59.000,9:59:59.000
You know, like, people open bug reports[br]against the game team and then

9:59:59.000,9:59:59.000
Oh no, you have to install a bunch of[br]games to try to reproduce bugs,

9:59:59.000,9:59:59.000
you know, but for work, so you install[br]a lot of games and

9:59:59.000,9:59:59.000
you try to see if they're buggy, so that's[br]also another perk of triaging bugs,

9:59:59.000,9:59:59.000
you get to try all the latest games.

9:59:59.000,9:59:59.000
An other thing is when people open a bug[br]and didn't check if there was

9:59:59.000,9:59:59.000
already one open.

9:59:59.000,9:59:59.000
It ends up being 2 reports for the same bug.

9:59:59.000,9:59:59.000
It's good to merge them so that's clearer.

9:59:59.000,9:59:59.000
The 2 bug reports must be on the same[br]package, with the same severity

9:59:59.000,9:59:59.000
and the same state,

9:59:59.000,9:59:59.000
otherwise you can't merge, so you have[br]to send first the commands to do that,

9:59:59.000,9:59:59.000
like I showed before, and at the end you[br]tell the bug tracker to merge.

9:59:59.000,9:59:59.000
So, that we've seen.

9:59:59.000,9:59:59.000
You can…

9:59:59.000,9:59:59.000
Ok, you can't really see the…

9:59:59.000,9:59:59.000
So, I was giving an example of my standard[br]message I paste when I close a bug

9:59:59.000,9:59:59.000
and we don't see the end, but I'm gonna[br]do it from memory, it says

9:59:59.000,9:59:59.000
"Hi! I'm closing this bug, since it was[br]tagged 'moreinfo' for years

9:59:59.000,9:59:59.000
without answer. If you still experience[br]the issue, please feel free to reopen it

9:59:59.000,9:59:59.000
or ask me to do it" because some people[br]don't know how to reopen a bug

9:59:59.000,9:59:59.000
that has been archived.

9:59:59.000,9:59:59.000
So that's a very standard message,[br]no nothing, it's not very long.

9:59:59.000,9:59:59.000
That is good to have a model so that[br]you can just paste, with niceness in it.

9:59:59.000,9:59:59.000
If you're not sure about a bug report,

9:59:59.000,9:59:59.000
you read through it and you're still[br]not sure what to do

9:59:59.000,9:59:59.000
because, let's be clear, I don't always[br]understand what the issue is.

9:59:59.000,9:59:59.000
What you need to understand to triage[br]is what the status of the bug report is.

9:59:59.000,9:59:59.000
I triaged bugs for the kernel.

9:59:59.000,9:59:59.000
I don't understand anything about[br]the kernel, like most human beings

9:59:59.000,9:59:59.000
but, without understanding the bug report,[br]you can understand if somebody asks

9:59:59.000,9:59:59.000
for info and nobody provided it

9:59:59.000,9:59:59.000
or, for example, for the kernel, all the[br]bug reports that were for the nouveau driver

9:59:59.000,9:59:59.000
that is not supported anymore,

9:59:59.000,9:59:59.000
it was possible to close them because[br]nobody cared anymore.

9:59:59.000,9:59:59.000
So you don't necessarily need to understand[br]what the bug is about

9:59:59.000,9:59:59.000
to do something about the bug report

9:59:59.000,9:59:59.000
but sometimes it's a bit more complicated,[br]you're not sure

9:59:59.000,9:59:59.000
just close the bug report, move to the[br]next one

9:59:59.000,9:59:59.000
There's probably an other one that's,[br]you know, low hanging

9:59:59.000,9:59:59.000
take the easy stuff.

9:59:59.000,9:59:59.000
Because if you do something wrong, or[br]if you bother the maintainer to ask

9:59:59.000,9:59:59.000
what should be done, then you're not[br]really helping,

9:59:59.000,9:59:59.000
you might be taking time from them that[br]would be best invested somewhere else.

9:59:59.000,9:59:59.000
Small warning, there are some people who[br]really don't like you touching

9:59:59.000,9:59:59.000
their bug reports.

9:59:59.000,9:59:59.000
I wish you not to encounter them.

9:59:59.000,9:59:59.000
I you do, just either ignore them or ask[br]the maintainers of the package you're triaging

9:59:59.000,9:59:59.000
to step in and help or you can also[br]contact the anti-harassment team.

9:59:59.000,9:59:59.000
But it's very rare and most of Debian[br]people are very nice people

9:59:59.000,9:59:59.000
and they'll be happy to cooperate and[br]discuss with you

9:59:59.000,9:59:59.000
and bug triaging is fun and rewarding[br]and easy.

9:59:59.000,9:59:59.000
Those are the links to the things that[br]are useful to triage.

9:59:59.000,9:59:59.000
The first one is…

9:59:59.000,9:59:59.000
Ok, the first one is bad, I'll correct it.

9:59:59.000,9:59:59.000
The second one is how to triage with[br]all the different commands

9:59:59.000,9:59:59.000
that are useful.

9:59:59.000,9:59:59.000
The third one is server control,

9:59:59.000,9:59:59.000
a reminder of all the different instructions[br]you can send to server control

9:59:59.000,9:59:59.000
which is the way to interact with[br]a bug report.

9:59:59.000,9:59:59.000
The last one is about only closing and[br]you don't interact with control,

9:59:59.000,9:59:59.000
you write to bugnumber-done, so that's[br]a different e-mail destination.

9:59:59.000,9:59:59.000
So, the idea was to have a workshop,[br]so this was the explanation part and now

9:59:59.000,9:59:59.000
let's close some bugs, or sort them,[br]maybe.