On Wed, 23 Jun 2004, Gazal, Geraud (MED) wrote:

Hi again Inkscape development team,

As I really appreciate the tool you're developping, I'd really like to contribute, as soon as my home internet connection is up again.

Ah, cool, welcome aboard. :-)

So I guess I'll try to submit tons of bug reports and at least the same amount of RFE (subliminal message : as I'm sometime hobbying with mapmaking, I'm really waiting for the layer features....),

Stay tuned; this is high on Mental's todo list. There may already be bits to test, if you're interested - give him a holler.

but I feel that something is missing in your website/wiki : a clear contribution wishlist.

Your web site clearly mentions you welcome new code, patchs, bug reports, RFE, translations, articles (etc); you also exhibit a clear roadmap, but in fact there's something missing for people like me (that would really appreciate to help, but are poor coders/graphists...) : some contribution guidelines. Some clearly stated multifunctional (ie not only technical) needs, for example on a dedicated wiki page...

I'd really like to face a list of small/modest but valuable tasks for the improvement of the software, on which current team can't focus due to lack of time.

This is a very good idea! Why don't you go ahead and set up a page, perhaps starting with what you've listed below, and keep your ears open for other similar items.

In many cases, there are tasks listed on the wiki, but often they're geared more for coders already familiar with the codebase, so something like you describe would be quite useful.

Here are a few places you can dig into to get further ideas for this, and some ideas of my own:

* The bottom of the RoadMap page has a kind of 'future wishlist' section of tasks we'd like done, but aren't "in the plan". There are several non-coding tasks in there.

* The Openclipart project also needs a variety of help, including web work, art, file maintenance (adding metadata to images), scripting. http://openclipart.org/ - see its roadmap too.

* We need more tutorials, and also need to have the current tutorials "optimized" by reducing the file size/complexity so they load faster on slower machines. We need tutorials for some of the "non-basic" things, like how to customize your preferences file, how to add an extension, how to generate SVG programmatically, and especially, how to create advanced graphical effects - shadows, cartoons, 3D effects, etc. etc. See the TutorialIdeas page.

* Help answer questions from fellow users on inkscape-user.

* More published articles, papers, presentations, etc. to help spread knowledge of Inkscape and build up the community. We need help in general to fill in the ArticlesAndPresentations page, and to keep the OtherProjects page up to date.

* We very much need some good solid ideas for proposals of new features. See the NewFeatureProposals page in wiki for things that have been proposed so far; all of these writings need further fleshing out, fresh ideas, and more specific details.

* We need more galleries, examples, and screenshots, as well as web-editors to help make them look nice.

* The Inkscape interface also needs more and better icons. Look through the menus and such for any icons that are missing or need improvement, and draw them. These are kept in inkscape/share/icons/icons.svg.

* We need new ideas for markers, gradients, patterns, templates, etc. Look in inkscape/share/ for what we've got so far.

* We definitely need help from people to just keep an eye on the RFE's and bug tracker to verify the problems, clarify the descriptions where needed, identify duplicate entries, and note ones that have been closed.

* We especially need testing, of all shapes and sizes:

- Locate crashes or other inappropriate behaviors and send a bug report with a recreatible test case.

- Identify performance bottlenecks, memory leaks, etc. using profiling tools. Rerun tests daily so we can track performance improvements/regressions.

- Compare Inkscape SVG rendering against that of other tools and identify differences, then find out which program is wrong and submit a bug report to the relevant project.

- Try loading SVG files generated by other programs into Inkscape and vice versa. Identify where info is lost and which program lost it, and send a bug report to that project. Do the same for other export/import file formats that are shared in common with the two programs.

- Do some informal usability tests with your friends and family. Keep a log of things they find confusing or get stuck on, and report to inkscape-devel. Note any ideas for improvements needed, and make sure they're listed as RFE's.

- Deliberately try to stress Inkscape's boundaries out. Create the most complex, huge, ornery SVG drawings you can, and see what behaviors Inkscape shows. Low memory? Crash? Lock up? Try to identify why it did that, and how it could be prevented.

- Try installing Inkscape on several different systems, or on a given system with different installation mechanisms. Report problems encountered, and identify any differences. This is especially valuable to do whenever we create pre-release packages.

PS I had thought of something like this (can be presented as an array ?): List of needs :

• Docs (in text/html/svg/openoffice formats):

• user manual in English, plus translations : (French, German, Spanish,

Russion, Slovak, Italian...)

• FAQ in English, plus translations : (French, German, Spanish, Russion,

Slovak, Italian...)

• tutorials

We also need translations for the tutorials.

• update of internationalization of the following languages....

It would be useful to identify languages that we don't have *any* translation for, and to look into posting onto sites where translators for those languages might see it.

• Tests

• System/Subsystem requirement document
• Test plan / test items plus traceability matrix linked to the

specifications

• Tests (results) on the following architectures (Linux, BSD, Win, MacOS,

Solaris...)

I've thought that a test plan document could be helpful, to give testers a checklist of things to try out, but most of the test plans I've worked with have been too dry and mind numbing to be of value to an open source project, and wouldn't add much beyond what we already get from the ReleaseNotes. However, I wouldn't be surprised if someone with sufficient creativity and motivation couldn't come up with something more engaging.

I doubt we'll ever create requirement documents. I've done a couple simple ones in the past for Sodipodi/Inkscape but except for special cases, they don't seem to fit our open source development model terribly well. We seem to do best with using the bug tracker and RFE systems, as kind of an evolutionary requirements system, so we like focusing such energies onto them, and just code-as-we-go.

We definitely need more tests. Early on we had figured we'd create formal unit tests, but those haven't proven as necessary as we thought. But it does look like we need some performance and portability tests.

Bryce