I've got a little bit of free time, so here's the first in what will
hopefully become a series of hints and tips about getting involved in
KDE without having to learn C++.
Today's topic is bug triage. Around 80 new bugs and wishlist items are
filed in KDE's bug tracking system
every day, and, while application and library maintainers try to look
at all of the ones reported for their application, their job is a lot
easier if someone else has already gone through and removed the
duplicates, asked the reporter for any additional information that's
useful, and noted which bugs can be reproduced.
The really nice thing about bug triage is that it comes in very small,
bite-sized chunks: each bug report probably takes a few minutes to
look through, so you can spend ten minutes a day on bug triage (on
your coffee break!), and be able to do something useful - something
that isn't so practical with some other ways of helping KDE.
The main reference for bug triaging, which I'd thoroughly recommend,
is the quality.kde.org
bugs howto. That'll give you some pointers for getting started,
and tell you a little about how the bug tracking system works, what
the different bug statuses mean, and so on.
So, once you've got an account on bugs.kde.org and read the
quality.kde.org howto, what do you do next? The first thing to do is
decide which bugs to concentrate on: do you want to look just the bugs
for one or two applications, or take an overview of al bugs that are
reported? If you're a long term KDE user, and are a little bit
familiar with the internals, then taking an overview might be for you:
you'll be able to see when bugs are filed against the wrong KDE
component, and suggest what other parts of KDE could be relevant to
the bug. If you're not familiar with the internals of KDE, you can
still do bug triage! Just pick an application you use a lot, or
particularly like, and concentrate on the bugs that are reported for
that application.
Let's say you decide to concentrate on bugs in one particular app. You
can use the query page to
display all the open bugs for that application, or just the bugs that
have been opened in the last few days. Take a look at each bug, with
the aim of determining whether or not the behaviour that the reporter
described is really a bug, and if so, making it easier for the
developer to fix it. Put yourself in the shoes of the developer - what extra information will they need to be able to
start fixing the bug?
Some things to do:
- First, try to reproduce the behaviour that the reporter has
described. Add a comment to say whether you could reproduce the bug,
noting your KDE version and distribution. If you don't understand the
description, ask for clarification - if you can't understand what the
reporter means, the developer probably won't be able to either. - If you can reproduce the behaviour, think of ways to narrow down
the cause: Imagine that an app crashes when you save a document. What
about selecting Save from the File menu? What about pressing Ctrl+S?
Does it happen for any document, or just certain documents (perhaps
certain file formats)? What about local vs remote files? This is where
you get to use your imagination a little bit, since every bug report is
different. - Try to find out whether the bug is related to a problem with
config files: trying to reproduce the bug with a newly created user
(and asking the reporter to do the same) is a good way to test
this.
Those are some common, simple things that I can think of. As you get
more experienced, you'll find other tips n' tricks that are useful,
especially if you choose to concentrate on just one application.
So, in 20-second summary:
Bug triage
Why's it useful? It makes bug hunting and fixing easier for
developers, so more bugs get fixed.
Why choose bug triage instead of ...? It doesn't take much time
to look over a bug, so it comes in nice small chunks
What skills do I need to do it? Not much, just a bit of
patience and sometimes some perseverance.
posted by Philip Rodrigues @ 5:40 PM
2 comments
