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

Martin Klapetek martin.klapetek at gmail.com
Mon Sep 3 07:50:24 BST 2012

On Sun, Sep 2, 2012 at 11:07 PM, David Edmundson <david at davidedmundson.co.uk
> wrote:

> However, when a KDE developer files a bug this step is skipped and the
> bug is automatically marked as NEW.

I may be wrong (and please correct me if so), but the bugs are marked as
NEW if you file it with the "&format=guided" removed from URL, so not only
KDE developers, but everyone doing that will file the bug as NEW (users are
just not aware of that; also I don't think there's a differentiation
between KDE developer and an ordinary user on bugzilla level, except the
elevated bug editing rights).

> 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.

I second this.

Martin Klapetek | KDE Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120903/a99bc070/attachment.htm>

More information about the kde-core-devel mailing list