 I'm Salveg. Here you have my contact info. I use food software and especially Debian since quite some times now and I also contribute to Tails so my interests are in privacy. Okay, no? Yes? Do you hear me? So I do some non-developer things and in Debian I found a way to contribute without coding or maintaining packages which is to 3-H bugs. So bug-to-aging it helps it's like a 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 so 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 the head so when you 3-H 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 email so that's low threshold to start it's very rewarding the maintainers are happy when you help them even if you don't touch their packages just if you sort some of 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 when them bugs for packages you don't necessarily know so you learn about a lot of software and Debian and some of them are really really surprising and you what what does this do and that's kind of fun and of course it saves kittens so so on this page there's a so the bug 3-H page is a how-to 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. So those are the teams I worked with they are 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 like if you go and touch packages from people you have not one or who are not willing to have somebody touch their bugs you might have backfire so to start I think it's good to go to packages that you know people are happy if you help with. So the first tool to 3-H bugs is a UDD I don't know if you have ever tried it the interface is really great I yeah that's a UDD so it's a bit hard like this but it allows you to select this tool 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 then when you're happy about your criteria you search and it will give you a list of packages corresponding to your criteria and you can select what some more info you want listed here so that's UDD search so I usually ignore the package is a bug report that somebody has touched in the last year so probably somebody else will look at them let's look at those that are lost in the limbo's I select won't fix more info upstream or unreproducible so those are those that probably you can do something on and then you choose a team preferably one of those that is listed in the page we saw before so once you 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 your comments to control but it's always nice to put a small sentence or two or three to say what made you conclude that is the right change and so that's so also make sure the email where you do the commands is sent to everybody interested because by default it only sends it to the maintainer and submitter in some cases so if other people insert the bug report saying hey I have the bug too or if the 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 and ideally people can receive the email 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 sweat if it was long and have them know everything oh thank you if you do massive tree age 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 email that people are always happy to read without more effort so you know they add a little thanks for submitting the bug or that was very interesting construction discussion or something like that so that let's keep the positive energy flowing so there are many ways to create one of them is trying to reproduce bug reports so in the UDD we saw earlier if you select unreproducible oh no those that don't have the tag confirmed there are bugs that one person submitted but nobody knows if they're really still up to date or if it's just somebody submitted it but if it's confirmed there's more chance that the maintainer can will look at them so if they're really old maybe they have been corrected and nobody bother to close the bug if they're new maybe you should have them too so see if it's a case so if it's a case you write to this address so the NNN is the number of the bug and you add the tag confirmed so that's how we interact with the control at Debian so the all the bug tracking is on an email interface so found bug number version number so you that's a command that the control will recognize so you give the bug number and what version you're running you add the tag confirmed since you found it so you're too so it's confirmed and thanks you always have to end your emails to control with thanks or thank you or whatever variation of it you want the control is a very very polite beast and likes you to be the same so if you don't put the politeness it won't work actually it's to tell them the comments are done but let's be polite also with machines so if the bug was not confirmed so you try to reproduce it and you couldn't so you could add the tag unreproducible or more info so depending if you're quite sure that it if there were if you're not the first thing I can't reproduce it or if you're sure you have exactly the same setup as the original submitter then you should put unreproducible if it might be reproducible for other people but just not use and you should ask more info so that the original submitter gives more details on how to reproduce their bug and it also requires you to be polite at the end of the command another very useful thing is to forward them upstream so some of streams follow the Debian bug tracker but a lot of them don't so maybe somebody reported the issue in the Debian bug tracker but upstream is not aware of it and most Debian maintainers are not gonna solve the bugs themselves are more probably gonna wait for it to be corrected upstream so we need the bugs to go back to where it will be corrected so yeah and in a lot of cases it's also it can be because upstream considers it not a bug so won't fix it so let's say it on the Debian bug too or maybe upstream is not aware of the bug so okay okay that's very tiny at least you have all so here you have the command to add upstream bug tracker's number so forwarded bug number you put the value in the upstream's bug tracker and then you say thanks again so yes so that's what I was saying before so you can also report it upstream if it hasn't been already sometimes the upstream bug tracker is more up to date so in upstream it's fixed so it's good to let know to the Debian bug tracker and say at the tag fixed upstream and it's good to be to say in which version so that we the maintainer maybe maybe motivated to update to the new version so in a lot of cases the bug reports are tagged more info which is somebody said it doesn't work which sorry for you but there's no chance it's gonna be fixed with that so in lots of cases the bug is tagged more info to say this bug doesn't give enough info to be solved or sometimes as a new the maintainer packages a new version and you think probably the bug is solved and you also need to ask the original submitter if they still have the bug or somebody said oh I'm gonna do some text next weekend and it's two years later and no natural they actually did the test they were saying they would do oh so info were asked and it it's like the bug is hanging so in those case it's helpful sometimes to send an email to the person who said I'm gonna do something or who needs to answer knowing if they still have the bug and saying hey so that's a sender gentle ping you said you would test or can you still reproduce the bug and so that you can update the status of the bug on the bug tracker it's okay don't it's good to wait like a good amount of time before bothering people about this kind of thing like I usually wait one year like I told you probably shorter might be good but it's good also not to have as people they have a life so sometimes the bugs have been tagged more info or one fix for a long time and the more info the info is not given or it's unlikely that somebody else wants this non bug fixed so teams have different policies but most of them will be happy if you close the bug that nobody's gonna do anything about so like if the tag was tagged more info more than a year ago and nobody answered to give more info or if a major release came out and probably the bug is fixed but original submitter doesn't answer then it's good to close them in most cases depending of the team but it's good to ping them before you close like give them a with an abal amount of time to try to test it again okay we don't have the bottom of the page but so the command to the command to close the bug is to number of bugs slash done at control and closing the bugs is kind of one of the most satisfying things to do like I speak with my maintainer friends and I say hey I close 25 bucks today and they're kind of jealous because when you have to actually work on the bugs to close them you can rarely fix 25 in one day so it's kind of the perks of doing bug-tweaging you how a lot of you know less bugs than the bug tracker I'm very efficient today so but don't close random stuff but you know when you find useless stuff to close it feels good okay we missed the last sentence earlier when trying to reproduce a bug you pay should pay particularly attention to the game steam you know like people open bug reports against the game steam and then oh no you have to install a bunch of games to try to reproduce the bugs so you know but for work so you install a lot of games and you try to see if they're buggy so that's also another part of creating bugs you get to try all the latest games so another thing if is when people open a bug and didn't check if there was already one open so it ends up being two bugs for the same two reports for the same bug so it's good to merge them so that clear so the two bug reports must be on the same package with the same severity in the same state otherwise you can't merge so you have to send further commands to do that like I showed before and at the end you tell the bug tracker to merge so that was seen so you can okay we can't really see the bug so I was giving an example of my standout message I paced when I close a bug and we don't see the end but I'm gonna do it from memory so it says hi I'm closing these bugs in since in twastag more info for years without answer if you still experience the issue please feel free to reopen it or ask me to do it because some people don't know how to reopen a bug that has been archived so that's a very standard message no nothing it's not very long and it's very so it's but it's good to have a model so that you can just paste with niceness in it if you're not sure about the bug report you read through it and you're still not sure what to do because let's be clear I don't always understand what the issue is what you need to understand to create is what the status of the bug report is I create bugs for the kernel I don't understand anything about the kernel like most human beings but if you can without understanding the bug report you can understand if somebody asked for info and nobody provided it or for example a for the kernel all the bug reports that were for the nouveau driver that is not supported anymore they work there it was possible to close them because nobody cared about anymore so you don't necessarily need to understand what the bug is about to do something about the bug report but sometimes it's a bit more complicated you're not sure just close the bug report move to the next one there's probably another one that's you know low branches take the easy stuff because if you do something wrong or if you bother the maintainer to ask what should be done then you're not really helping you might be taking time from them that would be best invested somewhere else so small warning there are some people who really don't like you teaching them bug reports I wish you not to encounter them if you do just either ignore them or ask the maintainers of the of the package you're to aging to step in and help or you can also contact the anti harassment team but it's very rare and the most of deviant people are very nice people and they'll be happy to cooperate and discuss with you and back to aging is fun and rewarding and easy so those are the links to the things that are useful to create so the first one is okay somebody okay the first link is bad I'll correct it so the second one is how to create with all the different commands that are useful the third one is server control so where it remind of all the different instruction you can send to server control which is the way to interact with the bug report the last one is about only closing because you don't and you don't interact with control you write to bug number done so that's a different email destination so the idea what to have was to have a workshop so this was the explanation part and now let's close some bugs or sort them maybe