Clarify what the categories mean in the bug report forum

flocsy🤠 said:

Non-simulator tool: probably some that I don't know because I don't use? Monkeygraph?

But you literally gave an example here? You clearly know of at least one non-simulator tool. Are you suggesting that it’s a useless or confusing category because you don’t care about monkeygraph?

There’s also monkeymotion (for animations), the ERA Viewer (everyone’s favourite non-simulator tool!), and the SDK manager.

flocsy🤠 said:

API: ??? I have no idea what is this. I do know what api usually means, but not in the context of the CIQ bug report forum.

I would assume this refers to any issues with the CIQ API that are not specific to the simulator or a given product (or set of products). Personally I think this could include things such as:

- incorrect implementation (implementation doesn’t match docs, especially in the case where the behaviour described by docs makes more sense than the actual implementation)

- unexpected implementation

- obvious bugs/crashes

- incorrect type definitoin

Admittedly this is a little fuzzy, as I can imagine some bugs could be equally categorized under API or Product.

Some of the other categories are fuzzy, too.

If a function is typed incorrectly, is that “Documentation” or “API”? I would argue it’s “API” (since the type information is present in both the documentation and the SDK, it affects type checking, and it’s part of the API definition).

As a concrete example, a while back there was a type issue with several fields in Weather.currentConditions which were typed as Number, but could actually be Float on some real devices (and Number on other devices), which led to some display issues for apps which assumed the type information was correct.

This was later fixed in the docs and SDK type information so that the fields were typed as Float or Number (or whatever).

Would this be best categorized as “API”, “Documentation” or “Product”. Personally I would rule out “Documentation” as the problem is deeper than that. (Maybe if Monkey Types didn’t exist, then “Documentation” would be a decent category for this problem). Should it be “Product” or “API”? Well, in hindsight, the docs/type definitions were changed to match the products and not the other way around, so maybe this was an API (type) issue.

I have no idea whether:

- the Number-only types were ever correct at *some point* and only became incorrect with subsequent products / firmware updates

or

- whether this problem existed as soon as type information was introduced for currentConditions, or currentConditions was implemented, whichever came first

Anyway, great post! I’m kind of curious to see what the CIQ team will say.

I thought the category is required. I remember they were at the beginning.

So if they don't serve you as you thought then it's kind of an unnecessary distraction. I use the tags anyway

Yeah, the category does seem to be required.

If you try to create a new bug report, the category drop-down defaults to API, there's no way to delete or unset the category, and the drop-down has no blank or "Not Categorized" option.

If I filter the bug reports section by "Not Categorized" and sort by descending date, the most recent "Not Categorized" bug report is from March 6, 2024. And if I filter by the actual categories, there are almost no bug reports older than that date which have a category, except for a handful of "API" bug reports which may have had that category applied retroactively (by Garmin?).

Both of those facts seem to indicate that bug report categories were introduced in March 2024.

It seems that if the intent was to force bug reporters to select a category, making the drop-down mandatory *and* providing a default value is not the best choice, as some people will simply use the default category of API even when it's not appropriate, which could further reduce the perceived usefulness of the category.

imo, whether or not the category is mandatory, the default value of the dropdown should be blank / "not categorized". If the category is mandatory, then the dev would be nudged to try to pick a value that makes sense (then again, nothing can prevent people from just picking the first available category anyway). If the category is optional, then they can easily avoid miscategorizing their bug report.

But I think the best solution would be for the category to be optional, and for the default value to be "not categorized" / blank.

It worked exactly like that on the day the category was added. I wasn't able to post a bug report and I had to ask in the discussion forum and the Brandon told us about the new category

forums.garmin.com/.../forum-bug-a-category-is-required-for-this-ideation 

Of course the link is not clickable... This forum is tragicomic

See: forums.garmin.com/.../forum-bug-a-category-is-required-for-this-ideation 

https://forums.garmin.com/developer/connect-iq/f/forum-about-the-forum/363276/forum-bug-a-category-is-required-for-this-ideation

When I add a new line after the url then it works

It's been that way for years.  For me, with win11 and chrome, the color changes when it's seen as a url