As milestone 1 nears completion, we're ready to start looking at laying into M2. Also, a bunch of you are probably new to the codebase and looking for someplace to get your feet wet.

The most sensible effort for new developers to dive into is bug fixing. Here's why:

* Many bugs have been identified and documented in the Sodipodi bug tracker. A goodly number are also not that hard to fix.

* A bug gives you a fixed goal to shoot for with a definite end. It is not a huge commitment of your time and doesn't carry any sort of ongoing responsibility - once you've got the fix in, you're done.

* It will expose you to building the codebase, finding your way around in it, creating patches, etc.

* Users *love* applications with few bugs. :-)

There are two aspects to the bug work:

1. Bug Testing - Go through Sodipodi's bug list and test each report to see if it can be recreated in Inkscape and isn't already registered. If so, cut and paste it into the Inkscape bug tracker and mark that you've verified it still exists (and elaborate on how you found it). Include the Sodipodi bug ID number for traceability.

2. Bug Fixing - Grab a bug from the SF tracker and chase it down; try to find a fix for it, and post a patch to the patch tracker. Try to also improve the error checking behavior of the code, where possible.

If those of us who are able to code C/C++ can close a couple bugs each, then we'll establish a sturdy base for building our next set of changes on.

If this endeavor sounds interesting to you, feel free to drop me a line with any questions you have.

Some other efforts that are going on, that you could participate in if you wish, include:

* Research & plan GtkMM-ification (see mental or njh) * Design & develop new layer system (see mental) * Implement arrowhead support (see bryce) * Create unit tests for each source code file (see mental) * Implement new grid systems (see njh)

Bryce