[04:27] <tiox> Hey fellas. I'm writing an assignment for my college about how Ubuntu can be a vialbe alternative to WIndows, and I'd like to know if there are any success stories of colleges, schools and/or students who have succeeded with using Ubuntu. Anybody got links you can give off hand?
[04:28] <pleia2> tiox: this channel is for actual teaching of online classes, you probably want #edubuntu for that sort of thing
[04:28] <pleia2> tiox: however, I am part of partimus.org (we're a non-profit which put ubuntu computers in schools, among other things)
[04:28] <tiox> Permission to speak in private?
[04:28] <pleia2> sure
[12:19] <ari__> ...
[21:02] <ClassBot> Slides for Basics of Bug Triaging: http://people.ubuntu.com/~nhandler/slides/misc/BasicsOfBugTriaging.pdf
[21:02] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/04/05/%23ubuntu-classroom.html following the conclusion of the session.
[21:02] <ddecator> Alright, is everything all set?
[21:03] <pleia2> ddecator: yep, you're good to go! :)
[21:04] <ddecator> Perfect! Welcome everyone. Today I'll be talking about the basics of Bug Triage
[21:04] <ddecator> Before we begin, I just want to cover a couple of things
[21:04] <ddecator> First, this channel is moderated, so only pleia2 and myself can talk in here. #ubuntu-classroom-chat is open, and all questions should be asked there
[21:05] <ddecator> Questions should begin with "QUESTION:" so ClassBot will pick them up and allow me to go through them easily
[21:05] <ddecator> This way, things will not get confusing if people ask multiple questions at once
[21:06] <ddecator> Second, the slideshow ClassBot linked to is an in-depth slideshow I made. I have no intentions of going through the entire thing slide-for-slide today, but there are a few slides I will reference, and it may be helpful for you to save for later
[21:06] <ddecator> That being said, are there any quick questions before we begin?
[21:08] <ddecator> Alright, then we'll get started. If you have questions, ask them at any time, and when we have time I'll go through them. I plan on keeping this more informal so there will be plenty of time for questions. That way I will not repeat too much of what you all already know
[21:08] <ddecator> First, I want to address a fairly common question: Why is Bug Triage important?
[21:10] <ddecator> Anyone who takes a quick look at all of the bugs hosted on Launchpad, even for a specific package, will see that there are a LOT of reports. The majority of these reports are incomplete, and many may be duplicates, or not even real bug reports
[21:10] <ddecator> It would take a long time for developers to go through them all, and that would mean less time for them to work on actually fixing the bugs
[21:11] <ddecator> That's where triagers come in. We go through the reports, request missing information, clean them up, organize them, and get them prepared for the developers so they can concentrate on fixing the bugs
[21:11] <ddecator> Effective triage is very important in maintaining the flow of work in software development, and a project as large as Ubuntu especially needs the extra help
[21:12] <ddecator> So, why help with bug triage?
[21:12] <ddecator> It's a relatively easy way for people to get involved in the community, and we're always in need of extra help
[21:13] <ddecator> If you're interested in helping, you may wonder "Where do I begin?"
[21:14] <ddecator> Most of the information you will need is on the wiki, but it does not answer every question, and right now it's a lot of information that can be overwhelming (do not worry, we're working on a new structure in order to make things easier for everyone)
[21:15] <ddecator> To begin helping with triage, you'll need to have a Launchpad account setup. To save time, I will not go into detail on how to do so, but it should be relatively easy to figure out
[21:15] <ddecator> Once you have that setup, it's time to get your hands dirty and start working on some bugs!
[21:16] <ddecator> Where you begin is up to you, but I highly recommend new triagers start with bugs that have the status of "New"
[21:16] <ddecator> These bugs are usually untouched, and it gives you the opportunity to work with a bug from the very beginning
[21:17] <ddecator> [SLIDE 6]
[21:17] <ddecator> Rather than post a really long link here, there is a hyperlink on this slide which will bring you to a page with bugs that have been untouched (most likely) and are "New"
[21:18] <ddecator> It's generally a good idea to begin with a package that you use and are familiar with, and then find a bug report that sounds fairly simple
[21:19] <ddecator> As you gain experience, you will want to push yourself to work on different packages and more challenging reports
[21:19] <ddecator> Once you find a bug report you're comfortable working on, it's time to begin the triage process
[21:19] <ddecator> Alright, are there any questions so far?
[21:20] <ddecator> Great! Then let's move on
[21:21] <ddecator> There is no specific order for the following steps when working with a bug report, but I'll give you the one that has worked best for me
[21:21] <ddecator> The first thing you will want to do is read the report and any possible comments so you become familiar with what the report is for
[21:22] <ddecator> After you understand the report, you should ask yourself if this is really a bug report or a support question
[21:23] <ddecator> Most of the time, support questions are easy to identify. For example, the report might say "I can't figure out how to connect to my wireless internet. Can someone tell me how to do it?"
[21:24] <ddecator> This clearly is not reporting a bug, but instead is asking for support. If the report you are looking at is asking a question, you will want to convert the report into a question
[21:24] <ddecator> [SLIDE 9]
[21:24] <ddecator> Thankfully, Launchpad makes it very easy to do just that
[21:24] <ddecator> In the top-right corner, I have highlighted the "Convert to a question" link
[21:25] <ddecator> Clicking that will allow you to convert the bug report into a question in Launchpad Answers. It will also give you the chance to leave a comment explaining your action. There is a stock response for this, and if you have the Greasemonkey extension for Launchpad installed it should fill that in for you, but I'll cover that at the end
[21:26] <ddecator> If it was a question, then you're done with the report (unless you want to help answer the question)
[21:26] <ddecator> Assuming it was not a question, then you're ready to move on to the next step
[21:27] <ddecator> This can be two different things
[21:27] <ddecator> If you do not understand the report, then you will want to request more information from the user
[21:28] <ddecator> If you do understand the report, or after the user clarifies the problem, then you will want to look for duplicates
[21:28] <ddecator> When a bug affects a lot of people, it is almost inevitable that multiple people will report the same issue
[21:29] <ddecator> Some users do not look to see if something has been reported already, and others may think the problem is different, so duplicates are common
[21:30] <ddecator> Searching for duplicates is something that you will get better at over time
[21:30] <ddecator> One option for searching is using Launchpad itself
[21:30] <ddecator> You can limit the search to the package and search for specific words that might be in the title
[21:31] <ddecator> Or, you can use an outside search engine (which is my preferred method)
[21:32] <ddecator> Using a large search engine, such as Google, will look for your search terms in the entire report, including title, description, and comments
[21:32] <ddecator> This can make it easier to find a report that has a misleading title but describes the exact bug you're looking for
[21:33] <ddecator> [SLIDE 11]
[21:33] <ddecator> Sorry, looks like the screenshot on that slide did not scale well
[21:34] <ddecator> But, as you can see, the method for using an outside search engine to search bugs on Launchpad is to type "site:bugs.launchpad.net <search terms>" where you replace <search terms> with your actual search
[21:35] <ddecator> As an example, you can search "site:bugs.launchpad.net nautilus graphical issue"
[21:35] <ddecator> It's a good idea to try various search terms when looking for a duplicate
[21:36] <ddecator> If you do find a duplicate, then you want to mark one of the reports as a duplicate of the other
[21:36] <ddecator> You will want to look at the reports, decide which one has the most information, and make that the "master" report
[21:37] <ddecator> All duplicates of the bug should then be marked as a duplicate of that "master" report so there is one central report for users to and developers to reference
[21:38] <ddecator> [SLIDE 16]
[21:38] <ddecator> In the top-right, above the link to convert the report into a question, is a link to mark the report as a duplicate
[21:38] <ddecator> You will click this on the report that is the duplicate, not on the "master" report
[21:39] <ddecator> You will then enter the bug number (found right under the title of the bug), and then leave a comment explaining that you marked it as a duplicate because the problem has already been reported. There is also a stock response for this. By doing so, the reporter can go to the "master" report and add any extra information they might have
[21:40] <ddecator> After the report is marked as a duplicate, that report is taken care of
[21:40] <ddecator> So, what if the report you're working on is not a question and is not a duplicate?
[21:41] <ddecator> There are a few things you can do. First, if anything is unclear, ask the user to clarify and add information
[21:42] <ddecator> Once you fully understand how to reproduce the bug, you may want to try and reproduce it on your own system. Whether you do this or not depends on how severe the bug is. To be safe, it's a good idea to have a Virtual Machine and/or a Live CD that you can use for testing. Doing this is not required, but it gives you first-hand experience of the bug and it allows you to confirm the report
[21:43] <ddecator> We only confirm bugs that we can actually reproduce ourselves. We do not mark a bug confirmed just because multiple people claim to experience it. Afterall, it could be several users making the same user error, and we only want to confirm real bugs
[21:44] <ddecator> Once you have confirmed the bug yourself, or have enough information that you do not feel it is necessary to do so, you want to make sure the report has enough information for the developers to work on the issue
[21:44] <ddecator> How much information is needed depends on the report, the issue, and the package
[21:45] <ddecator> You want to make sure the report is as specific and detailed as possible
[21:46] <ddecator> If logs are needed, a more advanced triager who is more familiar with the package can request them. Thankfully, apport usually collects the necessary logs (if the user reported the bug using apport) so this makes things easier. Knowing what logs are needed just comes with experience
[21:48] <ddecator> A quick note: Apport is an application that collects information from a user's system automatically when they report a bug. They have to use apport for this to happen. If apport was used, detailed information about their system will be in the description of the bug and files will be attached. If these are missing, you can request that the user runs apport so it will add that information to the report. There is also a stock response for
[21:49] <ddecator> Alright, so the report has all of the information it needs (as far as you can tell)
[21:49] <ddecator> The next step is to decide how important the bug is
[21:49] <ddecator> Only BugControl members can assign importance, but it's helpful if triagers suggest an importance
[21:50] <ddecator> Details on importance can be found here: https://wiki.ubuntu.com/Bugs/Importance
[21:50] <ddecator> Finally, go to #ubuntu-bugs or email the BugSquad mailing list and request that the bug be marked Triaged with whatever importance you feel it deserves
[21:51] <ddecator> If the report is all set, someone will take care of it for you. If more information is needed, someone will either request it, or ask you to request it. If they ask you to request more information, it's to help you learn
[21:51] <ClassBot> There are 10 minutes remaining in the current session.
[21:51] <ddecator> There are NO stupid questions, so feel free to ask anything in #ubuntu-bugs, and if you tell you to do something it's only to help you learn
[21:52] <ddecator> OK, real quick, I want to point out a tool that will help you triage
[21:52] <ddecator> [SLIDE 32]
[21:52] <ddecator> On this slide is a link to a PPA that contains an extension for Firefox. This extension will add stock response options to reports for you and make things easier
[21:52] <ddecator> [SLIDE 34]
[21:53] <ddecator> This shows what is added
[21:53] <ddecator> Clicking the little drop-down arrow for a bug report will allow you to do multiple things at once, such as leave a comment, change the status, and subscribe to the report. Doing it all at once reduces the number of emails sent to others subscribed to the bug
[21:54] <ddecator> [SLIDE 29]
[21:54] <ddecator> There is also a link to a wiki page with stock responses there
[21:54] <ddecator> Note: Stock responses are great, but I -highly- recommend you read the response before you use it. That way, you will not thank the user for "reporting this bug and helping to make Ubuntu better" with each comment, and will not tell them to "please use apport next time" if they already did use apport
[21:55] <ddecator> Alright, I think that covers everything I wanted to discuss. Sorry I talked longer than I meant to
[21:55] <ddecator> I'm open to any questions :)
[21:56] <ClassBot> There are 5 minutes remaining in the current session.
[21:57] <ddecator> Once again, if you have any questions, feel free to ask in #ubuntu-bugs
[21:57] <ddecator> We also have a group mentoring team we're working on improving, so users can join that if they're interested
[21:58] <ddecator> Finally, you can email me directly if you have any questions for me: ddecator at ubuntu dot com
[21:58] <ddecator> Thanks for being willing to help out!
[22:00] <ddecator> Oh, and if you have any suggestions for improving the BugSquad wiki, please email me!
[22:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/04/05/%23ubuntu-classroom.html
[22:55] <rakshasa> Can anyone tell me how I should persist my xinput settings under Ubuntu10.10??