Helping on the Mozilla SVG Project

Just prior to the release of Firefox 3, we lost our one full time developer, Tim Rowley, when IBM's Mozilla work came to an end. We're now looking for new contributers to help fill the void or to help with some of the non-development work to free up the remaining volunteer developers to focus on the code. Virtually everyone can help at one level or another and have a positive impact...you don't even need to know SVG.

Here are some areas where we need help:

Spreading the word

Naturally, the more people that consider helping, the more likely it is that we'll get some help. If you know someone who might be willing to contribute a little time (or a lot!), point them to this page or link us up by email.

We're also interested in hearing from any organizations that benefit from good SVG support in Mozilla or that consider such support to be important. This is especially true if they might consider donating some developer time (perhaps for a specific feature ,or perhaps on an ongoing basis). As with any new code contributor, we'd be very happy to help with the process of getting into the code and in selecting and working through bite size pieces of work.

Reporting bugs

If you notice that Mozilla is not displaying some SVG correctly, please don't assume that we know about the issue or that it will be fixed soon. Unfortunately, people do that far too often. Instead, please file an SVG bug report using this form. (Sorry, the form is ugly and not very suited to filing SVG bug reports, but we'll fix that soon--check back here in a week or so for the new link. For now though, just make sure you fill out the Summary and Details fields when you're in a rush.)

Triaging bug reports

Unfortunately, the C++ contributors currently spend a significant amounts of their limited time sorting through new bugs, teasing more information from reporters, figuring out whether bugs actually need developer time, and giving an explanation to the reporter when they do not. This is important work, but it's something that non-C++ contributors could do to free up limited C++ contributor time to focus on coding. If you know a little SVG and you'd be willing to investigate some of the bugs in our "UNCONFIRMED" queue, let us know and we'll help you get started. Even one person volunteering to help with triaging this list will help free up developer time to focus on fixing bugs and implementing new features.

Writing testcases

It can be very difficult to determine the underlying cause of a particular bug from large (often multi-file), real world SVG--in fact it can even be difficult to tell if there really is a bug. When someone reports a bug, one of the first steps is to take their SVG code and, one bit at a time, remove everything that isn't required to demonstrate the bug. This produces what we term a "reduced testcase". Some bug reporters are unwilling or unable (perhaps due to lack of time or lack of knowledge of SVG markup) to create reduced testcases. That's fine--we still want their bug reports. However, reducing testcases is another thing that is taking up C++ contributors' limited time. If you know a bit about SVG markup and wouldn't mind doing a bit of detective work to create reduced testcases, that would be a great help. Check out the list of bugs without testcases and let us know when you have any questions or need any help.

Quite appart from allowing the C++ contributors to narrow in on the root cause of a bug, reduced testcases have a second, equally valuable use. With a few tweaks, testcases can be added to our automated regression test suites. These suites are run continuously to make sure that as we change the code we don't accidentally (re)introduce bugs. As these test suites grow, the chances of new bugs and regressions slipping through into new versions of Mozilla shrink. Naturally, high quality, bug free implementations are something that everyone can appreciate. :-)

Review our code

We've been actively simplifying and documenting our C++ code to make it easier for new contributors to understand it and get up to speed quickly. When you're looking at the code on a regular basis though, it becomes hard to see it from the perspective of someone seeing it for the first time. Even if you don't intend to write code for Mozilla, you could still help us by taking a look at the code we have. Try and get a handle on it, ask questions, tell us where it's not easy to understand, and make suggestions if you can think of ways we could improve it. We need fresh eyes, and by looking over our code, you're sure to learn a thing or two. :-)

Coding

We still have a ton of work to do to implement new features, find and fix bugs, and simplify and clean up the C++ code to make it easier to work with in future. Unfortunately, C++ contributors turn out to be the hardest type of contributor to find. If you might be interested in working on the code, please do get in touch! We can help you start out small, perhaps by cleaning up and getting to know a section of code, or else by taking on one of the bugs in our "good first bug" list. If you enjoy it, we can build from there.

If you know an organization that has an interest in or cares about good quality SVG support in Mozilla, put us in touch and perhaps they will consider donating some time of one of their developers.

Other suggestions on action we can take to improve this problem are very welcome.


Jonathan Watt