Hello!
I’ve just spent the better part of the past two hours going through some really poorly written issues on the bug tracker. Some of them were quite nice and well done, but most of them weren’t useful. I’ll admit that during this interlude I was not in the best of moods because of this. Sorry if I came across as harsh on anything.
I understand that the main reason for this is people do not know how to report bugs. This is perfectly understandable, especially since most of the people reporting on Mystcraft are likely very young.
In this regard I want to lay out some basic rules and methods on creating an issue on Mantis. These will help you in writing your report and help me in understanding it. The better the report the faster it gets accepted and fixed. 🙂
Also, before I begin, any sufficiently badly written reports stand a chance of being closed immediately. Make sure your report is informative and covers everything.
Basic guidelines:
- Check for other reports for your issue first. You may not be the first with this problem!
- Be as informative as possible. The more you give me the more I have to work with.
- Type your best. Don’t slur things or use 1337 or any short form of typing. it’s not the place.
- Keep it clean. I’ll ban people for using foul language or inflammatory remarks. I know that your bug probably has you very frustrated, but it won’t help your case to kick and scream like a three year old. 😉
Now, let’s step through this process. It can be a lot to take in at once, so we’ll try to look at each part.
The category dropdown is meant to allow you to select the category that the issue best fits under. Is it a problem with another mod (compatibility)? Or maybe there is something wrong visually (rendering)? Maybe it’s an error in the GUIs. Whatever it is, select the most appropriate category. If it is a general level issue (the whole mod breaks for no apparent reason when I push the F1 key) or no other category cuts it, then go with general. Try your best. 🙂 If more than one suits then pick the best one. We’ll handle that in a little bit.
Next is reproducibility. This is where you indicate how reliably you can recreate the issue. Does it happen every single time you do something, or only once in a while? Can you control it? If you mark ‘have not tried’ then you can guess the first thing I’ll be asking you to do. 😉
Severity and priority can be confusing, especially since they seem like they should be the same thing! Severity indicates how badly the bug affects our game. It also includes an option for ‘feature’ which is meant to be used for requesting minor features or changes. Major features should use the Mystcraft forum. We’re trying to get some real forums up for you guys to blabber in, so hopefully that will happen soon. 🙂
Priority is how important you feel fixing this issue is. Most times it seems like you can’t possibly play without this, but step back and think about it. Keep in mind, this is actually the priority from the perspective of the project. I don’t feel I have to say very much here as you have all done a fantastic job of setting this value. 🙂
Profile is an odd one, in that the name gives no information about what is desired. It even confused me at first! This is the basic specs of the compuer you are using. There are four basic ones already saved into the drop down, but if those don’t quite fit the bill you can write it up yourself. Platform is the machine spec, so usually x86 or x86_64. If you don’t know what that means then you can usually check whether you are 64 bit or not and just supply that. OS is your operating system, so usually Windows or OS X. OS Version is what version of that you are running. In my case I’m running Windows 7, so I’d provide 7 as the version.
Product version is well named if you thing of Mystcraft as a product. I don’t either, but Mantis does. Just select the version of Mystcraft you are using and you’ll be all set.
Summary: This one may be hard. You need to summarize the issue as correctly as you can in about 6 words or less, giving as much information as you can. You might need to think about it a bit.
Description is where you describe the bug in meticulous detail. What happens and the general idea of what you were doing. Be sure to describe what you were expecting to happen versus what actually happened.
Steps to reproduce is how I and the QA team know how to do it too. You should describe your installation process and what steps are necessary in order to cause the issue in game. If yo can’t recreate the issue then describe what you were doing the first time as precisely as you can. Any omissions may make it impossible to recreate the event.
Additional information: This is a good place for your exception log and/or mod list. If you do have a crash error and it dumps an exception be sure to provide it somehow. Any other information you think would be useful should also go here, preferably before the error log. If you need help getting an error log then you might consider using MultiMC. There are also other methods of getting error logs when Minecraft fails without giving it on the MCF.
You can also upload a file. This is useful to provide a screenshot or the error log of the event. You won’t need this most of the time, but don’t be afraid to use it if you need it!
Now you are ready to report your issue! Check over it again to make sure you got everything right and didn’t make any typing errors or leave out anything before hitting submit.
You’ve successfully submitted a bug report! Congrats! Not that hard, was it? But you aren’t quite done yet. Due to the way Mantis works you can’t add tags to your issue on the report screen. How silly! It’s a known issue, and it’s already on their own Mantis tracker, but in the mean time we have to deal with it. Now that you can look at your issue you can see a place where you can add tags to the issue. Go ahead an look through the existing tags. Add all the ones that fit. If you experience the issue on SMP add that. If the issue occurs on SSP as well then add that too. Include the version of Forge you were using (ex Forge 152). These tags are meant to make searching and information finding much faster, and by providing them you make your report 100% better. 🙂
If you realize now you made any mistakes you should still be able to go back and edit your own report. Possibly. I’m not exactly sure.
However, I do know that I can edit your reports, and so can the QA team. And I also know we will. 🙂 This isn’t because you did a bad job, but we might go through and alter things as more information comes to light. There are some fields that only we can set, and there are others that are for both you and us (ex. Reproducibility). The issue will also go through several phases, starting out as ‘new’ and then moving through feedback, accepted, confirmed, and resolved. Through this process it may change in various ways, and we may add things like when the issue will be fixed by, or even when it was fixed! Don’t be afraid of it changing or worried about us editing it. We’re just trying to keep everything clean and organized.
I hope this clears up any confusion with the tracker and helps you all make high quality reports! 🙂 Good luck!