Hello
Do we have any bug importance guidelines? I'm asking because some of my bugs had absurdly high importances.
This node toolbar "bug" that is a cosmetic change in UI got "High" - same as the flowtext issue. https://bugs.launchpad.net/inkscape/+bug/534045
This preferences "bug" that affected a developer-only debug setting got "Critical" - same as graphic tablets not working on Windows. (and I don't even agree with classifying this as a bug - for me it's an incorrect use of preferences) https://bugs.launchpad.net/inkscape/+bug/367752
Regards, Krzysztof
On Mar 7, 2010, at 4:22 PM, Krzysztof Kosiński wrote:
Hello
Do we have any bug importance guidelines? I'm asking because some of my bugs had absurdly high importances.
This node toolbar "bug" that is a cosmetic change in UI got "High" - same as the flowtext issue. https://bugs.launchpad.net/inkscape/+bug/534045
No, not quite.
It is *your* assessment of that bug considered it cosmetic.
However, it was a removal of documented UI functionality that is covered in the current crop of Inkscape books among other places.
It also removed a fair bit of *functionality* of the UI. I can attest that when I'm using a graphics tablet it is much faster for me to have a single button that is visible to click on instead of having to set down the tablet and stylus, reach over to the keyboard, hit a key combo, pick back up the stylus and tablet and then continue. Even navigating menus is a slowing operation that breaks the workflow.
An illustration of the workflow might be:
* Decide to "fine-tune" and object * Click on the node tool to start editing it * See that the object is an object, not a path and recognize that the toolbar buttons and tool will not have the desired effect * Click on the toolbar button to convert it to a path * Start using the node tool on the current object/path.
Additionally you tend to call problems "absurdly high" when that is a very subjective term. I believe that this has even been addressed specifically before.
As to how a specific bug gets addressed, it is usually with several people looking it over and talking with the person who reported it. I know that this specifc bug was discussed on IRC directly with the reporter; the impact was verified; and several people including ScislaC and su-v all reviewed and discussed it.
In general one needs to consider the impact to the end user. That is the first consideration. Also keep in mind that our bug tracker has only a single "Importance" field. In software development it is common to also split that up into separate "severity" and "importance" fields, but we had chosen not to do so.
This "importance" field really addresses the level at which a developer needs to address things. A crasher is most likely going to have a high importance and thus say "fix me soonest". However a crasher that only occurs on some very unusual edge cases and does not have a simple fix could easily end up with a low importance.
Also as we get closer to a release, the relative importance of items will shift. Issues that should be addressed for that release will get a higher importance while issues that can be deferred to the next release will get a lower importance.
So here are some things to work through in your mind when looking at a bug:
* How will this affect an end user? * Does this break any existing behavior? * Does this impair usability? * Does this pose a security or data risk? * What is the *severity* of the problem? * What is the effort that will be needed to fix this? * How soon does this need to be fixed? * How close are we to a release?
So working through 3534045 we can get: * This issue definitely affects end users, and artists have already started reporting problems. * This removes functionality (the one-click workflow) that has been present and documented for several releases. * The lack of one-click object conversion slows down a set of end users, and in an understandable manner. * There is no impact towards data loss nor security risk. * It is of relatively low severity * It is very little effort for a developer to correct this. Probably less than 1/2 hour including before and after testing. * We need to fix this before 0.48 gets to any more testing phases. * We are very close to locking down for 0.48
So between the first two and last two factors we get to the point where it is deemed to have a "High" importance. However it definitely does not rate a "Critical" one. (Generally having any security or data loss will immediately get a bug promoted to "Critical")
If you have more questions on how software issue triage should work, definitely drop in the chat room and talk with ScislaC and su-v to see if they can help you get a handle on it.
On Mar 7, 2010, at 4:22 PM, Krzysztof Kosiński wrote:
This preferences "bug" that affected a developer-only debug setting got "Critical" - same as graphic tablets not working on Windows. (and I don't even agree with classifying this as a bug - for me it's an incorrect use of preferences) https://bugs.launchpad.net/inkscape/+bug/367752
Please try not to engage in revisionist history or misrepresenting an issue.
For bug 367752 the initially noticed manifestation was in a developer-only debug setting. That is, the visible effect that someone first noticed was such a setting, *However* the effect of the bug was verified to be far ranging and to have a much more severe impact beyond how you portray it there.
So for software bugs please keep in mind that the visible *symptom* of a bug may not be the only effect of a bug, and that not noticing an immediately visible symptom does not mean there is no other affect.
Remember...
Testing can only prove the presence of bugs, not their absence. - Dijkstra
Additionally you tend to call problems "absurdly high" when that is a very subjective term. I believe that this has even been addressed specifically before.
Moving a command to a different place, therefore increasing the number of clicks needed to execute it by 1, is not even remotely comparable in severity to flowed text not being SVG compliant; hence "absurd".
I wrote a long rationale why the prefs bug was not critical and probably not even a bug, but I consider further discussion of this to be pointless and unproductive, so I will refrain from posting it (unless somebody else is interested, but I doubt it)
Regards, Krzysztof
Forgot one thing: Jon, you could fix this bug, because it was introduced by your fix to the preferences bug (I don't know whether you noticed it on the tracker and this thread reminded me of it)
https://bugs.launchpad.net/inkscape/+bug/374455
Regards, Krzysztof
On Mar 11, 2010, at 8:32 AM, Krzysztof Kosiński wrote:
Forgot one thing: Jon, you could fix this bug, because it was introduced by your fix to the preferences bug (I don't know whether you noticed it on the tracker and this thread reminded me of it)
Actually, that came from some other factors, include some I tried to point out about the overall push of preferences.
For testing purposes it is very good to not have all low-level components "reach out" and grab the things they think they need to use. It breaks encapsulation and modularity, and makes things harder to both reuse and to test. The latter one is the issue here.
What should have been done in the overall preferences rework was to have interfaces pushed in from high-level components. In this case that would allow a tuned version of the preference store provider to be passed in.
However, in this specific case we do have problems occurring from inside of a nice unit test framework that supports mock objects. Those should be used to hook in to the CxxTest ones. The older test framework that we're migrating away from needs some help, so see what you can figure out about the mock objects. Or a simple test mode for the test programs would be good.
W dniu 11 marca 2010 19:09 użytkownik Jon Cruz <jon@...18...> napisał:
However, in this specific case we do have problems occurring from inside of a nice unit test framework that supports mock objects. Those should be used to hook in to the CxxTest ones. The older test framework that we're migrating away from needs some help, so see what you can figure out about the mock objects. Or a simple test mode for the test programs would be good.
I have no idea what you are trying to say. The test in question tests the Preferences object. It is not possible to replace it with a stub because then the test becomes meaningless.
Regards, Krzysztof
On Mon, 2010-03-08 at 01:22 +0100, Krzysztof Kosiński wrote:
Do we have any bug importance guidelines? I'm asking because some of my bugs had absurdly high importances.
The simple method is:
Low: Quirks, really obscure things, and minor nit picky things. Medium: Bugs which affect usability, functionality, behavior, etc. High: Crashes, regressions, or bugs related to file open/save problems. Critical: Data loss or file corruption.
Obviously, build breakage would be thought of as high too, but it should hopefully not take long enough to merit a bug report before fixing.
This node toolbar "bug" that is a cosmetic change in UI got "High" - same as the flowtext issue. https://bugs.launchpad.net/inkscape/+bug/534045
Not a true regression, so High is definitely too high of importance.
This preferences "bug" that affected a developer-only debug setting got "Critical" - same as graphic tablets not working on Windows. (and I don't even agree with classifying this as a bug - for me it's an incorrect use of preferences) https://bugs.launchpad.net/inkscape/+bug/367752
I don't want to asses the bug importance on that one... you and Jon can hash out your issues alone. ;)
Cheers, Josh
participants (3)
-
Jon Cruz
-
Joshua A. Andler
-
Krzysztof Kosiński