That is true, However not fixing bugs can certainly cost potential revenue.
Proposal Discussion Bugs & Issue Tracker
- Thread starter rootsrat
- Start date
I added all the necessary steps for reproduction of the issue to the one you posted, too!Sigh
Please add to existing reports instead of making new ones!
Issue Tracker
issues.frontierstore.net
I wonder, perhaps the top 20 issues should ALL be that nothing is being done.
Actually, this is also testable and I may have been too hasty.
If you just sort the "all bugs" list by Top Voted, it also tells you how many votes (relatively) a bug had when it was closed.
So, of the top 131 all-time voted bugs (i.e. all those which received 5 bars of votes):
Still Open and have been for a while: 9 (including the two feature requests and the ancient triviality, of course)
Opened in Update 14: 3 (including the new top voted bug of all time - the mission boards timing out)
Duplicates or Invalid or By Design: 22
Fixed: the remaining 97
That gives a "fake fix rate" 1-(Confirmed / Confirmed+Fixed) of 89%, which is higher than the 85% for all bugs. It's not that big a change, and the number of votes needed to get 5 bars is substantial, but it does seem to have some correlation with the fix rate. Of course, higher-voted bugs tend (tend!) to be more severe, so there still might not be any actual cause-and-effect going on.
1722 bugs seem to have ever received votes (and that was tedious to count!), so we can do a "fake resolved rate" with that, too:
All votable bugs: 1-(227/1722) = 87%
Five-bar bugs: 1-(12/131) = 91%
Not greatly different to the fake fix rate pattern.
So ... revising that: voting might not be entirely useless, though Frontier probably can tell the actual severity of a bug without that as input anyway so it's probably not necessary except for political reasons.
I find this pretty funny, because looking at all the data, Frontier:
- Have a pretty good record of fixing important bugs in Elite Dangerous over the last four years
- Have an even stronger record of fixing the most critical bugs (as loosely measured by votes) - and generally pretty quickly, too
- Have intentionally designed their bug tracker to present their performance and committment to bug fixing in just about the least flattering light possible, highlighting any failure or delay vastly more so than tens of successes or prompt responses.
If I were to guess, I would say confirming/voting is simply a way to make issues more visible to the CMs, who are ultimately responsible for choosing which issues reach the developers to be addressed.
I've been involved in a different reporting tracking & prioritization model, for another company, different kind of game.
IMHO it worked better.
With the current FDev Issue Tracker we still have the same issue as the above model. Perhaps even to a much bigger extent.
Missing repro steps, missing info. Incorrect device configuration, driver or OS-settings.
But the result with the current FDev tracker is that there's issue-rot. It's probably too many issues to manage.
The end-users are responsible to make sure issues are being sorted & combined (aka managed by end-users).
This is a extremely bad model. No users can ever manage and orient themselves across thousands of similar issues.
A dedicated team of trained people can, as long as they stay on top and organize the input to a tracker.
IMHO it worked better.
- Community used the open forums to report problems in subforums / subcategories.
- Dedicated Volunteers testers & staff had access to the BugTracker, but also acted as volunteers for the bugs-forums.
- Lot's of forum posts, often unstructured. Relevant repro steps & info was often missing.
- Some issues may go unresolved if not the right folks had a look at the problem / and or requested more info.
- Testers/Trained Volunteers sorted and combine several similar issues into the appropriate problem. This way the many similar reports got updated at the correct ticket.
- If it was a device/config problem on the user side, then it could be resolved through discussions.
- Forums Posts Public reports was updated with "REPORTED" or "REPRODUCES" kind of tags.
With the current FDev Issue Tracker we still have the same issue as the above model. Perhaps even to a much bigger extent.
Missing repro steps, missing info. Incorrect device configuration, driver or OS-settings.
But the result with the current FDev tracker is that there's issue-rot. It's probably too many issues to manage.
The end-users are responsible to make sure issues are being sorted & combined (aka managed by end-users).
This is a extremely bad model. No users can ever manage and orient themselves across thousands of similar issues.
A dedicated team of trained people can, as long as they stay on top and organize the input to a tracker.
Last edited:
Well that's odd, as Edge is based on Chromium.
Both of my laptops and my desktop have the same issue, since somewhere 2021. Those are fresh screenies.
And:
- The curator adds effective keywords so players doing searches find them better, reducing duplicates being submitted making their job easier.
- Legit reports get flagged so they don't expire. Even if they didn't get enough votes, who cares. If the report is good and the bug is obviously reproducible. This would reduce player effort and encourage people to add additional valueble information to existing reports. Also because the same report hangs around it would reduce the number of new reports being submitted (because it shows up in the search) making their job easier (less new reports to review).
I don't get it. Isn't that been a problem for the past years? The bug tracker being just ignored? What makes this pop up at the front now again?
Dropping an anecdotal observation, because I peeked into an Issue ticket about dumbfire missiles not having a working trailing reticule indicator a while back...
For this ticket the "steps to reproduce" was a rather verbose wall of text that, imho, boiled down to...
... "To reproduce JUST PLAY THE GAME, ya gorram numbskull!".
I've been on the receiving end of such "helpful" (sarcasm) interactions as a developer, and you very quickly want to do something else entirely.
And if an "issue" is a feature request rather then a bug it'll burn through your goodwill and/or willingness fast, as well.
Now in the above example it's easy to reproduce...
But as a ticket creator you could just record a short ten second clip of the multicannon in trailing; showing that multis work fine, and that's sort-of what you'd expect for missiles too.
Then show another clip of the dumbfires, showing that Trailing is active in the UI righthand panel, but not showing on the HUD at all.
Maybe add a hunch/tip on why it might be "kind-of" broken; for example the Supercruise Interdiction Minigame UI reticule was missing too at one point and was found to be rendered far off-center so it was always missing visually despite still being rendered - so maybe it could be like that in case of missile trailing reticules?
If it's hard to reproduce an issue, then you cannot begin debugging it.
For this ticket the "steps to reproduce" was a rather verbose wall of text that, imho, boiled down to...
... "To reproduce JUST PLAY THE GAME, ya gorram numbskull!".
I've been on the receiving end of such "helpful" (sarcasm) interactions as a developer, and you very quickly want to do something else entirely.
And if an "issue" is a feature request rather then a bug it'll burn through your goodwill and/or willingness fast, as well.
Now in the above example it's easy to reproduce...
But as a ticket creator you could just record a short ten second clip of the multicannon in trailing; showing that multis work fine, and that's sort-of what you'd expect for missiles too.
Then show another clip of the dumbfires, showing that Trailing is active in the UI righthand panel, but not showing on the HUD at all.
Maybe add a hunch/tip on why it might be "kind-of" broken; for example the Supercruise Interdiction Minigame UI reticule was missing too at one point and was found to be rendered far off-center so it was always missing visually despite still being rendered - so maybe it could be like that in case of missile trailing reticules?
If it's hard to reproduce an issue, then you cannot begin debugging it.
IMO the Issue Tracker doesn't matter. Might as well be shutdown:
- It doesn't even function properly. Its has glaring bugs with itself. Plus its clunky to quickly navigate. And they want customers to voluntarily submit useful information?
- The reported issues are obviously not important to Frontier. Expiring valid reports, and perfectly good reports marked as "Invalid"? (I can give examples of clear game software functional bugs marked as invalid)
- The system is based on a voting system? A system that eventually players conclude is worthless so can't be bothered to use, because its worthless, but its based on votes? How is that supposed to work??? I'm sure they get spats of players voting until they realize their time was wasted. Every 6 months the Issue Tracker is relying on a new batch of voters to replace those that have given up.
- A widely accepted perception by customers that the Issue Tracker is a worthless waste of time and that Frontier has it only because they should have an Issue Reporting System so they have one.
Last edited:
In my previous playing I've tried two ground missions in thargoid-recovery state, both broken. Today I've decided go for some good "old" ground on-foot cz combat and visited one high CZ (with limited free time I used my own ship and not frontier solutions vulture) ... in the end I've cleared last enemies alone while I was chased around big settlement and surprise, surprise ... CZ summary did not appeared, combat zone have not ended, means that there too is something broken. I'm going play something else for a while, I somehow lost most of fun with playing this game when bugs happens too often (I really do not understand why there is so huge issue properly test and made working missions, CZs). .. and no, I'm not in mood trying to write another useless bug report which very likely would expire like most of my other. I looked into IT and found there nothing similar reported. Means I'm either incredibly unlucky or players unsurprisingly do not bother any longer report bugs whichs do not crash game.
Attachments
Last edited:
CZs not finishing properly has definitely been reported before. It happens about 50% of the time I play Medium CZs. When I play Low CZs, the NPCs are often frozen to the spot (same as sometimes happens on non-combat settlements where no-one walks about, they just stay standing where they spawn).
How we do bug reporting at my employer (our product is specifically for customer support btw): we have a forum where all our customers are member and can talk to eachother to give tips etc, but we also have a section where people can vote on ideas or on reported defects that are not working.
Our support team and product owners are active on that forum daily and will take information from there to turn into actual Jira tickets for engineering.
On top of that support also has their own ticket tool (freshdesk) for incoming support emails/calls. They de duplicate reports here, and again create Jira tickets for product and engineering.
This still has all the voting and deduplication, but our customers don’t need to learn/fight a new tool, just to get issues reported/seen. They also get updates when an internal Jira ticket related to their report gets picked up and/or closed, because all the systems are connected.
With Fdev it seems there might be a disconnect between Frontiers issue tracker and whatever it is they are using for ticketing internally.
All I can say is that our customers are pretty happy they can report issues on the forums they were already using, and also to see how widespread it is via others votes.
Our support team and product owners are active on that forum daily and will take information from there to turn into actual Jira tickets for engineering.
On top of that support also has their own ticket tool (freshdesk) for incoming support emails/calls. They de duplicate reports here, and again create Jira tickets for product and engineering.
This still has all the voting and deduplication, but our customers don’t need to learn/fight a new tool, just to get issues reported/seen. They also get updates when an internal Jira ticket related to their report gets picked up and/or closed, because all the systems are connected.
With Fdev it seems there might be a disconnect between Frontiers issue tracker and whatever it is they are using for ticketing internally.
All I can say is that our customers are pretty happy they can report issues on the forums they were already using, and also to see how widespread it is via others votes.
Last edited:
There may be numerous reports about it, but NO ONE report is yet confirmed and cannot be therefore voted. I strongly suspect that issue with surface conflict zones happens mostly in cases when player do not use frontline solutions shuttle (putting aside fact that it is the worst time effective method). There should be main guidelines/categories for reports in IT which would show player reports from similar environment, i.e. Combat -> Foot which would give much higher chance that there will be not so much separate reports about the same thing. It may be also very helpfull to QAs with sorting reports.
Last edited:
btw ... just now I wanted do classic base restoration mission. Reactor console is inactive (instead is active point defense console), so mission cannot be finished. I really have no idea how this game is being bug tested, 5ve different mission in row I did, all were bugged (different issues). I'm not even sure if there is any need for IT when basic things which can be tested (i.e. mission routines) are full of bugs (or settings allow improper functioning).
.. menu restart "fix" worked, so it means it is random bug in mission activation. This however emptied all setlement lockers/data points.
.. menu restart "fix" worked, so it means it is random bug in mission activation. This however emptied all setlement lockers/data points.
Last edited:
Jumping on the thread to give this as an example:
issues.frontierstore.net
69 pages, acknowledged by FD but no resolution.
Issue Tracker
issues.frontierstore.net
69 pages, acknowledged by FD but no resolution.