It’s good to see that a web based Feedback finally is coming. But please tell me why I should do even more work for Xojo:
Sometime next year we intend to update the system such that when as case has had no activity in many months, the system will automatically ask the user if this case is still relevant. If they indicate that it is, the case will remain open. If not, it will close.
There are bugs in the system that are 10 years old and are still relevant. It’s Xojo’s job to check if a bug is still relevant or not. That’s not our job as users. We do the testing already.
Yeah, I’m really not a fan of this policy either. There are so many that just get ignored through no fault of our own. After we tell the system that it’s still relevant, will it do something to get an engineer’s attention on it? I expect not, in which case this “feature” just becomes a war of attrition. Eventually, the user will forget to reverify and Xojo can clear it from their plate despite never having done anything with it.
After all the work of reporting a bug, providing a sample project, maybe some screenshots and screen casts, writing a description of what we are doing, proofing which IDE versions and which OS is concerned, often struggling around with without any comment closed cases because not even our description and step by step instructions were read exactly and therefore the error can not be reproduced …
So after we do all this work for Xojo (yes - most of this work should be Xojo’s part) we also have to confirm every few months that the bug is still relevant.
This literally screams to simply confirm all requests with “YES”.
I disagree here. When filing a bug report for any app, the responsibility is on the reporter to make sure the information is clear. Xojo needs to know how to reproduce the bug. That is 100% on the reporter, because otherwise Xojo might take the wrong steps and either fail to verify it or maybe even verify a different bug.
That’s right - totally agree with you.
Often it gives the impression that Xojo itself does not even try the provided demo projects, screenshots, etc. and only asks on suspicion whether this or that could work.
Random example for really old bug: <https://xojo.com/issue/12072> 12072 - Xojo crashes when C++ raises exception in out of memory situation . From 2009! Rank 51. Who knows if Josh Hill is still using Xojo.
Not a big difference really. Now instead of they just ignoring the bug and leave it there OPEN for years, now they will close it if you are not constantly replying that you are still interested in the bug being fixed.
Closed could mean, you need to file another one. Many people won’t do that since they could find that closed shows that xojo is not fixing it… causing bugs to be unreported after that.
Even the priority system seems wrong. Some things like project types ands saving should be #1 then IDE and layout editor #2 etc since we still have for example the “true” vs true fighting in xojo_project files and many such other ide-written-save-changes-by-design we still have more work to do (manual reviewing git stuff). If those where never there one could have had more time to file reports. I’m not saying it is bad or non functional, just that it seems ineffcient.
So you have a bug, you can’t reproduce but xojo may he able to find a cause in code or at least investigate. They simply close the case because of no example project, that isn’t even possible for one to reproduce? A clear video was made (screen recording) to show the issue.
I think this is the wrong way to apoach it. It’s like there is no activity around those cases at all. Seems to me like it’s not worth my time to file any case.
We often think exactly like this.
We don’t file bug reports anymore which we can’t reproduce because we know that they are simply getting closed without even thinkin about it or investigating it.
With the exception of IDE crashes where an automated case is generated.
There we write 3-4 words what we were doing. But strictly speaking, we could save ourselves the work, since these cases are simply closed without a sample project anyway.
On the other hand if we don’t file cases nothing changes…
In my experience, they don’t just close it. Your video may give them enough of a clue to reproduce it, but odds are it will not. So what should happen here? The case ends up amounting to “something is wrong.” If it can’t be reproduced, it can’t be fixed.
Normally, there’s a closed reason indicated. If I check a given bug and find one with a status like “Closed—User didn’t confirm the bug is still there since 6 months”, I won’t blame Xojo thinking they just don’t want to fix the bug.
And I still prefer having cases automatically closed (where one can create a new case if necessary) than so much cases left open for years, should we have to choose between the two options.
Closing automatically means Xojo will focus on what’s known to be active. Both the users and Xojo will have a better visibility of what’s actively reported.
If something has been closed by mistake, because a user hasn’t confirmed the bug, someone more active in using Xojo may just create another case; that doesn’t frighten me.
Can’t reproduce can’t fix implies there had not been enough willingness to fix the issue same as feature requests. In xojo’s terms willingness is on the forums, mass compaints or high fb ranking. But that means there is Always A Way.
I think the main issue is that Feedback is just not working good/stable/easy for everyone. Most devs i know think it’s too hard to find their way trough feedback app. I have numerous crashes, disconnections etc. Basicly so much i’ve given up to even use it. Not to mention 75%(about) cases are just closed because even we can’t reproduce them. Meaning we put more energy in than we’d even get out… we only filed such cases mostly because we had a requirement for them.
I don’t know what you’re trying to say. “Can’t reproduce can’t fix” doesn’t imply anything. It means there is no test case. There is no way to confirm that the bug is fixed. Sure, somebody could look at code they think might be to blame, and make a change that they think might fix it, but that’s not the same thing at all. What do you put in the release notes? “Made some changes that might fix X, but we don’t know for sure.” We’ve all been in situations like this, I know, but Xojo is a large product with a team of developers and dozens of reports filed daily. You cannot expect them to just make changes willy-nilly without some sort of test case.
In any software, if you can’t reproduce a bug, you can’t know it has been fixed. Maybe you fixed it, or maybe you’re just failing to trigger it. No way to know for sure.