New features, or wishlist items may also submitted via the bug tracker system. Although if you are a new Inkscape user, you may want to discuss your idea on the mailing list, or in other forums, to gain some understanding of how it may fit into the developers' vision for Inkscape, before you file your report/request.
Your bug reports are vital for making Inkscape a robust and capable application. It is an important goal that each Inkscape release be stable, crash-free, and behave itself well. Bug reports from users are the primary means of quality assurance, as we rely on the Open Source principle of "Many Eyes Make Bugs Shallow".
If you're a new Inkscape user, it might be a good idea to post the problem you're having in a bulletin board style forum (list on this page), or in Inkscape Answers section, or even the Inkscape User mailing list, to first confirm it is a bug. Often more experienced users will be able to tell you if it's a known bug, or a bug, at all. If it's a known bug, you can look it up, and learn more about it. (Perhaps most importantly, you might learn a workaround.)
If you'd like to be more involved on this level of development, you can register for an account at Launchpad. This will allow you to do things like:
- add your support to existing bugs or feature requests (more support encourages faster fixes) by clicking "Does this bug affect you?"
- add Comments to the report, for example: 'this does or does not happen on my system', 'my experience is different, or whatever', etc.
- upload screenshots or sample, or test files (or other files requested by developers, for further investigation)
- report new bugs yourself
As the original reporter, you are not only the person most interested in fixing it; you also assume some responsibility:
- When you first start to report the bug, be sure to search first, to make sure it has not already been reported. Launchpad automatically searches the title of your bug report. But you may also want to try searching with similar terminology, especially if you are new to the development side of Inkscape.
- Submit complete information: version, platform (operating system), locale (language), steps to reproduce, and sample file(s) and screenshots if appropriate.
- If this is a crash, it's important to submit a backtrace. Use gdb to get a backtrace as follows:
gdb <path to inkscape executable> (gdb) run [parameters (optional)] # Carry out the actions to make the program crash (gdb) btand send us the output.
If you're not very technically inclined, and have managed to be making the first report of a bug that causes a crash, "gdb" is Gnu Debugger. Before you go to the trouble of trying to understand this, get confirmation via your bug report that you need to do this (because even if you searched and didn't find any existing report, there still may be one under terminology that you didn't expect). If you're on Windows, you'll need to use MinGW, which is the Windows version of gdb.
- Windows users can easily do a "time search" by downloading builds from "Development/Compiled Packages/Win32 Builds" link on the download page and finding the first one that doesn't break.
- Don't just submit the bug and forget about it. If a developer takes interest in fixing it, they may ask you for clarifications or more info or files. And it may be weeks later, before you get any response. Unless you opt out, you'll automatically be notified by email, when there is any activity on bugs you report yourself. (So if you're not getting notifications, be sure to check your spam folder.) And you can opt in to notifications on any bug that you might be interested in (even if you didn't report it yourself).
If the bug you report to the bug tracker is not fixed in the next stable release, there may be several reasons. Even if you have provided all the info you can, it still may not be enough for developers, to pinpoint the problem, and/or come up with a solution. They may need clues or info from other users, on different systems, under different circumstances. Or maybe the issue needs more research, or is just a mystery for the time being. Or maybe there are more urgent issues at hand, or issues which need to be solved before yours can addressed. Some issues may be discussed or debated, or a solution wrangled about, for weeks, or even months. Some bugs have been "on the books" for many months, and some even for several years.
But don't let that discourage you from reporting bugs, if you find them. Well documented bugs are valuable and helpful, even if they can't be fixed right away. And your input is welcomed and encouraged, if you're interested, and want to help.
Bug Screenshots and Animations
Making sure the bug report has the required information is very important, when dealing with a graphical issue. If you can attach screenshots, SVG files, and/or video or gif animations, they can really help explain what's going wrong in a bug to the developer.
Simple screenshots can be made from any computer, by using the Prnt Scrn key (which copies the entire screen content) and pasting into any graphics program. Then save and upload to the bug report. Or these days, most computers have a built in screenshot/screen capture/screen clip program. For example, on Windows 7, Start menu > All Programs > Accessories > Snipping Tool. If you're using a modern Linux distro this should be available in the accessories category.
To make animated gifs of the problem, you can use LiceCAP. This program allows you to capture multiple frames showing the problem without having to make a full mpg video of it.