Was thinking today (always a scary thing) that Feedback doesn’t give us the ability to allocate points fairly. Let me explain.
We get a number of points based on our license level. I’m a Pro license holder so I have certain number of points I can allocate to only 5 Feedback items. Hell, I have 5 items in my list that I consider a top priority for desktop, 5 top priority for Web, and few for Console, and a lot I’d allocate for iOS. In the current system there’s no way that I can do that. It seems unfair to ask me to pick just 5 for all 4 targets.
I was thinking it would be nice to be able to get a top five allocation for each target type. They’re already tracking our points based on our License type so I don’t think this would be a huge change to able to allocate points for each of the targets our license supports.
The advantage is that those of us that work on each platform can give feedback on what’s important to us for each target. Now, I tend to put only those items that are the biggest pain points on my top 5 list. This means these are not necessarily the most useful or best ideas I want integrated into the product. It’s such a high level that some really cool ideas, or important bugs, get zero points because points are so precious.
Anyway, I’m rambling a bit. I created a Feedback Request for this <https://xojo.com/issue/37501> Sign on if you want.
[quote=154874:@Norman Palardy]Making choices is what the top 5 is all about
What are the absolutely most important things overall to you[/quote]
As someone who spends equal amounts of time doing web and desktop apps I have a top 5 (at least) in each category. My current ranking reflects what I want now. But then next month when I’m doing something different it will change based on the current pain points.
I don’t see how that helps Xojo out - at all - given the release schedule is much slower than my pain points schedule.
Well, you do mark it as either bug report or feature request so I guess it is, technically, a separate list. Assigning points to outright bugs is BS as they should be fixed regardless of points. The point system is much better for feature requests - not bugs.
Like many other, 5 isn’t enough, especially when the ones in my top five haven’t been resolved yet. I made a feedback case some times asking for 10 top cases.
I agree that 5 isn’t enough. Feedback kind of makes sense in that it lets Xojo know the real pain points for a lot of developers but I think the real issue is that not enough people use their points to push features or bug fixes. If that doesn’t change more votes won’t make things better.
A large enough voting block could push bug fixes and features to the top of the list.
The assumption is that feedback points are relevant to Xojo management and that developers are tasked accordingly. I’m not sure that’s the predominant case. I suspect that a ton of bugs are fixed because someone has delved into the code for one reason, and had a eureka moment on something else in that code (aka “Oh, shit, that can’t be right”).
Some modules have bugs or flaws that languish for years. Other modules, especially recent ones, seems to have a triage team working full time on them. I don’t think feedback points have any effect on those situations.
Without knowing what weight feedback points really have in determining outcomes, they’re as valid as Zeller’s bonus points. Here’s a million, don’t spend them all at once.
Well, this came out sounding more cynical than I meant it to be. As a counterpoint, thanks Xojo Team for all your hard work, and a Merry Christmas to you all.
[quote=154961:@Tanner Lee]Some modules have bugs or flaws that languish for years. Other modules, especially recent ones, seems to have a triage team working full time on them. I don’t think feedback points have any effect on those situations.
[/quote]
I can speak directly to IDE bugs since that is my primary focus.
Ones from old IDE’s are unlikely to persist especially when they relate to behavior of certain components.
So they may sit until I find a spare moment (HA !) to review them and either confirm they still exist OR close them as no longer reproducible.
There are some however that relate to things that have not changed from versions (file io, project model etc) that may have persisted for some time.
My personal favorite is #3624
From what I’ve seen you’re the master tap dancer at Xojo. Hope you’re not bug-fixing over Christmas
I develop on OSX but primarily for Win desktop vertical apps. Sometimes I get discouraged thinking about all that Xojo’s got on their plate. I mean, the Windows controls need some serious love for one thing. But you guys have set so many high targets. I hope you can achieve them all.
Anyway, I’m off-topic about Bob’s thread about Feedback points. Sorry Bob. Signing off.
The recent example of iOS is a brilliant demonstration at the relative weight of top cases. <https://xojo.com/issue/9433> dates back to 2008 and although I cannot remember it’s placement in these old years, it has been steadily in the top five even before Geoff showed a demo. If the top 5 had been kind of automatic, we would have had iOS a long time ago.
I have myself had customers placing requests. I made sure to thank them for their suggestions, promised to keep them posted, then went on my daily chore until I sat down for a new version, and eventually implemented that, or not. I tend to regard FR as suggestions more than a contractual obligation. It is nice that Xojo has an ongoing poll to see what is most desired by it’s users. But it would make no sense to consider it a must.
In that perspective, 5, 10 or 25 slots in my top cases makes no difference. Furthermore, priorities are all about making choices. If I have five top cases for each platform, then I pick the top one for each and I have my 5 cases…
[quote=154961:@Tanner Lee]The assumption is that feedback points are relevant to Xojo management and that developers are tasked accordingly. I’m not sure that’s the predominant case. I suspect that a ton of bugs are fixed because someone has delved into the code for one reason, and had a eureka moment on something else in that code (aka “Oh, shit, that can’t be right”).
Some modules have bugs or flaws that languish for years. Other modules, especially recent ones, seems to have a triage team working full time on them. I don’t think feedback points have any effect on those situations.
Without knowing what weight feedback points really have in determining outcomes, they’re as valid as Zeller’s bonus points. Here’s a million, don’t spend them all at once…[/quote]
We use Feedback ranking as one metric of many to help figure out what gets fixed or implemented next. As you said, sometimes its just that we happen to be in that code, looking at something else. If we’re going to take the time to (re)familiarize ourselves with a particular section of code, you might as well fix as much as you can while we’re there. Sometimes it’s just the next thing to do in a long term plan.
