[Ubuntu-bugcontrol] Application for the bugcontrol team

[C de-Avillez]

Hi njin,

On 12/31/2010 06:39 AM, njin wrote:
> 
> Please remember that i can only assign packages, set status (incomplete,
> confirmed, invalid) and in the case send upstream.
>>> -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

> the only things that i can do is assign package, and as i'm the only reporter i cannot confirm.

There is a difference between *reporting* a bug and *triaging* it: a
reported bug _needs_ triaging. You reported this bug, and followed
directions from Collin. Ergo, you did not triage it, Collin did.

Indeed one should never confirm his own bugs. But, even if it was to
be accepted, you would still have not triaged it.

This difference is crucial in our work.

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

> I cannot triage bugs

You cannot _set_ the bug status to Triaged. You *can* triage bugs,
and then request we set the status.

<snip/>

>> 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.
> Ok for the tags, i'm learning, but this is a regression-update, because reporter said 'after first update', and
> Stenten has modified the title, and looking the procversionsignature the
> installed kernel is 2.6.35-22.35, but the release ship the 2.6.35-22.33

Good enough, and I agree. You *did* check the reporter's statement.

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

If the triager can reproduce the issue, the triager's data is
usually good enough (of course, this is not true when dealing
directly with hardware).

<snip/>

>> But, I'm pretty sure you would have a better list of bugs that *you*
>> have triaged for others. 
>> So +0 for now.

> i'll look at it this evening

<snip/>

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

> Everytime i do my best, there's no one bug different from the other,
> also expalining how to set the system is a usability bug.
> I don't like to play with the works of other persons.

Vish's comments still apply: the requirements for membership on Bug
Control are more stringent. When you send your application, you are
trying to show the Bug Control members the quality of your work. Of
course, even us in Bug Control make mistakes... the most important
difference, however, is that we are required to make *less* mistakes
;-).

Additionally, your application *must* have your take on Importance
for *each* bug you show, together with your reasoning for such. It
does not matter if the bug already has Importance set, we still want
to know what _you_ would set Importance to, and *why* (you may
disagree with the bug's importance, BTW).

0 for now. Please do resubmit a list of 5 bugs -- your best triage
work, as we are asking.

Cheers,

..C..

-------------- 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/20110107/c47a57ba/attachment.pgp>