I'm Solveig.
Here you have my contact info.
I use Free Software and especially Debian since quite some time now
and I also contribute to Tails
so my interests are in privacy…
No? Yes? Do you hear me?
I do some non-developer things
and in Debian I found a way to contribute without coding
or maintaining packages which is to triage bugs.
Bug triaging, it helps,
it's kind of non visible but it helps Debian as a whole
because maintainers don't always have the time to deal
with all their bug reports,
some packages have a lot of bug reports,
like the kernel or Xorg.
Also, it's a good way to improve the package quality.
When some packages have a lot of bugs open against them,
it can make it harder for the maintainers to know which ones are
solvable, actionable, and they can get a bit over their head.
So when you triage bugs, you help everybody have a better experience
with Debian.
So, you want to do it.
First, it's easy.
You don't need to learn any new tool supposing you already know
how to read and write e-mail.
So that's a low threshold to start.
It's very rewarding, the maintainers are happy when you help them,
even if you don't touch their packages,
if you sort their bugs, they'll be happy and the users who submitted them
will be happy that somebody looked at them
so it can be very joyful.
Also, you search random bugs for packages you don't necessarily know,
so you learn about a lot of software in Debian and
some of them are really really surprising and you…
"Wha? What does this do?" and that's kind of fun.
And of course, it saves kittens.
On this page, there's a…
The bug triage page is a howto page I made some years ago, with tips
and this part, especially, has a list of teams that added themselves
so that they want you to help sort their bugs.
Those are the teams I worked with, they're really really nice,
they don't bite.
They will let you know if you did an error,
they will answer your questions, you can work together.
I don't recommend closing random bugs.
If you go and touch packages from people you have not warned
or who are not willing to have somebody touch their bugs,
you might have backfire.
To start, I think it's good to go packages that you know people are happy
if you help with.
The first tool to triage bugs is UDD.
I don't know if you've ever tried it, the interface is really great.
Here, that's UDD.
So it's a bit arid like this, but
it allows you to select many many types of packages,
we can see that later.
Then you can choose a team or other criteria
and when you're happy about your criteria, you search.
It will give you a list of packages corresponding to your criteria
and you can select some more info you want listed here.
So, that's UDD search.
I usually ignore the bug reports that somebody has searched in the last year.
Probably somebody else will look at them,
let's look at those that are lost in the limbos.
I select wontfix, moreinfo, upstream or unreproducible.
Those are those that probably you can do something on.
And then you chose a team, preferably one of those that is listed
in the page we saw before.
Once you'll have selected a bug and something to do on it,
you'll have to document what you do.
Because you can change many many stuff on the bug,
you send the commands to control@bugs.debian.org
but it's always nice to put a small a small sentence, or 2 or 3
to say what made you conclude that is the right change.
Also make sure the e-mail where you do the commands is sent
to everybody interested, because by default it only sends it
to the maintainer and the submitter in some cases.
So if other people answered the bug report saying
"Hey, I have the bug too" or if upstream came by to explain something,
it's good to see all of those who interacted on the bug report and
put them all in copy.
Ideally, people can receive the e-mail, read what you're saying and
don't have to go back to the bug page to read it again.
So that you should sum up the thread if it was long and have them know everything.
If you do massive triage, you should have a few generic messages
so you keep the messages and just replace the words as needed.
It saves you a lot of time.
Also, it allows you to put a lot of nice things in your generic e-mail
that people are always happy to read without more effort.
You know, add a little "Thanks for submitting the bug" or
"That was a very interesting discussion" or something like that.
Let's keep the positive energy flowing.
There are many ways to triage.