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

• Inkscape Bugs - start bug management here.
• Inkscape Bug Team - you can apply for bug team membership here.

Bug status

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

• New: this bug was just reported, and it is not known whether it is reproducible. Try to reproduce this bug on your computer.
• Confirmed: this bug was reproduced and verified to be Inkscape's fault. You can work on tracking it down and fixing it.
• Triaged: a Bug Team member has verified the bug and assigned an importance to it. Inkscape developers accept that they will work to resolve the bug.
• In Progress: someone is working right now to fix the bug. Do not use this status to indicate that you are willing to work on a given bug, or that you will work on it some time in the future; only set it if you have actually started to work on a fix.
• Fix Committed: the bug is fixed in the development version (the lp:inkscape branch).
• Fix Released: the bug is fixed in the latest stable release of Inkscape. Also use this status for bugs that only appeared in the development version, and were never encountered in a stable release.
• Incomplete: not enough information was provided by the bug reporter to adequately identify or reproduce the issue. If nobody else encounters a similar problem, it will be marked invalid after some time.
• Invalid: this problem is not Inkscape's fault, or the reporter did not reply to requests for more information.
• Won't Fix: issue that will never be fixed in Inkscape due to design choices or because it is out of the scope of the program. An example might be a request for editing audio clips or rewriting Inkscape in a different language.

Bug importance

Importance reflects how serious is the bug.

• Critical: very serious incorrect behavior that will severely affect a majority of users. Examples: reproducible crashes after a common action; document data loss; document data corruption; severe regressions in functionality; build broken on more than one platform (Linux, Mac, Windows, other)
• High: serious incorrect behavior that is likely to affect a large portion of users. Examples: reproducible crash after an uncommon sequence of actions; other user data loss (e.g. preference file corruption); non-SVG-compliant output; SVG-compliant documents misinterpreted; incorrect file output; major memory leak; build broken on one platform only
• Medium: moderately serious incorrect behavior that is likely to affect many users. Examples: crash under very obscure or unlikely circumstances; user interface not adhering to standard guidelines; substandard quality of rendering; bad performance; minor memory leak; build issues on exotic but up to date platforms
• Low: quirk or deviation from expected behavior that may affect a small portion of users. Examples: minor rendering quirk; inconvenient placement of commands; inconvenient behavior or limitation of functionality of an existing command; bad performance during obscure operations; incorrect translation; build issues on outdated platforms
• Wishlist: lack of functionality that might might inconvenience some users. Examples: no autosave feature; export to exotic file format not supported; no drag and drop between Inkscape and Word

Tags

Tags assign bugs to categories related by subsystem, platform, or general area of functionality of Inkscape.

(TODO put list of official tags and description here)

Advice

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.