1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
|
# Bugtracking
## Introduction
Yokadi comes with a set of commands tailored to help you track bugs. These
commands are `bug_add` and `bug_edit`. They are similar to `t_add` and `t_edit`
except they will ask you a few questions to help you decide which bug to fix
next.
## Entering a bug
Enter a new bug like you would enter a new task:
bug_add fooplayer Fooplayer crashes when opening a .bar file
Before adding the task to the project "fooplayer", `bug_add` will ask you the
severity of the bug:
1: Documentation
2: Localization
3: Aesthetic issues
4: Balancing: Enables degenerate usage strategies that harm the experience
5: Minor usability: Impairs usability in secondary scenarios
6: Major usability: Impairs usability in key scenarios
7: Crash: Bug causes crash or data loss. Asserts in the Debug release
Severity: _
Enter 7 here, this is a crash. Now `bug_add` wants to know about the likelihood
of the bug:
1: Will affect almost no one
2: Will only affect a few users
3: Will affect average number of users
4: Will affect most users
5: Will affect all users
Likelihood: _
.bar files are quite uncommon, enter 2 here. We reach the last question:
bug: _
This last question is optional: `bug_add` wants to know the id of this bug.
This is where you can enter the Bugzilla/Trac/Mantis/... id of the bug. If you
just noticed this bug and have not yet entered it in a centralized bug tracker,
just press Enter. Yokadi will now add a task for your bug:
Added bug 'Fooplayer crashes when opening a .bar file' (id=12, urgency=40)
If you edit the task with `t_edit 12` you will only be able to fix the task
title. To be asked for severity, likelihood and bug id again, use
`bug_edit 12`.
## What's next?
Based on the severity and likelihood, Yokadi computes the urgency of the bug.
The formula used is:
likelihood * severity * 100
urgency = -----------------------------
max_likelihood * max_severity
This is based on the concept of "User Pain", as described by Danc here:
<http://lostgarden.com/2008/05/improving-bug-triage-with-user-pain.html>
Now, when you list your tasks with `t_list`, the most urgent tasks will be
listed first, making it easy to fix the most important bugs first.
## Behind the scenes
Likelihood, severity and bug are stored as Yokadi keywords (Yokadi keywords can
be associated with an integer value).
The bug urgency is computed from likelihood and severity, then stored in the
task urgency field. Yes, this means there is duplication and you may get
likelihood/severity and urgency out of sync if you manually adjust urgency with
`t_set_urgency`. In practice, I found it was not a problem.
## Tricks
Here are a few tricks I came up with while using Yokadi to do bug tracking:
- List all crashers: `t_list fooplayer -k severity=7`
- Make use of Yokadi keywords. For example I often use:
- backport: I should backport the fix when done
- i18n: This bug requires translation changes, better fix it before i18n freeze
- patch: This bug as an attached patch (You can paste the patch in the bug
description with `t_describe`)
- Find a bug by id: `t_list fooplayer -k bug=12`
- I often keep two projects in Yokadi, one for the stable release, another for
development. For example I have `yokadi_stable` and `yokadi_dev`.
<!-- vim: set ts=4 sw=4 et: -->
|
