Hi I have followed this list (ubuntu-bugscontrol) for about 3 months. This is my first insight into what is actually happening in this sub-culture. I have been working with IT/IS related questions for close to 15 years and have tried Linux for the last two. I thought that I was ready to start helping but after having read this I realize my skills are far below what is expected of the community. I have read the triage guide. I have a launchpad ID. I have subscribed to the list .I have read, understood and signed the Ubuntu CoC. Unfortunately, I do not see how I can help and if anyone would appreciate it.
BRGDS //stefanivarsson On Mon, May 17, 2010 at 7:57 PM, C de-Avillez <[email protected]> wrote: > On Thu, 2010-05-06 at 20:44 +0300, Jeremy Bicha wrote: > > Hello Jeremy, and thank you for your interest in helping. We *do* > appreciate it. > > > 1. Do you promise to be polite to bug reporters even if they are rude > > to you or Ubuntu? Have you signed the Ubuntu Code of Conduct? > > > Yes, I promise to be polite to bug reporters even if they are > not-polite to me or my friends. I signed the Code of Conduct 4 years ago so > it's about time I get more involved! > > 2. Have you read Bugs/HowToTriage, Bugs/Assignment, Bugs/Status and > > Bugs/Importance? Do you have any questions about that documentation? > > > Yes, I've read through the wiki. No questions at this time but I know > where to ask questions if needed. > > 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. > > > Passwords & private keys, personally identifiable information (name and > username are ok, I'd look for things like address, credit card info), > CoreDump.gz > > 4. Is there a particular package or group of packages that you are > > interested in helping out with? > > > 6 months ago, I took a special interest in Edubuntu, and have > subscribed to their bugs. I help out occasionally with a wide variety of > bugs that interest or affect me. > > 5. Please list 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 (and explain the > > reasoning) you would give it after becoming a member of Ubuntu Bug > > Control. Please use urls in your list of bugs. > > > I presume I can list bugs that I've reported too. > > You can list bugs you have reported, as long as they indicate a triaging > flow *you* performed. Usually this is not the case, though. So, in > general, one should not use one's own bugs as the examples we seek. On > the example bugs you provided us, I can see you seem to know the > process... but not all bugs show *you* triaging. Even more, you do not > suggest an Importance on most of them. > > I will use this reply to try and clarify the process a bit more. > > *WHAT WE ARE LOOKING FOR* > > First of all, given a problem, we must identify the root cause(s) from > the description and supporting documentation (and keep in mind that > correlation is not causation). For example, "I cannot run Ubuntu" states > a *consequence* -- we must now go and try to find out what *causes* this > failure. Triaging deals with this process. After root causes are > identified, one can then go and develop a fix (or invalidate the > problem, as needed)-- but this is problem _resolution_, not problem > triaging! > > We are trying to verify your knowledge of triaging (and, specifically, > your knowledge of the Ubuntu processes for bug triaging). This involves > a series of things: > > * how you interact with the original poster (OP): being courteous is as > important as being knowledgeable. Even more, courtesy is not an inbred > trait, but must be exercised continuously. > * explaining why some action is needed and how to get it done. We should > never assume (unless we know the OP) that the OP understands Ubuntu, > Linux, etc. > * explaining the reason of a status change. We should not blindly change > the status (or importance) of a bug. Always add a sentence, or comment, > on the reason. > * your problem identification process. How -- and why! -- you identified > the basic issue, your backtracks ("I am sorry, but indeed my previous > explanation/view/analysis in comment xx was wrong because of whadda > gimpa blahblah"), etc. > * keep in mind that others will (eventually) read the bug and its > comments, trying to figure out what to do. Please make their life > easier. Explain. Comment. Point out examples. > > By giving us 5 bugs you triaged, you provide us with a chance to glimpse > your work on this area. We are not required to search for your > contributions, although we *can* do so. > > *HAH! SO YOU _CAN_ SEARCH. WHY DON'T YOU, AND FREE ME FROM DOING IT?* > > Well. If you cannot be bothered with finding five bugs to show your > work, why should *we* be bothered to search for it? Yes, we understand > you are most probably busy, perhaps within the Ubuntu community, perhaps > without. But, most of the times, so are we. You spend some time > selecting your five examples of bug triaging, and we spend some time > reviewing them. You can *choose* which ones to show off, and we will > accept them. > > *WHY DO I NEED TO PROVIDE MY VIEW OF IMPORTANCE?* > > The most important difference between a triager-at-large and a > bug-controller is the ability to set the bug's importance. Yes, there > are other differences, but I personally do not consider them as > critical. > > As such, it stands to reason that we want to know your view on what > would be the importance. You may even disagree with the one set in the > bug, this is acceptable. But you *must* give us your view on the > importance, and you *must* explain why. > > *SO YOU ARE ACTUALLY AN ELITIST* > > No, we are not. Er, yes, perhaps we are. Both apply. As a bug-controller > you will have more access and control over what bugs are looked at, and > worked on. This has been discussed many times, and is still being > discussed. What we are doing here is our consensus, as of now. Again, it > stands to reason that we should be a bit more selective. And, after all, > we are not requiring too much: > > * sign the Ubuntu Code of Conduct -- this is basic. Being nice *is* a > requirement, and I personally fully support it. This is one of the major > differences between Ubuntu and other projects -- we strive to be nice to > others. > * understand the triaging flow for Ubuntu -- note that this is for > *Ubuntu*. Eventually, one will also work with upstreams, and knowing > *their* bug flow will then apply. > * privacy considerations -- every so often a bug will have private (or > potentially private) data. One should be careful, and respect the OP's > privacy. > * five bugs showing one's understanding of the three bullets above. > > I posit this is not unreasonable. > > > > https://bugs.launchpad.net/ubuntu/+source/marble/+bug/574450 User > > looking for marble wallpaper > > Correct answer, but too terse. Lacks being nice, and an explanation of > how to install the wallpaper. Also lacks an explanation of why it was > set to Invalid. > > > > https://bugs.launchpad.net/ubuntu/+source/gramps/+bug/549045 Feature > > freeze exception request > > Good work, and good catch. But I do not see your triaging knowledge > being used. > > > > > https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/527503 > > Icons not showing in KDE/XFCE > > I cannot see triaging work done by you here. You found a bug, and > reported it, that's all. > > > > > https://bugs.launchpad.net/ubuntu/+source/kdegames/+bug/527516 > > Missing .desktop icons, I would mark this as Low since it is a > > cosmetic/usability issue > > This, again, is a bug you reported (and was triaged by somebody else). I > cannot really see your triaging skill in use here. Agree on Importance. > > > > > https://bugs.launchpad.net/ubuntu/+source/moodle/+bug/452622 Incorrect > > config, wrote patch > > Again a bug you opened. A question I have is *why* a second patch was > necessary -- why is maintaining localhost important? Yes, I know why, > but not everybody does. This bug shows your skill on identifying an > issue, and fixing it. But I cannot see your skills on triaging. > > > > > > https://bugs.launchpad.net/ubuntu/+source/launchpad-integration/+bug/477685 > > Action should have ellipsis, submitted bzr branch > > Another good example of finding and fixing an issue, but not of > triaging. On the other hand, this is a good example of *why* commenting > on one's action is important -- Seb disregarded your branch because > there was no comment about it. > > > > > https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/516600 > > Report a Problem didn't work in newly uploaded version > > Another nice example of bug reporting. But, again, I cannot see your > triaging skills at work. > > +0.5 > > I personally think you do qualify, but I cannot see supporting bugs for > it. > > Cheers, > > ..C.. > > -- > Ubuntu-bugsquad mailing list > [email protected] > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > >
_______________________________________________ Mailing list: https://launchpad.net/~ubuntu-bugcontrol Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol More help : https://help.launchpad.net/ListHelp
