There are a handful of things you should be
When contributing to Ryzom Core you should be familiar with our licensing, coding standards, and how to get ahold of us:
All code submissions to Ryzom Core will be licensed under our preferred license, AGLv3. Any code contributions not licensed this way will not be accepted.
Additionally it cannot be emphasized enough: joining in on our discussions either through the Community page or IRC makes collaborating and contributing to Ryzom Core a lot easier. Check out Contact Us for more details!
Whether you're a Ryzom Core user, a Ryzom player or a community member everything, except documentation, should start with an issue. There are only a few rules around issues:
ddd
EOL Extension: http://mercurial.selenic.com/wiki/EolExtension
work in a branch.
Contributing a Patch File
When creating a patch you should try to segregate the work you're doing from any other activity. This makes generating patches, requesting a pull, and scrolling through the commit log much easier on everyone. For very small patches you should try and keep your work into a single revision and have only that work in that revision. This makes generating a patch file easier as you can generate the diff from the commit directly. For more complicated work such as large refactoring efforts or new features - any effort which may span a longer time-frame and involve a large number of commits - you should fork the Ryzom Core repository on BitBucket, create a branch and work within that branch.
For more information see https://confluence.atlassian.com/display/BITBUCKET/Working+with+pull+requests