Difference between revisions of "Bug Reporting Workflow"

Latest revision as of 11:03, 21 May 2024

This page is outdated. It is kept for historical reasons, e.g. to document specific decisions in Inkscape development.

After the Inkscape project's move to GitLab for the hosting of its source code repository (and various other repositories), the project's bug tracker is still on launchpad. As of February 22, 2018, there are 4748 open and 1826 new bugs listed.

Users are usually not guided in making their bug reports/feature requests, resulting in many unclear bug reports, duplicate reports and insecurity of what to do for the users, probably also in some bugs going unreported. There is no template, or a step-by-step instruction on launchpad for the minimum requirements of a good report. There is a web page that describes the process. Bryce has written up a possible, ideal scenario for a bug workflow for Inkscape.

To report a bug, one needs to have an account on launchpad. The registration process for a launchpad account (via Ubuntu One) can seem deterrent to a user.

Bug reports are not currently systematically triaged, tagged, labelled or otherwise sorted. They can go unanswered completely. Feature requests and bug reports, as well as some usage errors and questions all end up in the same place, which in its current state is not welcoming to users nor to (possible new) developers, due to the sheer amount and the missing categorization. Launchpad provides a system to label feature requests as 'wishlist' items, and to add various kinds of tags to an issue.

There is a group of people who check new reports and try to help where they can, but they are not organized as a team, and not all of them seem to have permission to change a bug's importance or to milestone it for a specific release.

Several developers on the mailing list have expressed a wish to return to the pre-launchpad system of having separate places for bug reports and feature requests. If such a separation is established, there is an agreement that it's necessary to allow for easy moving of issues between the two trackers.

The disconnect between reports and code work makes it more difficult for developers to know about new bugs or to engage a possibly interested developer in the discussion about a bug. It also makes it harder to keep the bug tracker updated. Automatted closing of bug reports via commit message is no longer possible.

Some work on moving bug reports from Launchpad to GitLab has been done, but has been given up due to the impossibility of attaching bug reports to non-existing users on the new platform. This would mean they do not get a message anymore when their report is worked on by someone, or someone has a question, but they would need to resubscribe. Extracting reports and metadata from launchpad works. A test account for adding new reports to GitLab has already been established.

Bryce's proposed organizational diagram

Should bug reports and feature requests be kept in the same location?
Should there be separate places for unfiltered user requests (bugs, user questions and feature requests) and bug reports that are ready for a developer to take on?

Should we establish a pathway for 'normal' users to get help in formulating their bug reports (and determining if their request actually is a bug)?
How could the technical implementation of such a pathway look?
Is there a software available that already fulfills those needs?
- should be connectable to GitLab
- could this just be a third gitlab tracker?
- as a last resort, write our own

Where does the Inkscape project want to host its bug reports?
- continue hosting at Launchpad
- move them to GitLab
- move them to a self-hosted site (then: which bug tracking program to use?)
- move them to ...

If bug reports will be transferred, how will this be done?
- Transfer all bug reports, inform users on launchpad programatically where their issue has been moved to
- Sift through the reports on launchpad, test them, and only move relevant bug reports manually. Inform users on reports deemed irrelevant to open up a new report in new location if they think the decision was wrong.
- ... something else

@@ Line 1: / Line 1: @@
+ {{Outdated}}
 == Issue Description ==
@@ Line 21: / Line 22: @@
 ''[https://sourceforge.net/p/inkscape/mailman/inkscape-devel/thread/97cab7ef-a1f8-e995-3a0a-947f4760724d%40gmx.de/#msg36195892 Related Mailing list discussion]''
-''[https://gitlab.com/inkscape/vectors/general/issues/23 Related Vectors Team discussion]''
+''[https://gitlab.com/inkscape/vectors/general/issues/23#note_53572757 Related Vectors Team discussion]''
 [[File:Possible user feedback workflow.png]]<br> Bryce's proposed organizational diagram
@@ Line 36: / Line 37: @@
 === Bug reporting pathway ===
-* Should we establish a pathway for 'normal' users to get help in formulating their bug reports (and determining if their request actually is a report)?
+* Should we establish a pathway for 'normal' users to get help in formulating their bug reports (and determining if their request actually is a bug)?
 * How could the technical implementation of such a pathway look?
 * Is there a software available that already fulfills those needs?
@@ Line 44: / Line 45: @@
 * How could we encourage more contributors to help with such a pre-triage path?
 === Location/transfer of bug reports ===