ubuntu-bugcontrol team mailing list archive

[Stefan Ivarsson <stefanivarsson@xxxxxx>]

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 <hggdh2@xxxxxxxxxx> 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
> Ubuntu-bugsquad@xxxxxxxxxxxxxxxx
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
>
>