The system brings a lot of improvements and more visibility, but there are some changes. Some users have asked “how do I find the bugs I have reported” or “how do I search for an issue number” and if you haven’t used this system, those may not be obvious.

Here are some tips for using Issues:

When do I use Issues?

Use Issues to let us know you have a bug or feature request for Xojo, the Xojo documentation, our website, or an example project. Discussing these things on the forum can be helpful but in order to officially let us know about a problem, please create a new issue.

For Customer Support, please contact us via email at hello@xojo.com. Contact Customer Support for general questions about licensing, questions about your account, technical support, etc. If you’re not sure, write us, we are here to help and usually respond very quickly.

How do I search for a specific issue?

If you are trying to find an issue by the issue number make sure you put “#” before it. For example, if you’re looking for issue 69360, make sure to type it in the search bar like this:

If you forget to type in the #, your search will not return any results.

To link to a specific issue, use https://www.xojo.com/issue/<issuenumber>.

How do I create an issue?

Click “New Issue” to create an issue. When you start typing in the title field, you’ll see a list of possible matches populate as you are typing which is helpful to see if your issue already exists.

How do I find the issues I have created?

There are many options for searching. If you click inside the search field, you’ll see a pop-up menu with criteria you can choose from like Author, Label, My-Reaction, etc.

To find the issues you created, perform this search using the popup menu: Author = [Your Username]. For example, the search below will find the issues I have created.

You can search for your issues or those created by other users. Keep in mind that Issues uses the same username as the Xojo Forum.

What do I do if my issue already exists?

If you are searching for a problem that you’re experiencing and find that an issue already exists, please add a thumbs up. If you have additional information, you can add a comment by scrolling to the bottom of the issue.

If your information should be kept private please check the checkbox at the bottom: This note should only be visible to Xojo.

How do I bring more attention to an issue?

If there’s an issue you feel needs more attention than others, you can click the thumbs up button to upvote it. Conversely, if you feel there’s an issue that should get less attention, you can downvote it.

Be aware that the more you upvote issues, the less your votes matter. The same is true of downvoting issues though upvoting and downvoting have independent impact. In other words, upvoting several issues doesn’t change the impact you have when you downvote issues and vice-versa.

How do I find the issues I have added a to?

To see what issues you have added a to, search for: My-Reaction = 👍

How do I see the top feature requests from users?

You can search by Popularity using the dropdown menu to the right of the search field to sort your results. It is important to remember that the Popularity list is not our Roadmap.

Note: If you do a search that you like, add a Bookmark to quickly go back to it in the future.

How do I view my recent searches?

Click the icon to the left of the search bar to see a list of your recent searches:

How do I reopen a closed issue?

If you are the original author of an issue you can close and re-open it yourself. You do not have to ask Xojo to do it. If you are not the author and want to re-open it, just leave a comment on the issue to let us know that it still affects you and you’d like it re-opened. Then either Xojo or the original author will re-open it for you.

Does Milestone mean a feature will be coming in that specific milestone?

Just because something has a Milestone listed, that is not a guarantee that it will be fixed or added in that milestone. It means that it is an issue we are considering for that release.

If you want to read more about issues, check out this page in the documentation. Do you have other tips for using Issues? Please share on the Xojo Forum.

Lots of big projects (both open and closed source) use it for that purpose. We found it has some really great features. For example, they have simplified the process of entering a new case which almost certainly leads to more people using it. The author of a case can close it themselves and then later reopen it without having to ask someone to do so. You can upvote or downvote any case. I could go on and on. That it’s so full-featured and well-thought out is actually unsurprising upon reflection since that’s Gitlab’s business. Naturally we wanted to have all of those features in our own bug/feature tracking system, Feedback. 

Over time that list grew and grew. We decided that some testing of Issues was in order so I wrote an app (in Xojo of course) to transfer all of the data from Feedback into Issues. There are just over 59,000 cases (since Feedback began more than a decade ago) and as you can imagine, transferring all the data along with all the attached files, was a long process. It took nearly a week running almost non-stop 24/7. The API they provide is extensive and allowed me to represent in Issues every case as it was in Feedback. Having all the cases in Issues helped us to see how well it really works.

After much research, test usage and consideration, maintaining bug base software is not the business we are in. While we are disappointed that our nearly complete web-based version is not what we will be using, we are confident that using Issues instead makes more sense. We are in the business of providing Xojo and anything we can do to devote more resources to that, is an improvement. In this case, a system that already does everything we want and more and is being maintained by others out-weighs having one written in Xojo. We already have hundreds of example projects, a great web-based example (Eddie’s Electronics which we will continue to improve), the Xojo Showcase, the Xojo Cloud control panel as well as many internal web apps, all of which are written in Xojo. The development of each of those has resulted in many improvements to the Xojo Web Framework and will continue to do so in the future. Many of you have created even larger and more sophisticated web apps in Xojo such that we have no shortage of feedback from you on how it can be improved. We continue to be grateful for that. We also develop the Xojo IDE and much of the frameworks in Xojo as well. The engineers at Xojo spend more time in Xojo every day than in anything else.

Our migration to Issues is now complete, so launching the Feedback app or clicking on Feedback in the Xojo toolbar will take you to the new Issues system. You will find all of your cases there and you will be notified when they change. You can begin using the new system to look for existing issues, up or down vote them, add new comments, files, create new issues, etc. It’s also very well-designed to promote conversation about an issue. I think you will find it to be easier to use and at the same time more powerful than Feedback. We have implemented single-sign on so you will be automatically logged in using your Xojo credentials. All of the Feedback case links on the forum are being updated to point to the same case but in Issues. 

Issues is far more transparent than Feedback. The benefit to you is that you’ll see more information about each issue. You can see how many issues have been created. You can see to which member of the Xojo team an issue is assigned. You can see which Xojo release (milestone) it’s assigned to as well. Remember that this is only a best guess. When it comes time to begin pre-release testing, if an issue is not yet closed, it likely will be moved to a later release.

We have always strived to be quite open with the community. While change always comes with some cost, we are convinced that this one is in the long-term best interests of the Xojo community and that in the end is what drives us to do what we do.

What We Do

Xojo’s MVP page spells it out pretty well. We try to facilitate communication between Xojo the company and Xojo the community, and we advise Xojo on new features that will be coming to the language. Sometimes that’s a lot of work, sometimes not.

Facilitate Communication

Personally, I hear from a fair few members of the community about concerns they have. I spend time with these users and try to determine what they need that they aren’t getting, or how Xojo might take steps to ease whatever suffering the user is experiencing. I then distill that down, hopefully into a paragraph or two, and discuss it with the Xojo team. There are a few different ways I handle that information:

• By opening a Feedback Case — if it’s a bug or feature request, this is usually the best way forward
• By messaging an engineer to clarify how something is supposed to function — knowing which team member(s) generally work on which part(s) of Xojo, I can usually get a quick answer when there’s a question like this by sending them a direct real-time message
• By forwarding the concern on to Geoff Perlman, Dana Brown, or Alyssa Foley — when it’s major, having direct access is great
• Or by posting it in our MVP chat channel — when there’s some finer points to work out, this can be incredibly helpful as all of us MVPs are long-time users, and there are a few members of the Xojo staff constantly monitoring this as well

I’m sure I get on their nerves sometimes with all of my questions, originating both from other users and myself, but it’s a decent system that lets me help out both the company and my fellow users.

In many cases, we’ll take a forum discussion and open the topic in our MVP channel to see if there’s some way we can help or Xojo can improve. We’ve had some very long and drawn-out conversations based on forums posts.

Informal Advisory Committee

Sometimes we get to see new things before they hit the public Testers group. We tested Web 2.0 for a while, Worker, and a bunch of other features. Some things we get to see long before they’re ready to roll out in any meaningful capacity. We have video calls every once in a while where Xojo presents the early stages of new features and asks for our input. We can make suggestions for changes that might make that new feature better, or help to alter the course of a new feature simply by asking the right questions that lead to the right realizations.

For a couple of examples: Workers were added as a Desktop (rather than Pro-only) feature after much discussion in the MVP group, and we’ve been talking over details of the forthcoming Web Feedback status messages and abilities.

This is an important task, and even though things aren’t released bug-free, we help Xojo understand and account for many things they might not have otherwise considered simply by providing our point of view early in the process.

What We Don’t Do

There’s a lot that we don’t do, and maybe some things we probably should do, but we do what we can with the best intentions for Xojo’s users. We represent you, the user, not Xojo in this capacity.

Be Self-Serving

It’s tempting to harass the engineers or Geoff for a particular new feature or bug fix that would help my business, but what would that really accomplish? In the end, I probably wouldn’t be an MVP for very long, and I’d feel pretty cheap to leverage my position this way.

Be Single-Minded

As a representative of the community, I try to see multiple angles for any situation. I know that I have very different experiences and projects than others, so I try to put myself in the shoes of other users when we’re discussing. It’s not always easy — and it’s not always fruitful — but it’s what I feel is incumbent upon me to do.

Be Confrontational

I get heated about things Xojo is doing at times, just like anyone else, but I certainly endeavor to keep my cool (yeah, Geoff, I know…trying also means failing occasionally). I try to offer alternatives and constructive criticism, as do my fellow MVPs. We often come up with good stuff that users don’t realize would otherwise be missing or point out things that I’m sure Xojo would rather we didn’t. don’t think for a second that we just pat them on the back and say “good job” in our private discussion venues.

Ignore the Big Stuff

If Xojo is working on something major and they’re giving us a chance to see it first, you can bet we’re all-hands-on-deck. Web 2.0 and Android, being the biggest new features released since the inception of the MVP program, pulled us all in for days or weeks on end. Testing, offering ideas, opening Feedback Cases, you name it. We try to help Xojo get it as close to right as they can, within reason and the allotted timeframe, before the Testers get their hands on these builds.

Get Paid

We’re not Xojo employees. We don’t get paid for doing this. I know some of you are thinking “Then why would you do it?!” and the answer to that is “Because we’re morons!” Seriously, though, we see a way to help Xojo and its users, and that’s enticing enough.

What it’s Like

It’s fun most of the time. I get along well with most of the Xojo team and the other MVPs, and I like discussing and testing new stuff with them. They’re a good bunch of folks, and I’m thankful to be part of the program. There’s a massive amount of knowledge and capability in a room filled with these people.

Users who contact me as an MVP are generally thankful when I can help them, either with my own knowledge or by passing along their concerns. I get thank you notes every once in a while, and it feels good to be doing something to help out.

But not everyone is thankful. There are those who deride the program and its members, send their diatribes via email and private message, or feel obliged to call us out publicly. These are people who have no idea what we do for them and Xojo — NDAs, anyone? — and they’re just looking for a reason to tear us down. I can say for certain that Xojo would look different than it does today without the presence of the MVP program. Knowing that some people want to vilify you when you’re trying to help them requires a thick skin, but it comes with the territory.

In the end, I try to do right by Xojo users, and I’m positive my fellow MVPs feel the same way. It’s not about us, it’s about you.

Thanks for reading!

Anthony G. Cyphers is the Lead Developer and Sole Proprietor of GraffitiSuite Solutions and a Xojo MVP. He has been providing custom Xojo components and contract development since 2003.

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.

There are numerous ways to communicate with Xojo, so here’s how to reach us:

Customer Service

If you have a question and aren’t sure where it should go – reach out to our friendly Customer Service team at hello@xojo.com. We guarantee a response within 48 hours but it’s usually much, much faster. We understand that the issues you’re running into are important to you – often even time-sensitive (we’ve been there!), so we strive to get you the answer you need as fast as we can.

Submit a Case

Got a bug or feature request? Please submit a case for it in our Feedback app (make sure you have the latest version), this is our feedback tracking system for Xojo. Creating a case is easy – first search to see if your issue already exists. If it does, you can Subscribe to the case for updates. If not, create your own case – be as specific as possible, enter steps to reproduce and include an example project if you can.

Technical Support

Desktop, iOS, Web, Pro and Pro Plus licenses all come with Tech Support. You can fill out our contact form to get in touch with Tech Support and you’ll hear back ASAP. The more specific you are in the initial message (include Feedback case numbers if you can), the faster you’ll be able to get a resolution. If you encounter a show-stopping bug that you are not able to work around, you should contact Tech Support for help.

The Forum

The Xojo Forum is a great resource that is frequented by Xojo users, you’ll get an answer pretty quickly. You might also make a friend or two! Bonus – members of the Xojo Team stop by to help out when possible! It’s good to search first, as many questions have previously been answered.

We want to help you be successful with Xojo. Each of us strive to be accessible and Xojo offers multiple venues for support and questions. And if you want to say hi, stop by a Xojo Hangout*, tweet us, join our Facebook page or subscribe to our YouTube channel.

*Xojo Hangouts are community social Zoom video meetups which are currently held every Tuesday at 2PM ET and Friday at 4PM ET. Hangouts are attended by a number of Xojo staff (Geoff’s usually there!) as well as a fun group of users from around the world. Details to join are posted the day-of at the top of the Xojo forum.

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.

With Apple’s announcements at WWDC 2018 and the introduction of dark mode it was time to revisit our graphics and the overall appearance of the IDE again. Here are some things which contribute to the changes that have been made and ones that you will see in the coming months.

Dropping macOS 10.9

Xojo 2018r3 drops support for macOS 10.9 and as the last version which had the skeuomorphic design elements all of our supported OS’s now have the flatter modern design. It’s not that this has held anything up per se, but it’s a good reminder that “it’s time”. 

To that end, we have taken that opportunity to remove some of the graphics that make the IDE look out of place and doing so subtly lowers the memory footprint and accelerates drawing of the IDE itself across all platforms. We’re also using a variation of Apple’s image templates which has somewhat reduced the on-disk footprint of the IDE itself.

macOS Dark Mode

Apple’s addition of a darker variant of the visual “Aqua” theme in macOS means that we needed to do an audit and update of several of our base framework controls so that your apps would render correctly as well as ours. 

Events

While it probably won’t be used very often (how often does one change themes while running a piece of software, besides the novelty of seeing it happen), we added an event to the App class named AppearanceChanged to notify you when the user changes from light to dark or changes their accent color. This is a good place to clear any graphic or color caches which contain theme specific UI graphics. 

Methods

There is also a new global method called IsDarkMode(Boolean) which will return True if your app is running with the Dark Mode theme on macOS 10.14 or higher. If your app is running on 10.13 or lower or in light mode on 10.14, IsDarkMode will return False.

Build Settings

Enabling Dark Mode in your apps is as easy as flipping a switch in the Shared Build Settings. Unfortunately, because Apple made the assumption that most apps would “just work” versions of your apps compiled with older versions of Xojo will either need to be recompiled with Xojo 2018r3 or you’ll need to push out a new version with a plist entry to prevent macOS 10.14 from showing your app dark in Dark Mode. 

Testing

When testing apps for use with Mojave’s dark mode, I seriously suggest that you test on a system that allows you to see the translucency effects of dark mode. Virtual Machines are usually really handy for testing, but in this case, Parallels Desktop 14, VirtualBox 5.2 and VMWare Fusion 11 do not show the subtleties of dark mode.

Colors

One of our goals at Xojo is to remove some of the headaches involved with the minutiae of each OS that you deploy for and to that end, we wanted to make drawing custom controls easier too. What this means is that the built-in global colors are largely theme aware now and will change depending on whether your app is running in light or dark mode on macOS. This affects things like TextColor, FillColor, FrameColor, HighlightColor, etc, so if you use those methods when drawing in pictures and canvases, you will want to audit that code. If you want a specific color, you should use a color constant. For instance, use &c000000 if you want black because TextColor will now return white in Dark Mode. 

In terms of the framework controls themselves, we are taking this opportunity to make some changes to make your apps appear better in the macOS 10.10+ ecosystem. Ever notice that a Label control and the text portion of a CheckBox or RadioButton control are not exactly the same color? Going forward, the default colors of controls which should automatically change between Light and Dark modes will do that. So if you have a Label using the default color of &c00000000 (Black with Transparency = 0), the color that is actually used is what Apple calls labelColor. It’s still black, but is a tiny bit translucent. TextFields and TextAreas will automatically change text, placeholder, selection and background colors to match the Apple prescribed colors for automatic Light/Dark compatibly. We think you’ll find that building your apps with 2018r3 will largely make them just behave and appear the way you expected them to.

IMPORTANT NOTE: These color and framework changes affect how your apps draw on all versions of macOS, so make sure you try them out on your 10.10 through 10.14 VMs before shipping!

Eating our own dog food

One thing we hear from users every so often is the desire for Xojo to use our own products for building apps. As most of you know the IDE itself is written in Xojo, but we also have several other apps (big and small) that are written in Xojo.

• Feedback – Our bug reporting system
• Xorders – Our internal order system
• Lingua – The Xojo localization app
• Remote Debugger – The remote debugger stubs for desktop and console

While the 2018r3 cycle was in progress, all four of these projects got updated for Mojave’s Dark Mode and definitely helped us find framework rendering bugs early on in the pre-release process.

What about Windows and Linux?

The TL;DR version is that we’re still looking into it. 

Currently there are several different ways to change Windows 7, 8 and 10 to use a dark interface, not all of which are compatible with the Xojo Framework controls and the Windows 10 2018 Fall Update promised yet another way but that ended up only being for UWP. We are looking into which method gets you the most “bang for the buck” so to speak. 

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.