Submitted by aklis on Fri, 03/06/2015 - 00:36
Revision of bugtracker-proposal from Fri, 03/06/2015 - 20:54
The revisions let you track differences between multiple versions of a post.
Trisquel bug workflow proposal
After the last development meeting, we ackownledged to revisit the workflow used in the bugtracker. This is my idea, feel free to add any comment or question.
This is a quick draft of my idea, with the new fields and a brief description, so we have something to start with.
Projects
- Trisquel: Confirmed trisquel bugs
- Webs: Issues related with web usages, not only for the main trisquel.info site but also for devel.t.i and others
- User support: Bugs that don't need any code change, only user configuration/guide. Should be limited to cases where a new package version is not needed.
Categories
- Problem: In case of doubt, the default category
- Bug: Confirmed bug
- License problem: Problem with
- Feature: Improvement over current situation (importing packages from ppas, improve docs...)
- Branding: Branding issue
- Upstream: Bug assigned to upstream to be fixed, expected to reach trisquel on next upstream version. There should be a link to the upstream bugtracker
Components
- Trisquel: packages in the default trisquel install
- Trisquel Mini: packages in the default trisquel-mini install
- Sugar: trisquel sugar packages (TOAST)
- Installer: Problems with the installer, or installation issues
- Packages: issues with packages not in the default install, but in trisquel repos
- Abrowser: abrowser related bugs (I think it needs it's own component...)
- Translation:
- Documentation:
Status
- New: First status to be used
- Confirmed: set by other user, not the author. For most software bugs, in order to set it the description or comments have to include:
- source package and version
- steps to reproduce
- expected result
- obtained result
- WIP: someone is tracking it down
- Patch ready: Patch is ready and merge request was sent in devel.t.i
- Duplicate: There is another bug reported, remember to set the id of the original bug
- Fixed: There was an action from our part
- Closed: There wasn't any action from our part
Bug priorities
- minor: doesn't affect common usages. Branding bugs should have this priority
- normal: obtained result is different from the expected one
- critical: normal usage is not possible
- regresion: Used when something that was working before, is now broken. It needs to have previous package version, and buggy one
Sample run
Using https://trisquel.info/en/issues/13379 as example
Stage | Project | Category | Component | Status |
1st | Support | Feature | Trisquel | New |
2nd | Trisquel | Bug | Confirmed | |
3rd | WIP | |||
4th | Patch ready | |||
5th | Fixed |
(Some of those states/stages could be avoided, but are shown here for clarity)
Questions
Add your own, this is a wiki ;)Revisions
03/06/2015 - 00:36