Re: [RFC] Change default bugzilla status to unconfirmed for all newly added bugs
On Sun, Sep 2, 2012 at 11:07 PM, David Edmundson da...@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
Re: [RFC] Change default bugzilla status to unconfirmed for all newly added bugs
On Mon, Sep 3, 2012 at 7:50 AM, Martin Klapetek martin.klape...@gmail.com wrote: On Sun, Sep 2, 2012 at 11:07 PM, David Edmundson da...@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). Interesting, just made a test account and opened some fake bugs on my product: normal user + format guided = unconfirmed normal user - format guided = new kde dev + format guided = new kde dev -format guided = 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. I second this. -- Martin Klapetek | KDE Developer
Re: [RFC] Change default bugzilla status to unconfirmed for all newly added bugs
Am 02.09.2012, 23:07 Uhr, schrieb David Edmundson da...@davidedmundson.co.uk: I am proposing changing the default state of all newly added bugs to UNCONFIRMED regardless of who the reporter is. No idea how you do it, but if you do it, that would certainly be much appreciated from my side. tl;dr: +1 Cheers, Thomas
[RFC] Change default bugzilla status to unconfirmed for all newly added bugs
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. Regards David Edmundson on behalf of Martin Gräßlin, Janek Bevendorff , Myriam Schweingruber et al.
