From The Battle for Wesnoth Wiki
Revision as of 21:00, 5 April 2014 by Aquileia (talk | contribs) (move link to a separate line)

Submitting a patch for a large and mature project like Wesnoth can be an even more daunting task than writing the code it delivers. This page provides some advice and requirements for prospective code contributors seeking the best chance of acceptance for their patches.

Technical requirements

  • All patches should be submitted as GitHub pull requests
    You may post them in the Coder's Corner forum for discussion too, but we need to track their status, and GitHub is better suited for this. See this page for help on using git and GitHub.
  • Add entries to the changelogs summarizing your changes if necessary
    The changelog file contains a list of outstanding changes that is published with every release. If you are fixing a bug or adding a feature that is particularly visible or important for players, you should also add an entry to the players_changelog file.
  • When adding new C++ source code files, make sure to update the most commonly used project files
    The development team primarily uses CMake, SCons, and Visual C++. The relevant files are src/CMakeLists.txt, src/SConscript, and projectfiles/VC9/wesnoth.vcproj. You may take a look at how existing source code files are handled in each build script to get an idea of the best way to add your own. Please consider updating the other build environments under projectfiles/, e.g. Code Blocks, as well.
  • C++ source code patches must not generate new warnings
    Wesnoth has a large number of compiler warnings enabled, and all of them are useful. If your code causes new warnings during build, you will be required to fix them.
  • Add yourself to the game credits
    Including your name and/or username(s) makes it easier for the development team and the community at large to recognize your contributions. New contributors (i.e. those without commit access) should add themselves to the Miscellaneous Contributors section of the credits file (data/core/about.cfg), making sure to follow alphabetical order with respect to the first character that will be displayed.
  • When changing or adding WML features, provide directions for updating the wiki along with your submission in the tracker
    This allows us to provide content creators with up-to-date information about WML features, even if you cannot be around in time for the commit or the next release.

After submission

  • Be patient, sometimes we are not very responsive
    The Wesnoth developers live on different locations across the globe and have other matters to attend to, most of the time. It may happen that your patch is assigned to a developer who is currently unable to dedicate much time to reviewing it. If you feel that it takes way too long for us to respond, contact us in #wesnoth-dev on
  • Don't be surprised if we discuss the patch a lot
    Thus, you should leave us a way to contact you, either a forum nick, an email address, or submit with a registered account. We recommend that you join the #wesnoth-dev channel on regularly so we can contact you in real time if needed.
  • Sometimes patches are rejected, don't be surprised if this happens
    If your patch introduces new errors or bugs, the feature you implemented isn't considered an improvement or we couldn't contact you with our questions and recommendations, the pull request will be closed without merging. This can usually be averted if you discuss your idea on #wesnoth-dev as the developers will point out these issues. If it happens, don't let this discourage you; it's just necessary to ensure Wesnoth remains enjoyable.

Obtaining help

If you encounter any issues or need additional guidance when preparing your patch, the easiest way is to ask the developers on the aforementioned IRC channel #wesnoth-dev. You can e.g. log in via

If you know who is responsible for the code your patch addresses, please prefix their IRC name in front of your question - else your message could be overlooked.

If your patch has a major impact on Wesnoth, the developer mailing list on might be more appropriate as all developers will be notified.

See also