[Ubuntu-bugcontrol] Application from Jeremy Bicha (jbicha)

C de-Avillez hggdh2 at ubuntu.com
Mon May 17 18:57:07 BST 2010


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..

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20100517/5ce0b12a/attachment.pgp 


More information about the Ubuntu-bugsquad mailing list