**Please Read Before Posting!**

[Sapu94]

Please follow the following guidelines when posting a new thread in this forum (also somewhat applicable to replies to existing posts).


Check that you're not asking something that's already been asked!
Fist of all, check the FAQ page to see if your question has already been answered! Obviously I don't expect you to read every single thread that's ever been created, but a brief scan of the titles on the first page or two for anything that might be related to your question / issue would save everybody a lot of time.

Follow up!
I do read every single thread and reply to most of them within 12-24 hours. If you post a thread, make sure you are checking it frequently for responses. Often you'll be asked to provide more information or be given something to do in order to resolve your issue. Even if you're issue has been resolved, a quick reply saying "I did X, Y, and Z and now my issue has been resolved" is very useful feedback for the person who was helping you with the issue and for somebody else who has the same issue and might stumble upon the thread at a later date.

...and most importantly, be specific!
Copied and improved from curseforge:

• When describing problems / defects, go into as much detail as possible on how to reproduce the issue, what occurred, what you expected, any errors you received, etc. If the developers can't reproduce the issue themselves, fixing it is near-impossible, so make it count. TSM has roughly 100,000 lines of code and only a small portion of issues are due to a defect in the code at all. The more effort you put into accurately and precisely describing the issue you are having, the more likely you are to get a prompt and descriptive response (and the quicker the code defect will be fixed if applicable).
• When describing enhancements (hopefully in the suggestion thread rather than a new one), go into as much detail as possible. Describe how you want the new feature / change to look, act, feel, etc. Also be clear on the purpose of the new feature / change. The less thinking I have to do about what the feature is and what it will be used for, the more likely I am to implement it anytime soon.

Try and avoid the following:

• Referring to the "latest version" or "latest update" is one of the pet-peeves of nearly all software developers and is read as you not knowing what you're talking about. Use precise version numbers.
• General statements like "X feature no longer works" don't convey any useful information because 99% of the time, the feature does work as intended and there are things specific to your setup that are causing it to not behave as you expected. To save everybody a lot of time, please be specific and describe exactly what you are doing, what you expected to happen, what actually happened, and any applicable settings. Screenshots are always good!

I don't mean this post to deter people from posting threads. Hopefully this thread will help you compose a well thought-out post and get a prompt and well thought-out response (there is a correlation there ).

Enjoy and thanks for reading!

[Sapu94]

http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

That is a great article on how to (and how not to) write bug reports. It is somewhat long so if you don't have time to read the whole thing, just skim it / skip to the conclusion. Reading it will help you avoid the 90% of bug reports which are initially useless and require multiple follow-ups (over many hours / days) to resolve. In the end, properly written bug reports get resolved MUCH quicker and are less frustrating on both ends. Thanks