Communication

    Before you contact the team, report a bug, post on the forums, etc. you should read through this page. Following the guidelines and instructions on this page will make the community and project run more efficiently and happily. Though this article may sound a bit harsh, please don’t be afraid to post. The team is generally quite patient, unless you’re a repeat offender. ;)

    Contents

    Please keep in mind…

    The developers are not paid

    The developers do this because they enjoy it, not because you paid them. They’re not paid to please you, though they’ll try to take your suggestions into account if possible.

    The developers only work on their free time

    They might not have a chance to answer right away. Be patient—they’ll respond eventually. And if they don’t, politely bump your post. This also means that you shouldn’t make trivial requests that are of no importance, nor extremely demanding requests.

    Open-source does not always mean your contributions will be accepted

    The team has to keep the quality of code and artwork up. This does mean that sometimes your work can’t be accepted. Please don’t be discouraged—the team will be glad to help or give advice.

    Guidelines

    When reporting a bug or crash in the game

    • If the bug is already reported on GitHub:
      • If the bug is open, see if you can report any more information to the team.
      • If the bug is closed, you probably will have to wait for the next release for the fix to be included in the game, unless you want to build from source.
    • If the bug is not reported:
      • Make the title clear and descriptive.
      • Include a detailed explanation of the problem. Step-by-step instructions on how to reliably reproduce the problem are especially helpful.
      • Include system information such as your operating system, operating system version, graphics processor (GPU) model and manufacturer, graphics driver version, and CPU model.
      • Include the stdout.log file. (See “Where does STK store the user config file” on the FAQ page for information about where this file is located.)
      • Include screenshots, if needed.
      • If you are capable of compiling STK yourself and running it under a debugger (such as GDB, Valgrind, or Visual Studio Debugger), please compile STK in debug mode, run it, and post the output from the debugger.
      • Include any other information as you see fit.
      • Answer any questions the team asks as completely as you can.

    When presenting an asset or other artwork contribution

    • Provide the source files (.kra, .xcf, .blend, etc.).
    • Clearly state the license. (See Licensing for options.)
    • Accept criticism and see what can be done to improve your artwork.
    • Discuss with the team while it is still work-in-progress to get feedback.
    • Be clear whether your contribution is complete or work-in-progress.

    When making a suggestion for STK

    This is a sensitive topic. Of course we need to accept criticism and suggestions—if we don’t, then it is contrary to an open-source ideal: that the software is for everyone’s benefit. But where does a request become too much? For that we must also watch for conflicts with an open-source ideal: that everyone should contribute where possible. So when making a suggestion for STK, please ask yourself these questions:

    • Have I made any contribution to SuperTuxKart before?
      • This could be donating, making objects, tracks, textures, etc. Even add-ons help the game.
    • If I were able to do what I am asking for, would I be willing to do so?
    • Do I understand the effort needed to perform this task?
    • Do I at the very least express support for the team and the work they do?
    • Have I made a lot of feature requests lately?
      • This may sound mundane, but it is really a sign of whether you respect the team’s work. If you respect their work, you’re a lot less likely to complain.