Thank you, Loekie, for introducing the new ideas about the buglist organisation.
Separating them into categories is much more what I call "overview" than what we had in the past.
I fully agree to the idea.
However, may I add some ideas?
All planned categories are closely connected to program functions. However, there are and will be bugs, that do not fit into that list.
Sometimes, the developers or the forum team will have to decide about the correct category. We are players, we are customers, we are NOT technicians, who can always be sure about which function definitely causes a problem/bug/delay/wrong data ...
Well there should be at least one category for uncategorized stuff.
1st suggestion: Add a category general/unknown for bug reports, your customer is not sure about the correct category
More: sometimes we might discuss if a report is a suggestion, a question, or a real bug.
Bad user experience for example is a bug in my perception, though the program works as intended
(two examples: a) if any list shows just 5 lines in rectangles that are too big to be seen completely and to show all usefull buttons to scroll and jump ... the worst user experience is, that I have to scroll DOWN to find the button to GO TOP. b) mouse movements: several lists have buttons at top, and then you have to move all over the screen to finde the "OK" button .. user experience means to make mouse usage easy and not a marathon across the screens)
Well, such reports might be "general" (1st suggestion) but I would (knowing that you would not call that a bug):
2nd suggestion: category user experience
Well, though most of the players are not technicians, some are. Some will use the developers functions of the browsers to find out what happens. For these people, it might be usefull tu have ...
3rd suggestion: category backend problems/performance/loading problems
Next one is care for handicapped players. Last year we had a very good discussion about colors, contrasts, transparency and their effects to color blind or color weak people. That changed many details to the better. But then the developers interested in that discussion became quiet and data slowly changed bask to light grey on lighter grey with too much transparency. The game returned to weak contrasts and lots of transparency. Which means: handicapped people cannot play this great game.
4th suggestion: category visibility of information or accessability (for people with a disability)
And one more: graphics and animations.
if machines look great when they go west, but change to paper thin objects when going south or just south west, there's something wrong. We players cannot decide if if's a calculating problem (calculating thickness of the machine), or if the graphic artist made a mistake. But what we can tell: graphics don't look correct.
Same with overlapping elements or - worse - with railcar distances behind their machines. That might be an error of the graphic artist, but might also be a bug made by the programmer who calculates the disstances from pictures length and train direction.
5th suggestion: category graphic bugs
Well, still not a complete list of categories, so I also suggest to keep it open and extendible.
And please allow players to call annoying stuff a "bug", though the programm works as intended. Bugs not only appear on coding, but also on planning. And a bug made on planning a function creates a programm as planned, but a game not working as the players expect or would use.