Don’t be so pedantic - I was replying in a more general context. It feels like the only time our reports get attention is when we remind them that we submitted them.
1 Like
Well, I was going to let this play out without further involvement, but judging by your sophomoric ad hominem, its clear that my point was difficult to digest for some. (Now does my use of bold appear more appropriate to your standards?)
The issues I had with Linux threading, where actually overcome with a major effort on my part to build helper apps and a message passing interface. I did it and it worked. The issues of my highly optimized code being turned into sub par excrement by the changes in 2020r1 are yet to be explored as I am releasing with 2017r3 because it works.
I realize that English is not my primary, and that some people get complex information quicker using non verbal and visual means. Therefore, I have created this info-graphic detailing my view of the situation and my position, so that there will be greater clarity for those who are unable or unwilling to recognize them.
[Edit: Image removed]
My bugs, and the exhaustive required workarounds, my participation in the bug reporting ecosystem and my writing style have no bearing on the systemic issues that need to be recognized, addressed and corrected with the product and company if it is to be any use to its customers in the near term future.
I trust this will be enough to get my position across without further interaction.
Thank you for listening, and when this (and I) are purged (for whatever nonsensical reason needed to justify it) you will understand that valid criticism, in the attempt to actually get a stable release for everybody is not desired or permitted if it cuts too deep. One day you will hit a brick wall with Xojo, and only then you will understand.
1 Like
Image removed, Cowards.
1 Like
I am sorry that we have upset you. Please understand that this is our place of work and as such creating images degrading the hard work of the Xojo team is inappropriate. The Xojo team is extremely dedicated and hard-working and we want nothing more than to enable you to be successful with Xojo. That’s why Geoff started this thread - to help improve the process. But we are people too, we are not opposed to criticism but please don’t be disrespectful.
8 Likes
Yes, it is much easier to read and digest. Less is more. Thank you!
Awesome. I’ve done the same. And Xojo has a really cool concept coming to make helper apps automatically generated in the future. There’s a YouTube video Xojo released showing how it works. Check it out if you haven’t seen it.
Also great that 2017r3 still works for you. As for 2020r1, now we’re getting somewhere! Curious did you test 2019r3, or any other Xojo releases since 2017 to see when the issue started?
Unfotunately, that’s not proven to be true - the WebFileUploader saga is a case in point (still not fixed, by the way, 6 years after it was first reported!)
You weren’t asking me, but I can say with authority from experience what happens: sometimes it gets fixed, and sometimes… nothing. 61536, 61544, 60181 is a set (two mine, one somone else’s) which I’ve begged for help with.
The cases are marked Reproducible and then… nothing happens.
Part of the problem may be communication? Maybe these cases are next on the internal “to do” list and we just dont’ know it?
But without any feedback, I had to get my app shipping, so I:
- stopped using WebContainers
- put in tons of special-case javascript code to try to work around the bugs.
My WebApp is online, and functional, but it’s ugly (the entire screen flashes and refreshes whenever any content updates).
To make this relevant: maybe the Feedback system neesd more feedback in the other direction?
Imagine this:
"Congratulations, 50 of your points have been used to buy bugfix 12345, which is now in the queue. You can reallocate these 50 points however you wish. "
2 Likes
Ahh, found the exact section (“Threads”) within the Xojo 2020 vid here: https://youtu.be/oi5MCrDlpsg?t=1087
1 Like
He never reached out to us. I can understand reaching out over and over but never hearing back and finally giving up but never reaching out in the first place, I can’t.
That’s a good idea.
2 Likes
That’s slightly different than what I was proposing: I’m proposing we get the notification when the fix has been scheduled rather than when it’s been fixed.
Knowing “this is still broken, and hasn’t been fixed yet, but is going to be worked on soon” would be really valuable to me.
2 Likes
I see. But you wouldn’t be able to reallocate the points until it was fixed and verified. Because until then, we don’t know it will be fixed. One of the reasons we don’t want to notified users when we start working on a case is that the case might not get fixed then or it might take a long time. We feel it’s better to let the user know when it’s been fixed and verified. Then we know that it’s done and will be in the next release.
I agree. I was about to suggest something similar, or at least some sort of indication of its internal rank or status beyond “reviewed” or “reproducible”. Such as an “assigned triage level” to let the reporter know where it stands among everything. However that may be revealing too much. Just something to let reporters understand that we’re all in the “Emergency Room” together, but a broken arm has to wait a bit longer than a heart attack.
I think that’s somewhat “web 1.0” thinking, to be honest.
Is Xojo worried that a user will be angry or frustrated if a case is scheduled to be fixed, but never gets fixed? Sure, that will happen sometimes, but the impact can be reduced with good expectation setting.
The current feedback system is already leading to tons of angry and frustrated customers due to the lack of information.
Why not do a trial run and see?
We’ve talked about a status of “investigating” which means we are now looking into it. It of course could stay in that state for a while. We have some cases that we don’t want to close but can’t reproduce either and are waiting hoping more helpful information will emerge.
What you are describing is how it once was and yes people were frustrated because they would expect that once something was scheduled, it would show up as fixed in the next release. We have learned the hard way that it’s best to underpromise and overdeliver when possible.
2 Likes
How about something like “assigned?”
Other tool suppliers are indicating the release considered for handling specific bugs (and feature requests). Re-scheduling can always happen. Developers get an indication but no promise.
We have that as well. But again just because a case is assigned doesn’t mean the engineer has started working on it or if they have, when it will be done. We’d rather report once it not even when it is fixed/implemented but when testing has verified that it is fixed/implemented.
Some do but not all of our users are experienced developers who have been through this with another tool. That’s why we prefer not to say anything until either we need more information or are certain the issue is resolved.
Can we talk about the whole Web Feedback system too? I hope that it doesn’t become a mini-forum and anyone can hijack the reported case. Maybe allow the original poster to approve other users’ comments on the feedback case they created?
How about closing a case? I think it could be a good idea to let the original case creator close the case. No need to wait for someone else to close their case.
How about clear rules for the feedback web app? Until recently I didn’t know that there are other metrics Xojo use to consider feedback cases (besides points), like how many people added the case to their favorites and subscribed to the case by using:
If Xojo reviews the points assigned, the number of people that added the case as favorite, the number of people that subscribe to a case to evaluate if that bug is important for a considerable number, then that must be clear.
I have seen several people creating good reports and offering help on other cases that may not be bugs. How about giving a few additional points or case priority to them? Some people are able to find bugs more easily and document them correctly. Taking notice of their cases will allow them to feel that their effort is being considered and appreciated, instead of feeling that Xojo is not paying attention by staying in ‘Needs Review’
Closing cases: I have seen several of my cases being closed because I didn’t make myself clear and my problem was misunderstood. How about not closing the case and ask the person that reported it to give more information before closing a case? For example, one of my cases was closed, then I contacted Javier and talked with him about the case, he was not able to reproduce the problem either, after some interaction the problem didn’t show with Safari browser and only with Chrome. There is another case that was closed recently because the staff saved the project using Xojo project or XML format and the problem is present only if the project is saved as Binary.
Ask for reopening cases: only on rare occasions, a case is reopened. If this feature is problematic for the staff put in the rules that we must open a new case with new information and not request to open a closed case.
Allow feedback users to change the visibility of their case and change it from pre-release to release if the case still presents the bug on the release version. Some cases that can only be seen by pre-release testers contain workarounds that may be helpful to people that are not testers.
Keep internal records to avoid cases to stay in ‘Need Review’ for a long time. You should not have cases in ‘Need Review’ for months, take a look at case <https://xojo.com/issue/59827> it was reported in April and still ‘Needs Review’ there is a forum post here. I understand that the Xojo users using Chinese or Japanese configurations are low and the problem may be hard to fix, but at least someone from the staff should be able to reproduce the problem and change the status. In the new web feedback system, a ‘workaround’ note could be displayed as to use English (in this case) but the status should be ‘Reproducible’ at least. Also, give information as to what we should do if our case stays in ‘Needs Review’ for more than X time (days/weeks).
That’s it for now. I hope this helps to create a better system and keep improving Xojo.
2 Likes