blob: fe520a185f7b63db8f67bd58a1cc72dbfd356019 (
plain)
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
97
98
99
100
101
102
103
104
|
= Design =
== Distributed Issue Tracking ==
The distributed issue tracking of Kwestie is designed such that each Kwestie
understands that other Kwestie systems exist and issues may need to hop from
one to the next.
Issues can be pushed upstream and downstream in order to be tracked by the
correct teams. In the distribution system of Red Hat a Kwestie issue tracking
system would work best in this kind of configuration.
Check out this ASCII art of the RH system of pulling from upstream and pushing
to downstream systems. Customers of Fedora (like BU Linux) and RHEL can be
running their own kwestie system if they are making local changes to the code or
distribution files. As each customer tracks their changes with Kwestie they
can forward issues upstream as the issue is realized to be an upstream issue
instead of an issue in their downstream system.
_________ __________
| | | |
| GNOME | | Kernel |
|_________| |__________|
\_________/
| |
| Fedora |
|_________|
_______/_ \__________
| | | |
| RHEL | | BU Linux |
|_________| |__________|
Technologies such as XML representations of issues on every kwestie allow for
pulling an issue from one kwestie to another. Each Kwestie system is an OpenID
provider and OpenID account consumer so that a user from a downstream Kwestie
can push an issue upstream without creating an account on the upstream Kwestie.
Likewise an upstream kwestie user can push an issue downstream without creating
an account (via OpenID) at the downstream kwestie.
== Email Interface ==
Kwestie make explicit use of an email interface. The email interface is
designed to provide the exact same functionality as the web interface.
There is an open email account for every kwestie, defaulted to issue@DOMAIN and
each issue has it's own individual email address of issue+ISSUE_GUID@DOMAIN.
When an email is received to the open address a new issue is created using the
subject for a title, the body for the description and all attachments as issue
attachments. If the person sending issue email to the open address does not
have an account with the Kwestie an account is initialize for them. An
initialized account requires activation which is done via email with an
activation link. A person needs to activate their account before their issues
become active on the Kwestie system, this is in hopes to prevent spam systems
from creating issues.
With an activated account the created issue is assigned to the default Track in
order to be processed by the users of the Kwestie system. The created issue
now has it's own unique email address. When a person replies to the issue email
address their reply is inclued as a comment to the issue.
Most people using an issue reporting system for the first time (or even first
few times) don't understand the complexities of the system and how issues are
processed. However most people in this circumstance _do_ understand how to use
email and reply to messages. Kwestie essentially acts as an email conversation
documenting system to the average user. As developers post questions to an
issue a customer can simply reply to the message sent and their reply will be
shown as a comment.
A common scenario is that a developer will ask for a type of log file from a
customer. Using an email interface the customer can simply reply to this
request with the log file attached to their email reply.
Because the email is unique and follows a pattern of issue+ID mail filters can
easily be created in most email clients.
== Tracks ==
Every issue often needs to be processed by a number of people before it can be
considered closed. In a software engineering environment with customers this
simplistic version of an exchange usually runs (and is designed in Kwestie to
run) like this.
-- Support Kwestie --
Issue Created By Customer (likely via the email address)
1st Line Support Group Receives and Processes Issue
1st Line Support Escalates Issue to 2nd Line Support
2nd Line Support Receives and Processes
2nd Line Support Escalates Issue to Engineering
-- Engineering Kwestie --
Engineering Receives and Processes Issue
Engineering Passes Issue to Engineering Sub Group
Engineering Sub Group Receives and Processes Issue
Engineering Sub Group Assigns Issue to Developer
Developer Triages Issue and Creates Fix
Developer Passes Issue Fix to Q/A for Testing
Q/A Tests Issue Fix and Declares Fix Ready for Release
-- Support Kwestie --
Customer Receives Issue Fix
Through out that scenario there is a lot of meta processing happening with
milestone and product tagging for project managers to understand trajectory and
priority of issues.
|
