GitHub Issues and rAthena Bug Reporting

[Aleos]

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!

• Bug Type
  • bug:core : A fault that lies within the main framework of rAthena.
  • bug:database : A fault that lies within the database of rAthena.
  • bug:documentation : A fault that lies within the documentation of rAthena.
  • bug:forum : A fault that lies within the rAthena forum.
  • bug:script : A fault that lies within the scripts of rAthena.
  • bug:skill : A fault that deals specifically with a skill.
  • bug:tool : A fault that lies within a tool of rAthena.

• Mode Type
  • mode:missing : Issue Title or Description does not state pre-renewal or renewal mode.
  • mode:prerenewal: A fault that exists within the pre-renewal mode.
  • mode:renewal: A fault that exists within the renewal mode.

• Priority Type
  • priority:high : A fault that makes rAthena unstable or unusable.
  • priority:medium : A fault that makes rAthena have significant repercussions but does not render rAthena unusable.
  • priority:low : A fault that affects rAthena in one piece of functionality and is self-contained.

• Server Type
  • server:char : A fault that lies within the character server of rAthena.
  • server:login : A fault that lies within the login server of rAthena.
  • server:map : A fault that lies within the map server of rAthena.

• Status Type
  • status:client date missing : Issue Title or Description does not state the client date used to create the bug.
  • status:confirmed : Issue that has been validated by a developer to affect rAthena.
  • status:duplicate: Issue that has been reported before.
  • status:git hash missing : Issue Description does not state the hash of rAthena used when the bug occurred.
  • status:invalid : Issue that is either not official or is not related to rAthena.
  • status:needs more info : Issue that needs more information from the issue creator.
  • status:needs official info : Issue that needs more information from a creditable source.
  • status:started : Issue that has begun resolution by a developer.
  • status:unable to reproduce : Issue that was unable to be reproduced on rAthena.
  • status:wontfix: Issue that cannot be fixed through some limitation or is intended behavior.

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