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.