Page MenuHomeFeedback Tracker

Classification in Issue Tracker should not be done by reporter
Closed, ResolvedPublic


Since most issues tend to be classified wrong, the method of classification should be changed (vote up, if you agree; vote down if you disagree)

  • The Priority should be set by the ratio of up/down votes. The more people vote one issue up, the higher the priority it should be dealt with.
  • The severity should be set by a dev.


Legacy ID
No Bug
Additional Information

There are a lot of reports which are too low classified and vica versa.

Tags should also be a "must include item" maybe even a live search upon typing the issue title to reduce double-reports.

Event Timeline

Egosa-U edited Steps To Reproduce. (Show Details)Mar 8 2013, 3:42 PM
Egosa-U edited Additional Information. (Show Details)
Egosa-U set Category to General.
Egosa-U set Reproducibility to N/A.
Egosa-U set Severity to Feature.
Egosa-U set Resolution to No Bug.
Egosa-U set Legacy ID to 1932672128.May 7 2016, 11:45 AM

Hello all, Bashkire here!

You know what, I wholeheartedly approve of this.

i agree with you 100%. i for one have no clue about the Category in which somethings would fall under.cause im new to pc gaming so i would not be used to some of the category terms and what falls under that bracket.but im good at find bugs and stuff not good when it come to putting it in writing.

100% in agree on this !
All the mess around this issue tracker is only going to slow down the fixing process and i'm sure DEVs and Managers would be more than happy to have something that they can trust on when it comes to priority, severity and category.

Also, all the damn multiple reports for the same issue.. seriously ? (@community)

I agree with the priorities. I checked on them and couldn't decide how important or not what I was reporting should be.. It is important to me sure but maybe not so much others, I'd be a dick to report something like PIP zoom and thermal auto brightness as being severe just because I believe it is.

Immediate thought, great idea. But then, a bit worried there are ways to abuse this. Not that I know how much some people decide to make multiple accounts and down-vote something, but it's an option, and since I can't think very well right now I suspect there are also other methods of this system being abused, so not entirely sure it's just a great thing to implement.

And whats the use of the double-regs? An issue with 300 voters (and up-down-ratio of 200:100 for example) will still be higher ranked(and thus would be earlier read by a dev) than a 50-voter with Ratio 40:10, because there are more people interested in. Priority only says, if and when an issue will be considered/resolution set by a dev - either accepted for change or declined, etc. . High votes are not a guarantee that the issue will be solved in the eyes of the reporter.

Quedr added a comment.Mar 13 2013, 1:53 PM

Upvotes only signify the interest of the community for the issue, and should *not* be used for priority (except for issues in the "crash" category, which should all be high anyway), as long as features are posted on the same issue tracker as bugs.

For example , while I (and the community) agree that it would be interesting, there are many issues (crashes, sound engine, flight model, IA bugs...) that should be addressed before even considering implementing this feature.

A way that might be more efficient would be for BI to provide clear guidelines on the correct use of priority and severity (game breaking, feature, minor glitch...).

Another way would be to remove the priority altogether, replacing it by the severity, and let the developers set the priority on their internal bug tracker when the issue is accepted.

By the way (shameless self promotion), this issue is trying to address the multiple reports problem

[QUOTE="Quedr"] Another way would be to remove the priority altogether, replacing it by the severity, and let the developers set the priority on their internal bug tracker when the issue is accepted. [/QUOTE]

I bet, the accepted issues are already placed into another priority-list for the dev-team only. Regarding crashes -> those are all quite often accepted/ongoing by a dev, whereas "whishes for changes" are mostly not even commented by a dev), even if they seem severe - maybe because the devs don't focus on that *yet*.

To your "shameless selfpromotion" (what I think, fits into this pretty well): I put under "Additional Information": Tags should be a "must have" to reduce (not eliminate) the "multiple reports problem".

So, anyone reading here please also vote on:

Thales added a subscriber: Thales.May 7 2016, 11:45 AM

We are very sorry, this issue was closed as no-bug.