On Tue, Oct 06, 2009 at 12:24:18PM -0500, C de-Avillez wrote: > On Tue, 2009-10-06 at 01:18 -0500, Marc Randolph wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > Howdy all, > > Howdy, and thank you for your interest in helping. > > > > > Here are my responses for the bug control membership application: > > <snip/> > > > > 2. Have you read Bugs/HowToTriage, Bugs/Assignment, Bugs/Status and > >> Bugs/Importance? Do you have any questions about that documentation? > > > > Yes, I have read those pages. I am never afraid to ask questions, and > > I error on the side of caution (and do nothing) rather than cause > > potential disruptions. > > I do have a question on one topic: Assigning importance is probably a > > triagers most important job since it sets expectations and indicates > > the understood priority to users, maintainers, and developers. > > But I find it sometimes difficult to assign an importance: > > A. Especially when the ticket it is incomplete, or > > B. When the bug contains enough information to be "confirmed", or > > maybe even "triaged" (if a patch is provided), but I am not familar > > enough with that particular project to understand how severe the > > problem is. > > > > In Case A, I'm not too worried, because if a bug is truely incomplete, > > then there is likely not information to accurately assign an > > importance. > > This is a sane approach, I agree. Some groups set a default Importance > of Medium to all new bugs, and adjust as needed as the bug progresses. > > > But in case B, is it suggested to leave the bug untouched (don't > > change the status or importance), or change just the status, or change > > the status AND make an educated guess on importance (on the assumption > > that if it is wrong, someone else will see it and change it)? > > This is a good point, and one difficult to give a definite answer ;-). > But, of course, I will try (I never leave aside a chance like this). > > First of all, you have to keep in mind the official definitions for > Importance -- https://wiki.ubuntu.com/Bugs/Importance. One important > point is we are free to *estimate* the potential impact. Of course, as > time goes by, our estimates will usually get better -- we learn more, > and more, about the specific package and Ubuntu/GNU/Linux. Hopefully. > But, since we are expected to estimate, it is also implied that we may > estimate *wrong*. Of course, if you get it wrong once in a while is > rather different than if you get it wrong most of the times. Bug-control > is expected to get it right most of the times. > > It may also happen that, as time (and work on the bug) goes by, we learn > more about the particular issue, and may decide the (currently set) > Importance does not reflect our (now updated) understanding -- and we > are free to reset the Importance to a new value. Any such changes -- in > fact, *all* changes -- in Status and Importance should be explained in a > comment. > > Now, the most importance difference between a common triager and a > Bug-control member the the ability to set the Importance (OK, and set > the Triaged status). Apart from that, a bug-controller is pretty much > identical to a non-bug-controller in capabilities. As such, we *do* > expect you will be able to set an Importance. This is why we ask > candidates to provide their best bet on what would be the bug's > importance. > > Adding it all up: as a member of Bug-control you *are* expected to give > your best bet on the Importance. If it ends up being wrong, someone will > indeed reset it, and explain why. > > > > > 3. What sensitive data should you look for in a private Apport > >> crash report bug before making it public? See Bugs/HowToTriage for > >> more information. > > > > First thing is to remove core dumps since they frequently contain > > sensitive user data. user-id's or account numbers, passwords, and > > other (even physical location data) can also show up and should be > > stripped out. > > Additionally, you should look at backtraces, stacktraces, etc. A 'bt > full', or 'thread apply all bt full', may contain private data. If you > find them, then you have two options: > 1. sanitise the backtraces, by manually taking out any private data. > This means downloading the traces, editing/redacting them, uploading the > redacted trace, and deleting the original one. > 2. Leave the bug private. > > I have been working on a sanitiser for backtraces for a while (well, I > *was* working on it, then I got busy earning a life, but I am returning > to it now). Hopefully, when I am done, we will be able to automate the > clean-up process. Meanwhile, it is a purely manual process. > > > > #4 Is there a particular package or group of packages that you > >> are interested in helping out with? > > > > I'm actually here at the suggestion of superm1 (Mario Limonciello), > > the maintainer of many mythtv related packages. My first and main > > focus will be on the myth related projects under his supervision. As > > time allows, I will be happy to help out on other projects where I can > > understand enough to actually be helpful (ref: case 2.B above). > > Good enough, and I am sure Mario will be more than happy with your help. > > > > #5 Please list of five or more bugs which you have triaged. These bugs > > > should demonstrate your understanding of the triage process and how to > > > properly handle bugs. If there is a bug in your list that does not > > > have an importance indicate what importance you would give it after > > > becoming a member of Ubuntu Bug Control. Please use urls in your list > > > of bugs > > > > > > https://bugs.launchpad.net/bugs/436792 - High. If you can read around > > the lengthy parallel (and off-topic) discussion regarding obtaining > > the current version, I feel this was high because it doesn't work > > after install, but can be worked around if the user is knowledgable > > enough. > > Good triage work -- and I particularly liked the fact you accepted you > were wrong at one point. I also agree with the High importance. > > > > > https://bugs.launchpad.net/bugs/440342: Low because it is cosmetic. > > Was originally thought to be an upstream bug, so I forwarded the bug > > on, but it turns out it was was a Mythbuntu theme issue. I marked it > > as triaged since the upstream provided the answer and also assigned it > > to the theme developer since he is actively working the issue > > (confirmed via IRC). > > Agreed. One single point: it is usually not a good idea to assign bugs > to other people. Of course, this is a moot point *here*, since you had > already checked with the assignee. You preempted my observation above > nicely ;-) > > > https://bugs.launchpad.net/bugs/440807: Critical - project was broken > > not only on nightly PPA, but also in Karmic on packages.ubuntu.com, > > where it is more accessable by inexperienced users, so therefore be > > resolved quickly. > > No comments. Acceptable setting of Importance. > > > https://bugs.launchpad.net/bugs/429089: Medium - there appears to be > > work-arounds for this non-major feature if the user is knowledgable > > enough. I developed and submitted a patch upstream, which I am in the > > process of re-working. > > This is one case where you could assign the bug to yourself, since you > are actively working on the resolution. > > It might be a good idea to provide the shell wrapper script as a bypass. > It would also be good to rephrase the description as noted in > https://wiki.ubuntu.com/Bugs/Description. > > Good work. > > > https://bugs.launchpad.net/bugs/397194: Medium - easy work-around for > > a very commonly used feature > > Not much to comment here ;-) > > > I welcome any critism of other bugs I've touched (it's impossible to > > make me upset, so fire away!). > > Well, there is not much to be critical of, here. Generically, good work. > > The only thing I am not sure of -- and I will defer to the bugmeisters > -- is why you need bug-control for Mythbuntu. > > But your work more than warrants membership to Bug-control. > > +1.
Your work looks great to me also and I'm happy to approve your membership in the Ubuntu Bug Control team. Thanks for helping out and welcome! Sincerely, -- Brian Murray @ubuntu.com
signature.asc
Description: Digital signature
_______________________________________________ Mailing list: https://launchpad.net/~ubuntu-bugcontrol Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol More help : https://help.launchpad.net/ListHelp
