[RFC] Change default bugzilla status to "unconfirmed" for all newly added bugs

David Edmundson david at davidedmundson.co.uk
Sun Sep 2 22:07:44 BST 2012

I would like to propose a minor change to our bugzilla workflow that
has been recently discussed on the KDE Quality Mailing List, but has
come up several times before. (originally discussed in 2009
https://bugs.kde.org/show_bug.cgi?id=183217 )

Currently when a new bug is filed by a non-developer is enters our
bugtracking system in the state UNCONFIRMED. This allows the
maintainer of that piece of software to triage the bug, check the
reports has all the necessary information and agree with the reporter
before it assigned to NEW.

However, when a KDE developer files a bug this step is skipped and the
bug is automatically marked as NEW. Whilst this may work for small
teams, KDE is too big a team for this to work.  Only the core
developers of that area of software have the knowledge to set the bug
status to NEW. I can, for example, file a bug in KWin but only someone
working in KWin has the full knowledge to confirm the bug.

As a developer this is very important as I have to duplicate my
triaging work, with the new system I can guarantee that everything
marked as UNCONFIRMED needs looking at by myself or one of my team,
with new bugs being already 'confirmed' I have to look at an entire
list that I have already looked at everytime. Also bugzilla should act
as a TODO list, everything marked as "NEW" should be something my team
has agreed upon, especially for behavioural changes. In the current
state I have junior developers regularly asking me "what should I be
working on next?", and I have to check before I can simply redirect
them to bugzilla.

I am proposing changing the default state of all newly added bugs to
"UNCONFIRMED" regardless of who the reporter is.

It's worth noting that when opening a bug and selecting "show advanced
fields" a new bug can be filed under a different status, it's simply
changing the default.

Obviously there are hundreds of bugs that have already been opened as
NEW which under the proposed change would not have been, these should
be left as-is.

I intend to make this anouncement on this mailing list, and assuming
there is general consentment, push for this change to happen. As far
as I can tell from Google searching this is a fairly small technical
change, but needs pushing to happen.


David Edmundson

on behalf of Martin Gräßlin, Janek Bevendorff , Myriam Schweingruber et al.

More information about the kde-core-devel mailing list