What we look for on Ubuntu-BugControl

[C de-Avillez]

I originally wrote the following text last year [1], piggybacking on
a response to a BugControl application. Perhaps it would be better
that this is sent completely separate, so that it will be as generic
as possible (and not seen as a critique to a specific application).

[1] https://lists.launchpad.net/ubuntu-bugcontrol/msg02249.html

-x-x-x-x-x-x-x-

*WHAT WE ARE LOOKING FOR on Ubuntu BugControl*

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20110420/fa5df7f5/attachment.pgp>