Bugtracker Needs

A Bugtracker is a very important tool in software development and can be used to both increase the software quality as well as coordinate feature development. Unfortunately the KDE Bugtracker installation (BKO) is failing in these requirements for Plasma (both the desktop shells and the compositor). The biggest problem at the moment is that BKO gets literally spammed by reports. Over the last half year against the product plasma 1685 reports were reported and against kwin 489 and have an open record of 1293 and 376 respectively. Together both products are number two of overall bko only outnumbered by konqueror.

In the current state BKO is of no use to the Plasma developers and changes are needed to improve the workflow for bug handling.

Reasons for the current state

High number of Duplicates

Users report bugs again and again, with an increase number of bug reports it gets more and more difficult to find the duplicates. DrKonqui lets users allow to report bugs even if there are high number of duplicates.

No Bug Triaging

There is no Bug Triaging team. Plasma reports are triaged by one person, KWin bugs by two persons. This is way too less for an efficient system.

No Developer is responsible for Bugs

Various components don't have a maintainer responsible for the bugs. Both Plasma and KWin have only a small number of developers responsible for all bugs.

Old Bugs don't get closed

There are many old bugs just bitrotten without any information whether the bug is still valid. This is especially a problem for crash reports when the code changed since the bug was reported.

No Quality Control of Bug Reports

Everyone is allowed to open bug reports and to comment on them. There is no way to ensure that a bug report has the required quality.

Bugzilla Issues

The current Bugzilla installation is rather slow and difficult to work with. An example are duplicates. In order to set a bug to duplicate you need to open it in the browser, scroll completely down, copy the number from the provided possible duplicates, click on mark as duplicate, paste number, click on submit and wait.

Ways to Improve the Situation

Better Components

The component situation for Plasma is not optimal.KWin did a reorder recently.

Maintainers

Each component should have a dedicated maintainer (or group) which is responsible for all bugs. This implies that the maintainers receive emails whenever a new bug is reported. As maintainer for a small component it is easier to have an overview and mark bugs as duplicate and in best case just fix them. A maintainer does not have to be a developer, also an interested user could maintain a bug component.

Introducing a QA team

Plasma should have a dedicated QA team which is running the integration branch. The team should consist of both developers and reliable and interested users which are known to report good bug reports. This team should be able to find all important bugs. It would be important to have a heterogeneous group, so that only "rare" use cases are tested.

Restricted Access

Not everyone should be allowed to report bugs against Plasma and have access to all comments. The core developer team should be able to discuss in an open way for them (this includes stating that a bug report is bullshit without the fear of insulting the user).

Only Core Team may Alter Bug Reports

Only the core team should be allowed to set things like the severity of bug reports. Not even other KDE developers can decide whether a bug is severe or not. Also, the "bug report reopening" war should not be allowed.

Karma system allows/restricts access

People's bug reports and or comments could be rated by X (be it maintainers, certain category of developers/users ...).

Those that are rated very good might get more responsibilities, while at the same time those that are rated bad could be blocked for certain products or even the whole bko for a certain amount of time or "forever".

In fact such a system should be easy for those who judge the report and it should be clear for the people judged why they were judged some way.

Automatic close of Bug Reports

Bug reports without any comments for a certain amount of time should be discarded. E.g. discard all bug reports for versions of 4.x | x <= current version - 2. Also bug reports with questions to the users should be automatically closed after e.g. two weeks of waiting.

Additionally the closing message could contain further information. E.g. "is this problem present in a recent version" and also a hint that for old versions rather the distribution should be contacted. A link to a userbase? page could further describe the reasons as to why the bug was closed automatically.

No more Voting

The voting feature is in general broken.

Catch user pain

Instead of voting "user pain" could be recorded. See: http://www.lostgarden.com/2008/05/improving-bug-triage-with-user-pain.html and http://thebuggenie.wordpress.com/2010/03/19/triaging-issues-user-pain-custom-fields-and-more/

No more Feature Requests

The complete idea of developers waiting for users to state their ideas and that they get implemented is broken. It should be removed and completely be replaced by brainstorm.

Migrate Bug Reports from forum.kde.org

Supporters on forum.kde.org should forward real issues raised on the forum. This would give users still the possibility to report bugs even if we disallow them to report bugs and we would have the issues pre-filtered and validated.

Restart

Close all bugs in order to get a fresh restart.

Better frontends

As mentioned above bko tends to be quite slow. GUI frontends like Deskzilla can work around that. This tool in specific keeps local copies of the queries, thus it is quite fast to work with. Further it allows you to change bugs locally and send them all once you are done (does not stop you from working). The disadvantage of the later program is that only the lite version is free.

Start reports as UNCONFIRMED

Unless the reporter is a developer of the certain program each report should be UNCONFIRMED first.