Bugreporting barrier is too low with the new Dr. Konqi

[Seb Ruiz]

2009/11/3 Mark Kretschmann <kretschmann at kde.org>:
> Nokia is now using the JIRA [1] bug tracking system for Qt. I'm
> personally very interested in that, as I know first hand that
> Atlassian makes excellent software. However, JIRA is only
> free-as-in-beer, and I can see how that would make certain people go
> mental.

Hi folks,
I've been following this thread and meaning to write earlier, it's
just that life has been getting in the way.

First up, a disclaimer: I work for Atlassian, the company behind JIRA.
That said, I do not work on the JIRA team. I don't want this to be a
marketing or sales pitch, but fear that I'll do a bad job of doing
that, so please give me benefit of the doubt. This email might get off
track, but it's a good opportunity to talk about the state of KDE's
bugzilla nonetheless.

I'm not here to tell you that KDE should move to JIRA, but I would
like to detail how we use JIRA to try and make the lives of developers
and managers easier and make them more effective and doing the things
that they need and want to do. I hope that we can find a solution that
brings KDE developers more efficiency and creates less head banging
than our current Bugzilla instance brings.

Primarily, an overview. Each product has it's own project in JIRA.
These projects are managed and administered by individual teams, and
in most cases are entirely distinctly and independently from each
other. There are global settings, but each team can create their own
customisations to suit their own team processes.

There are a few features in JIRA (or rather, the implementations of)
which I consider to be really critical to the way that we use the
software. The first is the notion of versions and milestones (which I
consider to be second class citizens in bugzilla). We have a very
agile method of software development, which KDE development parallels
in many ways. Every project has a list of previous and upcoming
releases, as well as issues which have been reported against and
scheduled for fixes in a (or none) milestone. This is useful not only
for prioritising work, but also for generating changelogs. As you
might see, a good bug tracker is not only for tracking issues, but
also just as important (if not more so) for product management and
planning. I shudder to think of the days I used a `todo` file in
amarok/ for things that needed to be done. Currently, we really don't
have much better. A wiki, some reminders from the people on top of
things during irc conversations.

Another critical feature customisable workflows. This is where
developers really can get the head up in terms of noise created by
third parties. A typical workflow might go like this:
     Needs Triage --> Open --> In Review --> Closed
(the closed state can be any meta of states, such as dupe, cant
reproduce etc). Workflows are like a state machine for issues. Define
them how you like.

You might decide that any new issue that comes from Dr Konqui goes
through a custom workflow, or that issues created by developers or
people you trust go directly to the Open state.

Really powerful filters help me find the issues that I want, and not
the junk. I hope that KDE can find an issue tracking solution that
actually helps me as a developer do the jobs that i want to do - to
find those bugs that I want to work on or the blockers for a
particular release. I think this is even more important when we have
many contributors looking for JJs or finding dupes.

At the end of the day, whilst bugzilla may indeed have served us for a
long time and with a good heart, I think it's falling short of the
expectations that developers have nowadays when dealing with issue
trackers. At least, it certainly falls short of my expectations.

Best regards,
Seb

ps - I know that JIRA being closed source will be a deal breaker for
some of you, and frankly, that's alright. It is however free as in
beer for foss projects, as we encourage and contribute to many open
source developments.

-- 
Seb Ruiz

http://www.sebruiz.net/
http://amarok.kde.org/