Let's talk about GitHub Issues! GitHub has this great tool called Issues. Issues not only for developers can be used to track bugs, but it can also track enhancements and tasks. Spare 3 minutes of your time and get a quick overview of the Issues feature! Here's a breakdown of an Issue: Here we can see that we have:
Title should give some general insight as to what the bug is about.
Description should give greater detail of the bug that can't be explained in the Title.
Labels which are colored to represent a category to which they fall into it.
Milestone which is what developers can use to track enhancements or tasks, ask described above.
Assignee which is someone who is directly linked to resolve the issue.
Comments which allows other members to give feedback on the issue.
What are some good details to provide in a bug report? When describing your Issue through the Description area, it is recommended that you provide as much information as possible to make the Issue get resolved a lot quicker. Keep in mind you can tag people within the Description area through the @mention feature. You can also tag other Issues by typing # which will pull up a list of issues. You can find a more detailed list of GitHub Markdown here. An example of a very detailed bug report which prompted a quick resolution can be found here. Some information to keep in mind while creating an Issue:
GitHub Hash: The hash is a 40 alpha-numeric string (which can be broken down to the first 7 characters) which states the version you are at. A detailed guide of getting your hash can be found here by @nanakiwurtz. (If you're using SVN instead of Git: Please also put the change date and first line of changelog beside the revision number, or we'll be assuming you're using very old rAthena revision).
Client Date: The client date provides specific details depending on the issue. The main detail is that it helps narrow down issues if it's related to a packet problem.
Modifications that may affect results: It's always best to try to reproduce your issue on a clean rAthena if you have lots of modifications.
Description of Issue: Describe your issue in detail! Screen shots and videos help a lot! Please also provide crash dumps if the one of the servers is crashing.
How to Reproduce Issue: Describe how to reproduce your issue in detail! The more the merrier!
Official Info: Provide creditable sources to state why it is a bug! Please don't provide an iRO Wiki link as there is a high chance it doesn't match kRO behavior.
Be wary of the @mention feature! Since rAthena uses custom @commands, when describing an issue that deals with these commands please keep in mind that this does clash with the @mention system for GitHub! Always quote the text when mentioning an @command (ie: `@hide`) so that you do not tag GitHub users! What are all these colored labels? For the most part you as a user will have no reason to worry about the Milestone or Assignee parts of an Issue. The different Labels of an Issue allow developers to quickly understand the issue and also allows for fast searching or sorting.
Labels
Users should be aware of the 'Mode' and 'Status' Type Labels as these sometimes require feedback so get to know your Labels!
So how does this benefit me? You might be asking your self this question at this point. This helps you and the community in many ways! Detailed bug reports lead to quicker resolution which means less bugs and more official content! It also can help you earn some nifty badges! tl;dr Please include the following information when creating a bug report to provide a quicker resolution!
GitHub Hash
Client Date
Modifications that may affect results
Description of Issue
How to Reproduce Issue
Official Info