Just you in my opinion. You come across as overly aggressive and unable to actually provide examples of what the issues are when asked by Geoff.
You actually don’t speak for most of the user base but appear to think you do.
6 Likes
All very good suggestions.
This whole thread brought up some very good ideas but in the end there is only one way to fix this problem: Assigning more time for fixing bugs.
Even the best feedback system is worth nothing if there is not enough manpower to fix the bugs.
5 Likes
Just you in my opinion. You come across as overly aggressive
You are absolutely right, I will continue with the logical and diplomatic approach for only as long as it has a chance at being effective.
At some point talking to the brick walls in an echo chamber has got to give way to alternative methods at seeking remedy.
Demanding that I focus exclusively on my personal cases is an effort to straw man, when any dispassionate observer, many disgruntled customers, and virtually all independent reviewers clearly state that each release has been getting progressively more unstable, not delivering as advertised and removing previous functionality; is a time tested tactic of deflection. Eventually, you will get it, if you are intellectually honest. I apologize, but getting entrenched and vested interests to do whats right for all concerned is rarely clean and without fireworks.
Perhaps this is more civilized and logical:
Bottom line and like it or not, we are going to have a major and exclusive bugsweep if this product is to continue to be commercially viable and keep its reputation intact by bringing the product up to the standards that, they sold to us and that we all paid for
2 Likes
I would really like to see an announcement by Xojo Inc. of some improvements to come into implementation soon.
e.g.
for every release cycle, Xojo Inc. reviews top 100 list of bugs. This may include bugs inserted as features like case 36888, which could have been entered as a bug not handling UInt data types properly in variant.
Xojo Inc. picks 20 of those cases to be handled in the release. Not all may be finished, so aim for 10 to ship with fixed state.
Now Feedback points make sense, because a case getting a few points may not show in top 20 list, but may still get in the top 100 bug list.
And of course make the list of 20 picked items visible, e.g. as list in Feedback app. And later announce in blog, which 10 items made it as items reported by users.
3 Likes
We are always looking at the impact surface of any case. Fixing the bugs that impact the most users or implementing the features that impact the most users is very high on our list of criteria. That has always been true.
Listing items scheduled for a new release and later reporting on which got fixed would help to make the process more transparent.
Can we just get a “Snow Leopard” of Xojo?
No new buggy features.
Just fix the things.
11 Likes
We used to do that but users were disappointed when something that was scheduled didn’t make it into that release. We have learned the hard way to only list bugs once they are fixed and verified.
Please read again. Top 100 Bugs, so points on cases have an effect.
Then pick 20 and announce those are looked into. Then make sure in the 3 (?) month window for the cycle you get 10 at least done. Report which one made it into the release and which don’t.
The expectation is, that bugs can get into the top list and that some of them will get addresses on a regular (quarterly?) cycle.
3 Likes
Geoff said some things for future releases made good progress while r1 used so much time to finish. So I expect something new is ready for r2. Add a few new things for Web and a dozen older bugs fixed for compiler/desktop and we could be very happy.
1 Like
It looks like Norman has made a ticket to the effect my request. It’s top-20 already.
4 Likes
@Geoff_Perlman closing that ticket is unacceptable. You tell us to put points toward stuff to indicate what we want, and so we did. The ticket flew up the list in points. Users want it. You closed it so you could continue to deflect. Un-be-lievable.
The users are trying to speak: The product is embarrassingly broken and we’d rather have it fixed than have new half-implemented features. That’s all the ticket was about.
inb4 you deflect some more.
9 Likes
From the other thread, Geoff says
“The ranking is a big factor in helping us identify which cases are having the greatest impact. That a case is entered at all means someone is affected.”
I hadn’t even looked at my Top Case ranking in over a year.
Am I alone?
5 Likes
closing that ticket is unacceptable. You tell us to put points toward stuff to indicate what we want, and so we did. The ticket flew up the list in points. Users want it. You closed it so you could continue to deflect. Un-be-lievable.
The users are trying to speak: The product is embarrassingly broken and we’d rather have it fixed than have new half-implemented features. That’s all the ticket was about.
inb4 you deflect some more.
1 Like
Classic feedback, ask a load of questions then close the ticket. You literally couldn’t write this stuff.
6 Likes
“This case has been closed because we didn’t receive enough information.”
You literally ask us to put in nebulous requests that don’t involve specifics so you can “come up with the solutions” then you complain that we don’t specify things enough?
3 Likes
A case has to have a clear definition otherwise it would stay open forever. The case was not even close to clear enough. If we did two releases, each with say 100 bug fixes, I doubt everyone who voted for those cases would agree that the case could be closed especially if bugs they cared about were not among the cases fixed.
And what about support for the new Worker class we demonstrated? What about support for Apple Silicon? What about Android? Given that on average releases are 3 to 4 months apart, was everyone voting for those aware that they were asking for us to delay those features another 6 to 8 months? I doubt it.
Unbelievable.
Honestly @Geoff_Perlman, you are trying to get us paying customers to engage with you and help you improve your product so you can take more of our money and yet when we collectively enter a perfectly reasonable request into Feedback to have a release focussed solely on bug fixes you close the case? This case shot to the top 20 in under 3 hours.
Why should we bother anymore?
5 Likes
My top cases are there for several years, since they 1) have not been fixed yet, or 2) the feature is not completed. So those points stay there for a very long time, maybe once a year i’ll reorder them but critical bugs or features have not even showed any sign of a fix or implementation.
2 Likes
What about Android? Given that on average releases are 3 to 4 months apart, was everyone voting for those aware that they were asking for us to delay those features another 6 to 8 months? I doubt it.
Yes, i’m pretty sure that many here want precisely that.
Bugs in the CORE API must come first, above any new targets or other niceties.
Apple Silicon is on you, its literally in your mandate to keep up with that regardless and it should have been time budgeted.
WE NEED A MAJOR BUG SWEEP. FULL STOP.
LITERALLY, HAVE A BRAINSTORMING SESSION WITH ENGINEERING, GET SOME RED BULL AND GET ON IT. Its 20 years past due and cant be kicked down the road anymore. Set the helm to full stop, get out the collision mats, torches and steel plates… and start fixing the holes in the hull, the pumps can NOT hold much longer.
1 Like