Follow us on:

Home » Develop » Bug Management

Inkscape Bug Management

Inkscape's bugs are reported and managed in Launchpad. Any Launchpad user can comment on bugs, update their status, and assign themselves to work on a given bug. Inkscape Bug Team members can set the bug status to Triaged (more below) and assign priorities.

Important URLs

Bug status

Launchpad has several bug statuses. Their use in Inkscape is explained here.

Bug importance

Importance reflects how serious is the bug.


Tags assign bugs to categories related by subsystem, platform, or general area of functionality of Inkscape. They are particularly useful to developers who work on a specific area of the code and want to fix several bugs in one go. Here is an incomplete list of the most important tags.


The general methodology for working with bugs is as follows:

Be polite. It takes some effort on the part of the user to come to our site, navigate to the bug report section, and write up a report. If they know their report will be treated seriously and professionally, they'll respect the system and put in extra time to help us solve the issue.

Do not close an unreproducible bug unless a reasonable amount of effort is put into reproducing it, and let it rot for some time before closing -- someone may come up with a better report in comments. (In a few situations we've not been able to recreate the bug, but due to the involved assistance of the user have been able to narrow down and fix the problem, and the user's been able to do the validation.)

Clarify. If it took you some time to guess what it's about, change the summary or add a comment, to make it obvious to whoever will be reading the tracker after you (especially if it's the person who can fix it). For example "bizarro scrolling bug" should be replaced with "rendering quirk when scrolling while dragging masked clone", and "Inkscape crashes in this file" with "crash when dragging gradient stops of clone parent".

When closing a bug as Fix Committed, add a comment that includes the revision number of the first version without the bug. For bugs that appeared only in a development release and were fixed before a stable release was made, set them to "Fix Released" right after they are fixed in trunk.

Always search for similar or duplicate requests before filing new reports. When choosing which report should be marked a duplicate and which one left valid, older reports should be given priority over newer reports. Exceptions can be made if the newer report has signficantly better information provided. Where appropriate, copy and paste across any relevant extra information as a comment to the bug report being left open.