[PLEASE READ] Posting & tagging guidelines for bugs & suggestions

[WillLem]

Tagging System Explained

To keep things simple and organised, I've decided to start using the following tagging system for bug reports and suggestions:

[ ✓ ]
This indicates that the [BUG] has been fixed, or the [SUG] has been implemented. At this stage, there may still be discussion or further action pending, so the topic may remain in the "Bugs & Sugs" board and, if it's a [SUG], may yet be revoked following implementation. Only once it has been moved to the "Closed" board should it be considered final.

[ + ]
This indicates that the [BUG] has been replicated successfully and confirmed as a bug, or that the [SUG] has been accepted. Discussion could still influence the outcome at this stage, but it's pretty much a guarantee that the [SUG] will at least be trialled in a future version update (if implemented successfully). The next stage is to attempt to fix the [BUG], or implement the [SUG]. If successful, the topic will then be re-tagged as [ ✓ ]. If unsuccessful, the topic could still be rejected at this stage, but is more likely to be re-tagged as [ ? ].

[ ? ]
This indicates that further discussion and/or information is needed before any action can be taken. It may be that the [BUG] has not yet been tested and confirmed, or the [SUG] needs to be discussed either for clarification, to see if other users would be interested in the feature being added, or for specifics on how the feature should be presented. If you see this symbol on a topic, this is the point at which your input is most likely to influence the outcome, so please do reply with any comments or suggestions that you might have at this stage.

[ - ]
This indicates that the [BUG] has been deemed as not a bug and/or not something that needs to be addressed program-side, or the [SUG] has been rejected. At this stage, if the topic has been moved to the "Closed" board then the decision should be considered as final, but the topic will remain unlocked for possible further discussion either way.

How To Create A Bug Report / Feature Suggestion

The following are some basic guidelines for creating bug reports and suggestion topics. For the most part, these guidelines are just that: guidelines. It's not a major issue if these aren't followed to the letter, but it does help with keeping the forum organised and keeping your topics clear and easy for others to understand.

1. Tagging

Prefix your topic title with the appropriate tag. First should be either [BUG] for a bug report, [SUG] for a suggestion, or [DISC] for a discussion. Following this should be either [PL] if it relates to the game engine itself, [ED] if it relates to the editor, or [STY] if it relates to styles. If multiple tags from each set are applicable, use the one that you think is most applicable. If unsure, just use your best guess, it isn't the end of the world if you get it wrong.

2. Creating a title

Topic titles should be reasonably specific. For example, if the editor has a bug where it crashes when you try to load any level with 500 or more lemmings, "Bug in the editor" is not a good title. "Editor crashes when loading certain levels" is better. "Editor crashes when loading levels with 500+ lemmings" is better again.

3. Providing Information

Be as specific and descriptive as you can in your bug report/feature suggestion. If it's a [BUG], include steps to reproduce the observed behaviour that another user (i.e. me!) can follow in order to see exactly what's happening and what actions lead to triggering the buggy behaviour. If there are any times when the bug doesn't occur, include that information as well.

If it's a [SUG], remember that your idea may be quite obscure and unique (even if you don't think it is!) and so it will need to be explained as fully as possible.

For both [BUG]s and [SUG]s, screenshots and/or visual representations are extremely helpful. I may even request these if I've been unable to understand your original post for any reason, so bonus points if you can provide anything like this up front!

4. Adding Polls

Feel free to add a poll to your topic if you want to get others' opinions on your [SUG], or to see if other users have experienced the same [BUG]. Polls will not necessarily influence the outcome of a [SUG], but will help to indicate whether or not other users are interested in the feature being added, which may become important later in the process.