Reminder: How to get bugs fixed quickly

Unity 4.6 is in beta, which means it's not quite finished yet; there are still bugs, oddities, small missing features, and other things that need to be taken care of before the dev team are willing to call it 'done.' They already know about a lot of the issues, but there's always more to find - that's the point of a public beta. 4.6 is officially out! It's not a beta any more. However, all the following advice about reporting bugs is still true

So, when you find something that isn't working right, or is difficult to use, or would be perfect if they'd just add this one checkbox or whatever, the dev team want to hear from you. Posting in this forum is a good start, and you'll see Tim C, Rune, and Phil (amongst others) doing what they can to read and reply to everyone's questions, but once you're sure you're not just misunderstanding things, the best thing to do is to make a formal bug report. That way the bug is logged, can be tracked, can be checked up on, and so on.

There has been some previous advice on how to do this most effectively, and of course there's the Official Bug Reporting FAQ, but to recap a few things:

• DO submit things via the bug reporter instead of only posting in the forum about the problem. You can open it via Unity's "Help" menu, or find it next to Unity in the Start Menu (on PC) or Applications folder (on Mac). The bug reporter will automatically include lots of useful information about your computer, your OS, your Unity version and edition, and so on.
• DO submit a report when Unity crashes and the reporter pops up automatically, even if you're not sure how to reproduce it or can't attach your project. Raw crash reports are still useful.
• DO include a repro project - a project that the developers can open and see the problem for themselves - and DO remove things from it that aren't related to the bug, so the developers aren't distracted or misled by irrelevant stuff. You could do this either by stripping down a copy of your project, or by making a fresh project and recreating the problem in it. Make sure your minimal project does actually reproduce the bug, though! Also, make sure to save your open scene/project before opening the bug reporter.
• DO give instructions on how to reproduce the problem that the developer can follow at their end. Keep them clear and to-the-point. They might just be as simple as "Step 1: Open the attached project. Step 2: Crash."
• DO consider using screenshots or a screencast to demonstrate or explain more complex issues. There's free screen casting software available: for example, you could use Jing or OBS. Just recording yourself using Unity and talking about what you're doing/thinking for a couple of minutes can be much clearer than a text description. You can either attach the video to the bug report, or upload it somewhere and put a link into the report.
• DO file bugs from the latest version of Unity. Bugs from older versions aren't necessarily ignored, but they aren't looked at as quickly as bugs from the latest version because they're more likely to have been fixed already.
• If you've been discussing the problem in this forum, DO follow up by posting the bug number - this is helpful both for Unity devs who are reading the forum and want to dig up your report, and also for other community members who run into the bug and want to keep track of it. Remember to post the bug number from in the subject line of the email you get after filing a bug, not the Fogbugz link.

And here's a few things to avoid:

• DON'T submit reports that just say 'X is broken,' even if you think your repro project makes the problem obvious. What's obvious to you might not be obvious to someone else; they may look at your project and think it's meant to look like that. Always describe the way in which it's broken, and if possible describe what you think it should be doing instead.
• DON'T approach filing a bug like starting a conversation. The best bugs contain all the information the developers need right from the very beginning. If they have to get in touch with you and ask for more info, everything slows down. Better to have too much information in the report than too little.
• DON'T file duplicate bugs unnecessarily. Doing so just makes more work for the QA team; it won't cause the bug to be fixed any faster. If you're not sure whether it's the same issue as someone else has reported, it may still be worth filing just to be on the safe side, but use your common sense. If you just want to "me-too!" a bug, you could look to see if it's in the Issue Tracker, and vote for it or comment on it there.
• DON'T file feature requests as bugs unless you're asked to. The dev team are still looking to polish and perfect the existing feature set; they're not looking to add weeks and weeks of extra work to their task list. For now, the place for major feature requests is the Feedback site. If you have a minor feature request, something which you're reasonably confident would be very quick to do, then you can post in this forum about it and someone from the dev team might ask you to file a bug about it - but equally, if you post about it here, someone might be able to show you a way to do it already.

The more you can follow the guidelines, the more easily the dev team can track down the problem and eradicate it for you. Give them good reports, and they'll give you a better, stronger, faster Unity!

Thanks for reading this far. You get a cookie.