On Thu, 2010-12-30 at 10:27 +0100, njin wrote: > -Do you promise to be polite to bug reporters even if they are rude to > you or Ubuntu? ****yes > -Have you signed the Ubuntu Code of Conduct? yes > -Have you read Bugs/HowToTriage, Bugs/Assignment, Bugs/Status and > Bugs/Importance? ****yes
Hi, Let me start by saying, thanks for helping with bug triage. You have been doing a lot of work! :) > -Do you have any questions about that documentation? ****no > -What sensitive data should you look for in a private Apport crash > report bug before making it public? ****every kind of private data > (passwords, keys,or everythings can be a privacy violation if public). > coredump.gz never has to be attached to a public report. > -Is there a particular package or group of packages that you are > interested in helping out with? ****Ubiquity, Debian-installer. > https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/684083 This bug was reported by you and it was triaged by Colin instead. > reproduced looking at top ghostscript at 100% of cpu > https://bugs.launchpad.net/ubuntu/+source/at-spi/+bug/642888 > You did identify the package, but the bug here was triaged by Charlie (comment#1). > Remembering the debugging of gpm i've decided to switch off plymouth at > boot, hight set by chris as makes ubuntu unusable for nvidia cards > https://bugs.launchpad.net/launchpad/+bug/692291 I think you might have quoted the Wrong bug # here? This is not an Ubuntu package bug, this is a bug in launchpad itself. > But why on this pc don't work and on the other works, ah it's not > maximized....i'm the only reporter, importance set by another > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/390959 You could have just asked the reporter to run the following command: $ apport-collect 390959 That would have collected all the info that was required , rather than the reporter having to attach one file at a time. It would have been a lot more easier for the reporter. This looks like one of your earlier bugs, but We need to remember the tools available to us. > just following how to triage > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/480903 In this bug you did mention apport :) But, when requesting information you changed the status from: incomplete -> confirmed , rather you should have left the status as incomplete until the apport info was collected. Luckily the reported did add info using apport. But what if the bug reporter had not? The bug would have been marked confirmed without any info. > missed driver in the kernel. reporter sayd that installing drivers from > producer site make it working. > https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/674663 The tagging for this bug is weird and introduces custom tags. The correct tag to be used here is `needs-upstream-testing` and once done it just needs to be removed. no need for any new tag. Are you sure about the tag 'regression-update' here? There is no indication that an update from the maverick-updates caused the bug. It seems more like a `regression-release` since the bug was also later re-titled. What would have helped was, if the reporter was asked if the problem did not exist when he installed Ubuntu 10.10 fresh. And started happening only after a particular update. It would narrow-down the cause of the bug here. for more info on tags: <https://wiki.ubuntu.com/Bugs/Tags#Kernel%20Specific> <https://wiki.ubuntu.com/Bugs/Tags#Regression%20specific> <https://wiki.ubuntu.com/Kernel/Tagging> > as john lennon sing "with a little help from my friends" > https://bugs.launchpad.net/ubuntu/+source/cups/+bug/668800 This one seems fine. Would have preferred info from the original reporter though, but a triager adding the info is also good. IMO, The list here would only be 4 bugs that you had triaged for others. However, I'v noticed that you have been doing a lot of triaging, but the bugs you selected are not a great list. If i had not noticed the work you've been doing , based on the bugs listed here I would have -1'd your application. But, I'm pretty sure you would have a better list of bugs that *you* have triaged for others. So +0 for now. > i don't remember > And many others > Have a look at: <https://bugs.launchpad.net/~fabiomarconi/+commentedbugs> <https://bugs.launchpad.net/~fabiomarconi/+subscribedbugs> Try to choose bugs where you have made less mistakes, preferable none. :) Have a look at the BugControl criteria: <https://wiki.ubuntu.com/UbuntuBugControl#Evaluation%20Criteria%20and% 20Process> And a few example applications: <https://wiki.ubuntu.com/UbuntuBugControl#Example%20Application> Everyone makes mistakes when starting with bug triage, but when submitting an application for Bug Control it is better that you list the bugs where you have done your *best* work. If you are not able to find any bugs without mistakes, I'd suggest you focus on the packages you are interested in(Ubiquity, Debian-installer) and get back with a good bug list. Looking forward for a better list of bugs.. :) Also do mention the bug importance that you think is appropriate, BugControl are the folks who set these, so it's kinda important that you mention along with the bug list too . (Yes, the wiki is ambiguous, looks like the wiki needs to be updated and more clear about this. Every 'triaged' bug,which is what we request for bugcontrol application, would have an importance set, so adding the clause of "does not have an importance" is a moot point. Have a look at the application examples.) -- Cheers, Vish _______________________________________________ Mailing list: https://launchpad.net/~ubuntu-bugcontrol Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol More help : https://help.launchpad.net/ListHelp
