1) Bug reporting
This is easy but time consuming work, all need to do is-
* (optional) Download a Subversion client and get the latest code from SVN trunk, or grab a nightly build.
* (optional) Create a sourceforge account if you haven't already got one.
Now follow these instructions.
If enough people help out by fixing the bug reports and test cases then we'll create a special user group for the bug team and give them moderator access to the bugs forums, so that they can rename and move threads.
2) Filling feature requests and fixing bugs.
The tracker is filled with bugs that need fixing and features that people would like to see in Irrlicht. You can help out by fixing/implementing one of these! If it's something big and you think that we may not accept it then make sure you discuss it in the bugs or open discussion forum first, or come to the chat room and discuss it in person.
Changes to the API, including any additions are always bad! Okay, they're not always bad for Irrlicht in the long run, but bad for your patch because it will need a lot of discussion before committing it and it will be a long time before you see your changes in an official release. Avoid them where possible.
If you fix a bug: Post your patch to the patch tracker, post a link to it on the bug report, and also bump the bug topic in the bugs forum.
If you fill a request: Post your patch to the tracker, a link to it on the request tracker, and create a new thread in the open discussion forum.
3) Reviewing patches
Patches always need reviewing, because:
* They don't conform Irrlicht's code style rules.
* They have gone stale; they don't work with the current version of Irrlicht.
* They contain more changes than is necessary, or changes which have nothing to do with the problem they fix. These must be split into multiple patches or have the useless parts removed.
* Some are not on the patch tracker, they are posted to the forums and have been buried. These need re-testing and submitting to the patch tracker.
* Some have been reviewed and need changes, one of the dev team have commented on the patch with an idea for a better implementation. These need to be rewritten.
* Like all code, they have bugs in them.
To review a patch:
* Decide where it should be applied: If it's a bug fix then it goes to the current release, if it's a new feature then it goes against SVN trunk.
* Download the patch file and open it in a text editor. Read through it and see if it conforms to Irrlicht's style guide, get an idea of what it does.
* Apply it to your code, manually if necessary.
* If there isn't a test case then write one, make sure that you test as much of the changed code as possible.
* If necessary, fix the patch. Use tabs, not spaces, use Windows line ends, remove unnecessary API changes, follow the style rules strictly.
* If the patch is supposed to improve performance then make sure you test it in release mode!
* Compile with all warnings enabled, try to remove as many as possible.
Once you've reviewed the patch:
* If you didn't make any changes, just post a comment to the original patch. Explain what you tried and that it works.
* If you made changes, post your new patch to tracker as a new item. Post a link to it in the old patch, link to it in the forum thread if there is one. You could post the patch in the forum in code tags instead, and link to that if you want.
4) Help extend Irrlicht.
The code snippets forum has lots of cool plugins and extensions, maybe you even wrote one yourself. We'd like to move as many as possible to IrrExt and build a team to look after them.
If you'd like to volunteer to help out, send an email to irrext-devs@lists.sourceforge.org