Difference between revisions of "Bug Reporting Workflow"
Jump to navigation
Jump to search
(Created page with "== Issue Description == 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...") |
|||
| Line 1: | Line 1: | ||
== Issue Description == | == Issue Description == | ||
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 [https://bugs.launchpad.net/inkscape is still on launchpad]. As of February 22, 2018, there are 4748 open and 1826 new bugs listed. | * 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 [https://bugs.launchpad.net/inkscape 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 [https://inkscape.org/en/contribute/report-bugs/ web page that describes the process]. Bryce has written up [https://gitlab.com/inkscape/vectors/general/uploads/5fd013b6e716f16ccc85f8620d49bbdf/friendly_feedback.txt a possible, ideal scenario for a bug workflow for Inkscape]. | * 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 [https://inkscape.org/en/contribute/report-bugs/ web page that describes the process]. Bryce has written up [https://gitlab.com/inkscape/vectors/general/uploads/5fd013b6e716f16ccc85f8620d49bbdf/friendly_feedback.txt 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. | * 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 new developers, due to the amount and the missing categorization. | * 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. | |||
Some work on [https://github.com/doctormo/lpout 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 metadate from launchpad works. A test account for adding new reports to GitLab has been established. | * 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 [https://github.com/doctormo/lpout 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 metadate from launchpad works. A test account for adding new reports to GitLab has already been established. | |||
== Resources == | == Resources == | ||
| Line 24: | Line 26: | ||
== Questions == | == Questions == | ||
=== Bug report organization === | === Bug report organization === | ||
* Should bug reports and feature requests be kept in the same location? | * Should bug reports and feature requests be kept in the same location? | ||
* Should there be separate places for unfiltered user requests (bugs and feature requests) and bug reports that are ready for a developer to take on? | * 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? | ||
| Line 38: | Line 37: | ||
* 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 report)? | ||
* 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 | |||
* How could we encourage more contributors to help with such a pre-triage path? | |||
Revision as of 01:22, 22 February 2018
Issue Description
- 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 metadate from launchpad works. A test account for adding new reports to GitLab has already been established.
Resources
Questions
Bug report organization
- 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?
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)?
- 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
- How could we encourage more contributors to help with such a pre-triage path?
Location/transfer of bug reports
- 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