A customer can’t always reproduce an issue. Xojo may be able to do so since there may be more knowledge on where it may arrise. However it’s not always up to the customer to reproduce an issue, it’s too easy to blame a customer for NOT reproducing an issue and therefore not fixing it. There may be different issues and different test cases depending on an issue. Not all are the same, maybe on your plate but not mine.
1 Like
What i understood from the new development is that Xojo is more interested in closing the reported bugs. Xojo team has to understand that if the bugs can’t be fixed the ultimate looser is you and not the customer. You can always blame the user for not properly reporting a bug. Why not put an extra effort from your side also to identify the reported bug. You may employ more people to just analyse the reported bugs.
6 Likes
Going from more detail and more frequent updates to no detail and no updates;
Customer turns to colleague:
“I’ve put in a bug report about it, fingers crossed.”
A week later
“Have they even seen it yet?”
“No idea, it still says Open”
A month later
“Have they even seen it yet?”
“No idea, it still says Open”
A year later
“Have they even seen it yet?”
“No idea, it still says Open”
I swear I’m living in a Dilbert comic.
5 Likes
Best definition of software developer I ever heard.
Thank you, Beatrix!
P.S.: About the auto-closure, I feel the same. Statistics:
This release fixes 286 bugs and closes 2432 …
6 Likes
So, the clasic “whenever its ready”. How many people out there think that maybe web 2 is still not up to the task to produce a functional Web Feedback?
2 Likes
this Feedback system is like a open water faucet and this water runs uncontrolled.
somehow a administrative assistant from xojo should be there to input and verify new requests one thing at a time. (online service chat as example)
or this xojo framework need a better test system to reduce problematic cases before a new release appear.
Wrong sentence Steve, but good point;
The question may be:
“You have assigned points for this bug. Is your application affected by this bug ?“
Well one could argue that if a users’ points were still assigned to a case, then the user still cares about the case. Otherwise the points would be assigned elsewhere…to something they do care (read: impacts them in some way) about
Can’t reproduce means you can’t even be sure the bug exists.
1 Like
I wanted to highligh the difference between “this bug have to be removed” and “this bug hurts me”.
Yes, the former must be removed at all prices, but not against new features…
The later HAVE to be removed.
The points list is way too short… For example you can assign 5 cases to points. Now for months at a time your not in the FB app, top 2 cases are already finished… Now all that time the top 2 points are wasted, unused.
If you could make a LONG (like unlimited length) “my top cases” list, and only the top 5 or so get points then if one of those cases is fixed, closed or whatever the points can automaticly go to the NEXT cases in your list… keeping the points up-to-date at ALL times.
Unused points should go to any other of the user’s reported cases automaticly !
That should stop xojo from unprioritzing ANY case that MAY be relevant to current license holders.
Just a FIFO list or so where the points would automaticly step to the next in the list.
1 Like
But aren’t you talking about an initial classification of when the points are awarded vs the (assumed) 6 monthly ‘check for life’ test ?
That’s a “let’s auto stealthily try to sweep the dirt under the rug and pretend it doesn’t exist until things eventually blow up” policy.
A reviewer, a person (or a bot), must close cases when any acknowledged bug is still listed and close it when not present.
Regarding sample projects, imagine you have 10 bug reports, 5 of which have example projects that reproduce the bug (or steps to reproduce it) and the other 5 don’t. As a developer, the most productive use of your time is going to be spent on those that have some way for you to reproduce the bug. Having said that, you might see a bug report title and think you actually have some idea about what’s going on, make a change and ask the user to verify that your change resolved the issue but that certainly the more rare resolution. In general, we can’t fix bugs we can’t reproduce. This is true for us just as it is true for you.
Like any software developer, we want to fix bugs that are negatively impacting users and we are looking for the most efficient ways to do that.
When I can’t reproduce a bug, I don’t even start a feedback. If someone does it, the reviewer must close it as “can’t reproduce”, but not leave there for an automation to close it without investigation.
No, that’s not the case. We know from past experience that it’s not uncommon for bugs to be fixed as the result of other work. Sometimes that other work is by us, by some library we use that has been updated or even by the OS.
So if a bug hasn’t had any activity in quite some time, we will ask if it’s still an issue. If it’s not, it can be closed. If it is, it will stay open.
2 Likes
Nor do I. Not just with Xojo but any product I use. Why? Because I know the odds of that report being useful are close to zero. Very rarely you might get lucky but few companies regardless of size have the extra resources to pay people to track down bugs that can’t be reproduced. If every bug with steps to reproduce or a sample project was fixed, then sure, spend time on ones that provide no such information but in large, complex applications, that’s rarely the situation one finds themselves in.
I remember reading long ago that the software that ran the space shuttle was considered to be bug free. That came at the cost of $25,000 per line.
If someone finds a bug, bit also find a work around , even if they report it they move on, and likely won’t bother confirming in teh future…
But other customers WILL trip over it and waste their time to figure out the issue in teh future or just get disillusioned with Xojo because of bugs…
And then there is the issue fo people who move on a has been metioned…
Bad policy IMO.
-Karen
2 Likes
We have bugs 10+ years floating around. That would be 20+ useless confirmations that at some point the users will fail or will give up on confirming.
3 Likes
Well the most efficient way is not “spending less time on it”, that depends on the context. Maybe you can use dedicated testing staff that only does testing (no developing to the ide or so) so these persons act more like customers. Communication is key here, but there is basicly (mostly) none other than “please provide a sample project”, and that’s it.
We as customers (even if we are developers) like to get support when we feel this is impacting us. I bet not many people actually put cases in Fb that are completely useless, as even registrating a case may be useful.
In general, we can’t fix bugs we can’t reproduce.
That doesn’t need to require the customer to reproduce it… On the Xojo side you can maybe try to better understand the issue, then reproduce it (or at least try).
Maybe cases can be “Archived” which are cases that could be brought back to attention if they happen again and “may” become reproducable… currently “reopen case” is never ever happening (as far as we know).
But first of all it would be a big step forward if we get a stable tool to report them in the first place.
1 Like