I found the following text, explaining the different status-options for tickets:
It´s just, people use some time to possibly document bugs nicely and have an interest in improving the game. Getting not a single comment but “solved” in return is a bit “sub-optimal”, i think.
Has my ticket been rejected and then closed, has it been entered in the bugs list and then closed/solved? What ever… at least a single line of text about the way, the reported bug is going to be treated, would be nice to get as some feedback.
Typically “solved” is understood as an solved problem, at least in any other ticketing system i know.
Be it as an fix, included in the next patch, be it an offered workaround… anything, that disables the problem.
Taking a bug on a buglist is not “solving” it already… so maybe it should be named “accepted”, if it´s accepted on the bug list or so.
For sure, noone can predict, when a bug really will be fixed… no question… but a bit more than just closing the ticket without any comment would be much nicer.
Zendesk tickets are all “noted.” How they get dispositioned specifically per ticket is not ever known.
Ah, i see.
So, maybe a bit more transparency in handling our tickets would be nice to have…
1 Like
Hi @daScooty, some similar discussion has taken place on this.
Here is how the category of Solved is used, which is mentioned in the ZenDesk FAQ:
- Solved: The bug report has been handled—our team has recorded the bug in our internal bug and issue tracker. Please note this does not mean you will see the bug fixed in the next update , but has been recorded and prioritized accordingly.
One of the other mods summed it up nicely in this post:
Important thing to remember is to send clear, concise, specific reports, including screenshots, crash logs from event viewer, steps to duplicate the issue, etc. So please keep quality bug reports coming through ZenDesk, and then use the forums as a secondary method of support.
2 Likes
Thanks a lot, i knew about the link towards the Zen FAQs, i added it in my initial post.
The second post you added made it much clearer for me than the “official” FAQ section, thanks for pointing to this post, i really had´t found it before.
1 Like
The fact that your tickets just disappear in blackhole on Zendesk is why I dont even bother there any more.
1 Like
I agree there needs to be some better feedback. I posted about this a number of times, but something along the lines of an actual tracker would be nice.
I see an advantage for them too:
If I post a feature idea and it gets rejected, I have no way of knowing because it is simply solved. If it is rejected I know that I probably shouldn’t bother them again with similar ideas. On the other hand I guess there is the risk that people start complaining.
This kind of feedback probably didn’t make a lot of sense in the first month with thousands of Zendesk reports everyday. But they are now down to ~90 every 12 hours. I think they can start giving some feedback then? Even if just a standard answer for rejected, not a priority, added to backlog, started development, coming in next version.
1 Like
I have a request for the Zendesk system that I think would make MANY people trust the system more.
Currently, when a Zendesk bug report is moved on to the next stage of its journey, it is marked “Solved”. Given the problem isn’t solved, since that’s not what happens from Zendesk, could we please have the notification changed to either “Accepted” or “Rejected”?
If it’s a duplicate of one that’s been accepted, “Accepted” is a perfectly good response.
I’ll let you guys decide to give an answer of why it was rejected. I’m fine with letting the user figure it out, but maybe a selection of 4 or 5 choices for various reasons for rejections could be used…
Something like:
- Unreproducible
- Not enough information
- (The dreaded) User Error
- You’re wrong
It would be really nice to know if the reviewer was able to reproduce the bug or not.
I had a situation where the reviewer of a crash responded with a list of standard reasons for CTD’s that had nothing to do with the CTD I was submitting, even though I gave them every bit of information they needed to reproduce the issue. I submitted it again and this time it was accepted and the CTD was solved in the next version. In both cases, it was marked Solved. I’m sure it was actually rejected the first time.
Marking it “Rejected” can help a user review their report and add more information, rather than feeling like… well, nothing, since “Solved” doesn’t actually mean anything.
Thanks to whoever made this votable 