1# Contributing to SuperTux
2
3## Bug reports
4
5- GitHub Issues in English only. IRC support might be possible in other languages,
6  however English is generally preferred so everyone can understand what's happening.
7- Please check for duplicate issues on GitHub, as they're wasting the developers'
8  time.
9- Also try to check if your issue has been resolved in the development version.
10- Separate issues and feature requests. Don't put all in the same issue.
11- If you made a mistake in your bug report, please use GitHub's edit feature
12  to correct the wrong detail, instead of closing the old issue and opening a
13  new one.
14
15
16### Required information
17
18Please include the following details in your issue report so that we can investigate:
19
20- The SuperTux version you're using, as printed in the bottom left corner of the
21  menu or in `supertux2 -v`.
22- Details about your kernel, operating system and distribution, including name
23  and version details.
24- If possible, provide steps to reproduce your issue.
25- If available, it's a great help for the developers to include a backtrace from
26  gdb or a core dump. If you're on GNU/Linux and your distro is using systemd, it's
27  highly likely that a core dump is available using `coredumpctl(1)`.
28
29### Add-on related issues
30
31No support is provided for third-party add-ons (that doesn't include official
32add-ons or language packs). However, a pull request against the SuperTux/addons
33repository containing a fix is always welcome.
34
35### Translation issues
36
37Please use Transifex to fix or report translation related issues.
38
39## Pull requests
40
41- No duplicate pull requests, please.
42- Please test your code to see if it works correctly. If the pull request
43  is untested or work-in-progress, please mention that.
44- Pull requests importing translation updates from Transifex are, unless requested
45  by a contributor, not very welcome.
46- Commit messages should follow this style:
47  - First line: Short summary, up to 72 characters
48  - An empty line, separating message subject and body
49  - Detailed explanatory text for the change which can include multiple paragraphs,
50    or bullet points. Maximum of 72 characters per line.
51  - If the commit fixes an issue reported on GitHub, please add another empty
52    line, followed by a line containing `Closes #xyz`, where `#xyz` is the issue
53    to close. See <https://help.github.com/articles/closing-issues-via-commit-messages/>
54    for a more detailed description of this feature.
55  - If the commit doesn't include any changes that need CI testing (code or
56    build system changes should always be CI tested, other things not), yet another
57    empty line, followed by a line containing `[ci skip]`. This makes the CI
58    ignore that commit.
59- Please [squash](https://help.github.com/articles/about-git-rebase/) commits that belong together.
60  If you forget initially, it's okay to force push to your own fork to fix it.
61- No merge commits inside pull requests. Use `git-rebase` to keep your branch
62  up-to-date.
63- To make it easier for everyone, don't make a pull request pulling your fork's
64  `master` branch.
65