This document explains the process to submit code patches. This process isn't well suited for art changes, it's best to use the forums to submit new proposed art. == Creating the patch == First you should [[BuildInstructions|check out]] the game code from SVN or an up-to-date Git fork and make some changes. Make sure you're on the latest version of the code (and merged in your own changes) when making your patch. And try to follow the [[Coding_Conventions|coding conventions]]. If this is your first contribution, please add yourself to the relevant file under [source:ps/trunk/binaries/data/mods/public/gui/credits/texts]. You are free to use your real name, your nickname or both. Go to the "trunk" directory in the source tree, and create a patch, with `svn diff` (or the equivalent "create patch" feature in TortoiseSVN). Also try to keep your patches reasonable. Different bugs shouldn't be mixed in the same patch. When you modify or add methods to simulation components, you should add unit tests that test all added or modified changes. == The [report:21 RFC queue] == Submitting a patch is done by attaching the patch file to a Trac ticket. This can be an existing relevant existing ticket or a new ticket. To get the ticket in the [report:21 RFC queue], you should make sure the ticket looks as follows: * The ''Summary'' (title of the ticket) should start with `[PATCH]`. * The ''Milestone'' should be set to the release we're working on now. * The ''Keyword list'' should have the keywords `rfc patch`. At this stage, at least one other developer should try to give some comments on the patch (on all aspects of it). It is advisable that you also drop by on [https://kiwiirc.com/client/irc.quakenet.org#0ad-dev irc], to discuss matters further. If the topic involves controversial matter (things that influence balancing f.e.), it's also best to create a forum topic for it. Some patches can take longer to review due to high complexity or lower priority. But it's best to keep in touch with us and ask for reviews. Note that any developer can help in the RFC process. So if you have some time, you can also help with other patches in the queue: playtesting, checking code quality or even just seeing if it compiles on your system. When you're already familiar with the codebase, and have a trivial patch (that won't cause discussions on the code style or implementation of the feature), you can skip the RFC stage, and push your patch to the review queue directly. == The [report:15 review queue] == Once a patch is agreed on during the RFC process, it can be pushed to the [report:15 review queue]. This is done by changing the `rfc` keyword to `review`. At this point, one of the core developers should review the final patch on the following points: * Code style (check if the patch follows all [[Coding_Conventions|Coding Conventions]]) * An in-game test (check if the patch implements the advertised changes) * Unit tests (check if the required tests are implemented and the tests still work) When the patch passes on all points, it gets committed. When the patch doesn't pass, it will be denied and send back to the RFC queue. == Legal disclaimer == By sending in a patch, you agree that it is your own work (or else make it clear where it came from) and agree to licensing any code as [http://www.opensource.org/licenses/GPL-2.0 GPL 2+] (or in some cases [http://www.opensource.org/licenses/mit-license.php MIT], especially for code in `lib/` - check the existing copyright headers on the source files you edit) and data files as [http://creativecommons.org/licenses/by-sa/3.0/ CC-BY-SA 3.0].