Recently an MVP brought up that they don’t like the policy of automatically closing Issues when there is no action for 2 years; they explained that if a case was verified it should stay open. All of the other MVPs agreed and threw out possible solutions, which led to a productive discussion. The ideal solution was that Xojo would re-verify the case and close it if it is no longer relevant. We continued evaluating the matter internally and going forward – at the suggestion of the MVPs – cases will no longer auto-close. Instead they will get the “Needs Review” label, we will review them and close them if they are no longer reproducible.

We appreciate the time everyone puts in to let us know if they encounter issues in Xojo, this helps us continue to improve Xojo. If you ever have anything you want to discuss or offer feedback on please reach out to any of us, including the Xojo staff or the MVPs, via PM on the Xojo Forum.

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

The Xojo MVPs give us regular feedback on issues affecting the community at large – sometimes that is about a new feature, early testing of a release or more general matters. Recently the MVPs emphasized to us that bugs that don’t affect a lot of users, but can be really annoying to a small group of users, don’t get much attention. We talked about how to best address some of these issues and since we haven’t done a Bug Bash in a while, we decided it was time to do one.

Nominating a Bug for the Bug Bash

Starting now, each user can nominate up to 10 bugs to be fixed during the Bug Bash. You don’t have to nominate them all at once, we will accept nominations through August 31st. To nominate a bug, post this exact language as a comment on the case(s) you wish to nominate in Issues: [BugBash2022Nominee]. Starting in August, our system will add a Bug Bash label to make it easy to find them.

If you find that a case is already nominated with the Bug Bash label, do not add it again. Per usual, if the case affects you, add a “thumbs up” so we have some idea of how many users are affected by a particular bug. Please note that Feature Requests will not be considered for the Bug Bash.

Not every case that is nominated will be fixed. There are a multitude of reasons for this, but each case nominated will be evaluated and we’ll let you know the outcome.

We hope you’ll participate in the Bug Bash. No case is too old, too small or too esoteric! Submit your nominations today!

1. Web-based Feedback: We have been developing a web-based version of Feedback for some time now. It’s been delayed mostly due to other priorities taking precedence. Nevertheless progress on it continues. We expect it to be available this coming year.
2. Because several case statuses are misunderstood, we are simplifying them. The bottom line is that a case is open until it’s not. Changes in status don’t really mean anything as a case could get resolved the day it was submitted or get stalled for months because we can’t reproduce it. Thus new cases will have the status of Open until we need more information from you (in rare cases) or they are closed. The closed statuses (fixed, implemented, etc.) will remain as they were before.
3. Sometimes cases stagnate with little progress. In the case of bugs, this is often because we can’t reproduce them or we don’t have the information we need. These cases impede all of our efforts to search Feedback. Sometime next year we intend to update the system such that when a case has had no activity in two years, the system will automatically change the status of the case to Archived. If you find an Archived case that is still important to you, please request that we reopen it.

We believe these changes will improve our communication with you about feature requests and bug reports. I know that change can be frustrating. Just know that the reasoning is always to improve. If a change doesn’t ultimately accomplish that, or if we find a better solution, we will consider implementing it. To all of you that use Feedback, we greatly appreciate your efforts. You are helping to contribute to making Xojo better for the entire community.

The Impact Surface is the benefit in our cost-benefit analysis. The more users affected by a bug or feature and the more enabling or disabling the case may be, the greater the impact surface. The greater the impact surface, the more likely the case will be addressed sooner rather than later. Even in the instance where the impact surface is large, some issues can be resolved quickly while others may take a long time. A typo in a dialog box can be fixed in seconds. Supporting an entirely new platform takes longer.

Requests from Users – Issues is the system we provide to users to make feature requests and report bugs. With Issues users can specify which issues are most important to them and which are not, be they bugs or feature requests. We can then see which issues have the highest priority from users that have take the time to indicate their priorities. While this is only one criterion, it’s an important one because it helps us determine the impact surface of any issue.

We sometimes get contacted by users asking why an issue that was reported and then verified (or reviewed in the case of a feature request) by our team long ago has not yet been fixed or implemented. This goes back to the impact surface. Issues with a large impact surface will typically be handled before those with a small one. Many (but not all) of the open bug reports in Issues only impact a small number of users (and many just a single user) so we focus our attention first on those that impact the most. The age of an issue is not a criterion for resolving an issue. The impact surface (with the exceptions noted below), is what matters.

It’s important to note that development tools will always have far more open bug reports than most other software. Why is this? Because development tools generally have such a large number of APIs that the total possible interactions can’t be calculated. In a small, very focused app, the total number of interactions are few by comparison making them easier to thoroughly test. Every large development tool, even those from teams that are orders of magnitude larger than Xojo’s team, have thousands and thousands of open bug reports. Reviewing Microsoft’s bug base for cases regarding Visual Studio is a good comparison. In terms of ratios (open vs. closed reports), we are similar but with a team and budget several orders of magnitude smaller. That there are thousands of open reports doesn’t mean Visual Studio and Xojo are not powerful and useful. Most of those cases are almost certainly at the fringes and thus do not affect many people.

Our Ideas – As you can imagine, we think about Xojo all the time and we use it all the time as well. Much of the code we write is in Xojo. While the Xojo IDE is written in Xojo, many of our internal systems are written in Xojo as well. Sometimes we come up with ideas that users have never thought to ask for. For example, at the time we added the ability to create web applications, no user had ever asked for that ability. And yet today a large portion of Xojo users build web applications.

Show-stopping Bugs – Occasionally a user contacts us about a bug that is preventing them from deploying their app to their users. It may not be impacting many other users, but it’s having a major impact on them. We will typically first see if there’s an immediate workaround and then determine if a fix makes sense. I say that because sometimes the workaround is easy and the fix is incredibly difficult. All of these factors have to be considered.

Sometimes a bug is reported by just a single user and yet we can tell the bug will impact a large number of users so we don’t wait to address it.

Bugs that Bug Us – As we develop much of Xojo in Xojo, we run into bugs ourselves and fortunately are in the unique position to fix them at that point. This is one of the benefits to writing much of Xojo in Xojo.

Xojo Pro Plus User Issues – Pro Plus users pay more to be able to get their issues resolved sooner. It’s an extra level of support – for example, perhaps there’s a bug that is normally not one we would prioritize because it doesn’t impact many users or you need help tracking down an issue in your code. Xojo Pro Plus users will be given priority.

Sponsored Development – Occasionally we get requests for features that while certainly worthy of addition to Xojo, don’t have enough impact for us to prioritize them at the moment. The user requesting said feature can sponsor the development of that feature which pays for the opportunity cost to us of doing it now as we will not be working on something that the far more users are requesting. Two examples that immediately leap to mind are support for Security-Enhanced Linux and most recently, the ability to store and load compiled XojoScript.

Shouldn’t Xojo Be Bug-Free? In the ideal world, yes. In reality, the cost of attempting to get the bug count down to or even close to zero goes up exponentially with the size of the project. For example, the software that ran the space shuttle was 420,000 lines of code and supposedly had just one bug in any particular version. As one of the programmer’s said, “If the software isn’t perfect, some of the people we go to meetings with might die.” That level of reliability doesn’t come cheap. NASA projected that the software would cost $20 million but ended up spending $200 million. Given that the source code to Xojo is far larger than that of the space shuttle, the cost of making it bug-free would also be higher.

Looking at the top 100 issues in Xojo is also illuminating. 80% of them are feature requests. Only 10 of the top 50 are bugs, only two of which make the top 10. As a result, we spend a lot of time on new features but that doesn’t mean bug fixes aren’t a priority.

Bugs Fixes – We fix hundreds of bugs every year. The bug fixes counted in each Xojo release are all bugs that existed in the previous released version. For example when Xojo 2020r1 says it includes 161 bug fixes, that number doesn’t include bugs that were introduced in 2020r1.

The Roadmap – We plan out about 18 months in advance for the bigger new features that will appear in Xojo in future releases. We outline these on our Roadmap. It’s important to recognize that our engineering team is quite diverse and as a result we are generally working on many different features at any given time, some that will ship soon and others that may be many months down the road. And of course in every release we fix lots of bugs.

In Conclusion – The Xojo team is a very dedicated and hardworking group of people and we care about the issues you care about. The whole point of Issues is to guide us in finding a way to prioritize and balance everyones’ needs and desires. Through our 20+ years, we’ve tried multiple ways of managing this process. What this boils down to is we very much appreciate all the assistance of the community and our testers who help us make Xojo the growing success it is, and we’ll continue to use Issues and the guidelines above to evaluate your bug reports and feature requests. We want you to know if you have reported a bug or need a workaround for an issue, Xojo wants to help you find a solution so reach out to us via Issues, or email our support team, or on the Forums.

We’ve talked about the importance and the value of good bug reports before:
Great Bug Reports
Feedback Tips
The Importance of Feedback
Or try this Google search: writing good bug reports

It can never be stressed enough that a good bug report is the BEST way to see that your particular bug gets reviewed and action is taken sooner rather than later. Here are a few facts that you should always include in your bug reports:

What kind of project?
There can be bugs that affect only web projects, desktop projects or console projects. Each kind of project utilizes different classes in the IDE, so it’s possible that a bug that occurs in a desktop project may not occur in a web project and vice versa.

Which alpha/beta/release are you using?
If you’re like a lot of people, you have a few versions installed. When you hit a bug it’s pretty important we know which version you were using when you encountered the issue.

What OS/platform?
We work really hard to avoid major differences in Xojo between OS X, Windows and Linux, but it happens. And it is possible a bug that occurs on Linux may not occur on Windows or OS X. It’s important we know what OS and version of that OS you’re using when you encounter your problem.

These first three should really be considered required bits of information for any bug report. Here are a few more tips to make your bug report even stronger:

Did you include steps to reproduce the problem?
If your bug report comes with reproducible steps, the likelihood your bug can and will get fixed goes way up. It’s not a guarantee but it certainly helps us find and isolate what is causing the bug.

Did you include a sample that shows the bug?
This isn’t always possible, but when it is we really appreciate it. Just like writing clear step by step instructions on how to reproduce the bug, this gives us a reproducible way to see it in action, making it much easier to debug and find the problem. When all else fails you can record a video of the steps you take to experience the bug. In some cases crucial details can be easily pointed out in the steps you took to reproduce the issue for the video.

Remember, strong bug reports result in bugs getting identified and fixed faster.