This process is new and we have little experience - we expect it will evolve over time, so please send any suggestions for improving the process.

Currently the idea is:

 * [http://trac.wildfiregames.com/wiki/TortoiseSVN_Guide Check out] the game from SVN. Git is also acceptable if using a fork of the official 0 A.D. git repo.
 * Make some changes.
 * Make sure you've updated to the latest version of the code (and merged in your own changes).
 * Create a patch, with `svn diff` (or the equivalent "create patch" feature in TortoiseSVN).
 * Attach it to a Trac ticket (an existing ticket if there's a relevant one, else a new one), prefix the ticket '''Summary''' with "[PATCH]", set the ticket '''Milestone''' to the current release, and add "review patch" to the '''Keywords''' list. (The keywords make it show up on [query:status=new|assigned|reopened&keywords=~review this query].)
 * Try to keep the patches reasonable, i.e. don't mix a dozen bug fixes and new features together, producing a single massive patch. It's generally better to break these into multiple patches, each with its own ticket.
 * One of the core developers should then review it and maybe suggest some changes.
 * When it's considered okay, they should commit it to SVN.
 * If you don't hear anything within a reasonable time period (maybe a week or two), feel free to post a reminder on the [http://www.wildfiregames.com/forum/index.php?showforum=312 forum]. Some patches take longer to review due to low priority, high complexity, or special knowledge required to review it. We appreciate your patience and all contributions.
 * For more "controversial" changes and gameplay features, it's a good idea to create a topic on the forum anyway, to get as much feedback as possible from the community.
 * Also, it's a good idea if you take some time to test patches yourself as well. Even just downloading/applying the patch and compiling it and testing if it does as it's supposed to is highly valuable. (Maybe the developer only has access to Linux, and you're on Windows or Mac, so even just testing to see if it compiles can be a good thing.) You don't have to know all the code to be able to test patches.
 * Once you get more familiar with the code you're encouraged to help review patches yourself. Not only will this help speed things up as bugs and ways to improve your code can be found before a team member has had time to look at the patch, it's also a chance for you to become even more familiar with the code and the coding conventions. 

You must 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].