Labeling decision: usability + bugs

[DanVanAtta]

A quick topic to decide how to label for usability vs bug types.

I would suggest these 3 options for discussion:

1. keep as is, two labels, one for bugs, another for usability problems (with a small grey area when a usability problem is so bad the feature is effectively broken, ie: defective or buggy, eg: Existing Bombing Damage Not Displayed on Bombing Target Selection Window #2333)
2. Drop the usability label type, just use type: bug for both bugs and usability problems, and we'll just know that is how we defined 'bug'
3. Merge the two labels, renaming to something like: type: defect or UX problem

[ssoloff]

Without any other context, I view type: bug as having a slightly higher priority than type: usability. So I think the extra label has some value.

However, if it's decided that a single label is best, I would suggest a slight variation of option (3) to keep things simple: type: defect. I don't think there's a need to further qualify it with or UX problem.

[DanVanAtta]

Neither conveys a priority, a bug could be hard to notice while a usability problem could be so severe you can not use a feature.

I personally would opt for type: UX problem over type: defect if we were to merge the two (to me UX problems can include bugs, but many UX problems are not necessarily bugs). This I then I think would work well with our category labels, which then could further hone down to whether something is just a UI glitch, a problem with game rules, or something that is causing a game crash.

[DanVanAtta]

Some more consideration, maybe just - type: problem
I think we may see situations where we are reviewing and finding a lot of none-critical items, I'd rather not call all of these things 'defects', I'm concerned it would discourage us from fixing the smaller things.

[prastle]

If renamed it changes nothing. Usability should take precedence over a bug in most instances. BUT I am a live player. Either decisions are fine.

[prastle]

A better wording would be PLAYABILITY and SPEED of game ... but i know dan will yell at me about this :)
gl with your choices :)

[DanVanAtta]

Again, severity/priority can really vary. There are many aspects to usabiltiy/UX problems, some are delays of games, others could be windows that are covered or rendered unusable through user action while some bugs are game killers and others are hard to notice.

This does make me think still that type: problem is perhaps the right way to go, with category labels as additional clarification (eg: category: playability, category: speed, category: defect, category: crash)

[Cernelius]

I definitely would say this is a bug (either a bug in the map, if you are supposed to never have multiples of the same bombing targets, or a bug in the engine, if that is supposed to be supported):
#2333

Let's make a simple example.

I open TripleA and the entire screen is completely white, but I can still fully play the game, if I happen to blindly click everything correctly, by mere chance.

If that would be a bug, not usability, then having two different things to click on, and no way to know what is what, is a bug as well.

On the other hand, if the engine tells me when I buy too much or, instead, I have to do all the math myself, that is usability, as long as the game is always allowing me to see all I need for accounting.

[DanVanAtta]

I definitely would say this is a bug (either a bug in the map, if you are supposed to never have multiples of the same bombing targets, or a bug in the engine, if that is supposed to be supported):
#2333

Not knowing what to click on, even though everything is correctly (but maybe not fully) labelled is a usability problem. It would be a bug if for example the factory were not actually repaired after taking the action, or maybe the wrong unit were repaired instead (ie: the resulting action were incorrect). This is an example of a usability problem that is so severe you pretty much can not use the feature.

If you want to call any broken feature 'bugged', I can't really argue with that. Though technically, all code as written is working exactly as intended. On the other hand there is a requirements miss, incorrect assumptions baked in that make it impossible to use the feature correctly in some situations.

In general I don't like defining bugs against the intent of the code and coder. The "works as coded even though you still can't use it" is BS IMO. Hence, the 'usability' label was added and is tracked here alongside bugs, so it does not matter since we still track the problem. Now, I think it makes sense for us to just call it all type: problem so we can sidestep the 'usability' vs 'bug' debate. We can both agree the feature for selecting the infra unit here is broken, whether you call that a bad bug or a bad usability problem I don't know if it matters.

[ron-murhammer]

I don't have a strong opinion here. I tend to think of things as either bugs/defects/problems/etc or as features/improvements. If something doesn't work properly then its the first if its a suggestion to improve or add something new then its the latter.

Usability or UX is more of a category as you can have usability bugs (I personally believe the issue that started this discussion was on that type) or usability improvements/features which improve the overall experience for users.

[Cernelius]

Also, I personally would be sure that this is a bug (and would suggest labelling it as such):
#1270

In the moment you are offered an option you should not have, even if maybe all code as written is working exactly as intended... Well anyways I guess you should clearly define what a bug is, document it, and, then, try to apply it consistently. The main problem would be if each developer keeps his own ideas, then the labelling would end up kinda random.