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