Skip to content

Issues

Issues are a key part of the development process. They are the best way to get something done, as they support communication, progress tracking, and are an easy way to track who is doing what.

Workflow

Most repositories should be setup with some template labels. These labels are a way to track the status of an issue, and should be used properly. You can see an example of labels here.

There are three different types of labels: Priority, Status, and Type. Each label should have one of each (making three labels in total). When someone creates an issue they should assign the Traige label. This marks the issue to be traiged, which can be done by either the game's leadership or a member of tech.

Triaging is straightforward: consider the issue's priority, who is available to work on it, and what type it is. A game breaking bug should be assigned Urgent / High, an annoying bug that happens once a round should be assigned Medium, a small bug that happens once every map Low, and anything lower should be assigned Backlog.

Priority

Remember to stay reasonable when considering priorities. Excess higher priorities simply means the higher priorities become less important, and we are unable to focus on the genuinely urgent / high priority issues.

Once triaged, if the status label is anything other than "Open" or "Backlog", there should be someone assigned to the issue. The person assigned is responsible for the issue, and should be the person to contact for questions / concerns about the issue.

Communication

Make sure to keep all conversations that pertain to an issue within the issue itself. This is important both for communication, verification, and progress tracking.

Upon completion of an issue, the status label should be changed to "Complete". This marks that the change will come into affect the next update. Once the server is updated, all "Complete" issues should be closed.

Issue Creation

When creating an issue, make sure to include all relevant details within the issue itself. The person you are assigning or that will be handling the issue likely does not know what is in your head.

Things to include

  • Map names and download links
  • Links to plugin(s) to add, and versions
  • Explanations of an issue if unclear
  • Intended behavior or implementations
  • Related forum thread(s), bug reports, or media if available

If you fail to create a proper issue, (especially for large issues), we likely will either ignore the issue or close it without responding. It is your responsibility to ensure all needed information is in the issue itself. If there is a template for an issue, make sure to follow it properly.

Issue Commands

There are a few commands that you can use to interact with issues.

  • /cc <user> - CC's a user to the issue. This will notify them that you have CC'd them to the issue, and will add the issue to their TODO list.
  • /assign <user> - Assigns a user to the issue. This is similar to CCing them, but will more explicitly define who is responsible for an issue.
  • /label <label> - Adds a label to the issue (you can also use the sidebar on the right)