GitHub issues are used for everything from bug reporting to suggesting long-term ideas. You can make everything run much smoother by following some simple rules.
Always give your issue a meaningful title as this is the first thing anyone will see.
Note: [CR] and [WIP] "tags" are meaningful only for PRs. All open issues by definition are request for comments and work in progress.
Before you submit a bug always search the current list of issues to see if it has been reported already.
Your bug report has to include:
- On what OS did you experience the problem (Windows, Linux, OS X etc.)
- What version were you playing:
- Tiles or Curses (text-based)
- Version string (preferably full version e.g. "0.C-4547-g3f1c109", or Jenkins build number e.g. 3245)
- Description of the problem written in a way that enables anyone to try and recreate it
Your bug report may include:
- Screenshot(s) as some things are best explained visually
- Save file (e.g. link to a dropbox upload)
Bonus points for:
- Checking if the bug exists under latest experimental build
- Checking if it is OS specific
The OS and CDDA version are very important - with the pace of changes here it is possible the bug you have encountered has already been fixed. After that reproducibility is the key, so write your report with all the necessary details.
Please first search if something like what you have on mind has been already proposed. If so, feel free to join the discussion! If your idea is related but sufficiently different, open a new issue and refer to the older discussion (use GitHub's #issue_number reference system).
There's no guarantee that any given suggestion will be added or that any given bug will be treated as high-priority (unless it's completely breaking everything), but we'll try to give each one due consideration. Please remember that developer time is limited.