Re: Bug importances - Suggestion for improvement
El 08/04/14 22:35, C de-Avillez escribió: Sorry, I do not understand what you said above. Can you please rephrase? Yes: Although bug management does not apply to workflow bugs, they still have to be worked first by developers. So setting these as critical is a visual aid for them. El 09/04/14 00:52, Thomas Ward escribió: In the How to Triage guide [1], even, there's a section labeled Special Types of Bugs [2], which says that unless you know what you're doing, you shouldn't touch those bugs. Status included. Because this is prone to mistake, perhaps we can warn in the Bug Statuses page itself that these bugs are not covered in that policy. El 09/04/14 00:52, Thomas Ward escribió: That's my opinion on this. Let's move on to actually fixing bugs, not dealing with how we set the importance on special bugs, of which our bug triage rules don't really apply in the same way (if at all, case in point merge requests, sync requests, security bugs (which have slightly different policies), etc.). There's another relevant part of setting importances for all bugs, which is bugs that really need its importance to be set can be catalogued in work-flows made of list; without having items in these that cannot be cleaned up. For example, in the following work-flows: - https://wiki.ubuntu.com/One%20Hundred%20Papercuts/Work-flow - https://wiki.ubuntu.com/UbuntuBugControl/Final%20clean-up - https://wiki.ubuntu.com/Bugs/Ubuntu%20Bug%20Weekend Summarizing: While changing status for this bugs can disrupt development work-flow, setting their importance to a default value can be a visual aid for everyone. -- Ubuntu-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
Re: Bug importances - Suggestion for improvement
On Wed, Apr 9, 2014 at 2:52 AM, Alberto Salvia Novella es204904...@gmail.com wrote: El 08/04/14 22:35, C de-Avillez escribió: Sorry, I do not understand what you said above. Can you please rephrase? Yes: Although bug management does not apply to workflow bugs, they still have to be worked first by developers. So setting these as critical is a visual aid for them. Why? This is not a bug, it is a workflow. If this is not a workflow you are *involved* with (as, for example, 100 papercuts) you *cannot* change anything in the workflow bug without clearing it out with the people that actually work them. It does not matter if my personal perception is this is a critical (workflow) bug for *me*: it is NOT a workflow under your responsibility. El 09/04/14 00:52, Thomas Ward escribió: In the How to Triage guide [1], even, there's a section labeled Special Types of Bugs [2], which says that unless you know what you're doing, you shouldn't touch those bugs. Status included. Because this is prone to mistake, perhaps we can warn in the Bug Statuses page itself that these bugs are not covered in that policy. Agreed. El 09/04/14 00:52, Thomas Ward escribió: That's my opinion on this. Let's move on to actually fixing bugs, not dealing with how we set the importance on special bugs, of which our bug triage rules don't really apply in the same way (if at all, case in point merge requests, sync requests, security bugs (which have slightly different policies), etc.). There's another relevant part of setting importances for all bugs You again are mixing real bugs and workflow bugs. , which is bugs that really need its importance to be set can be catalogued in work-flows made of list; without having items in these that cannot be cleaned up. For example, in the following work-flows: - https://wiki.ubuntu.com/One%20Hundred%20Papercuts/Work-flow - https://wiki.ubuntu.com/UbuntuBugControl/Final%20clean-up - https://wiki.ubuntu.com/Bugs/Ubuntu%20Bug%20Weekend Summarizing: While changing status for this bugs can disrupt development work-flow, setting their importance to a default value can be a visual aid for everyone. Sorry, this does not make sense for me: I will rephrase, as I understood the above sentence: while changing status for workflow bugs can disrupt development workflow, I do not care. It is not my workflow. The importance will be set by the people working this workflow, if they so want to. Otherwise it should be left as is. -- ..hggdh.. -- Ubuntu-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
Re: Bug importances - Suggestion for improvement
On Wednesday, April 09, 2014 15:00:49 C de-Avillez wrote: On Wed, Apr 9, 2014 at 2:52 AM, Alberto Salvia Novella es204904...@gmail.com wrote: El 08/04/14 22:35, C de-Avillez escribió: Sorry, I do not understand what you said above. Can you please rephrase? Yes: Although bug management does not apply to workflow bugs, they still have to be worked first by developers. So setting these as critical is a visual aid for them. Why? This is not a bug, it is a workflow. If this is not a workflow you are *involved* with (as, for example, 100 papercuts) you *cannot* change anything in the workflow bug without clearing it out with the people that actually work them. It does not matter if my personal perception is this is a critical (workflow) bug for *me*: it is NOT a workflow under your responsibility. El 09/04/14 00:52, Thomas Ward escribió: In the How to Triage guide [1], even, there's a section labeled Special Types of Bugs [2], which says that unless you know what you're doing, you shouldn't touch those bugs. Status included. Because this is prone to mistake, perhaps we can warn in the Bug Statuses page itself that these bugs are not covered in that policy. Agreed. El 09/04/14 00:52, Thomas Ward escribió: That's my opinion on this. Let's move on to actually fixing bugs, not dealing with how we set the importance on special bugs, of which our bug triage rules don't really apply in the same way (if at all, case in point merge requests, sync requests, security bugs (which have slightly different policies), etc.). There's another relevant part of setting importances for all bugs You again are mixing real bugs and workflow bugs. , which is bugs that really need its importance to be set can be catalogued in work-flows made of list; without having items in these that cannot be cleaned up. For example, in the following work-flows: - https://wiki.ubuntu.com/One%20Hundred%20Papercuts/Work-flow - https://wiki.ubuntu.com/UbuntuBugControl/Final%20clean-up - https://wiki.ubuntu.com/Bugs/Ubuntu%20Bug%20Weekend Summarizing: While changing status for this bugs can disrupt development work-flow, setting their importance to a default value can be a visual aid for everyone. Sorry, this does not make sense for me: I will rephrase, as I understood the above sentence: while changing status for workflow bugs can disrupt development workflow, I do not care. It is not my workflow. The importance will be set by the people working this workflow, if they so want to. Otherwise it should be left as is. Please, please, please! If you are not a developer involved in the relevant workflow of a workflow bug, leave it alone. You may think you are helping. Trust me, you are not. Scott K -- Ubuntu-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
