| 1 | = Design = |
| 2 | |
| 3 | |
| 4 | == Distributed Issue Tracking == |
| 5 | |
| 6 | The distributed issue tracking of Kwestie is designed such that each Kwestie |
| 7 | understands that other Kwestie systems exist and issues may need to hop from |
| 8 | one to the next. |
| 9 | |
| 10 | Issues can be pushed upstream and downstream in order to be tracked by the |
| 11 | correct teams. In the distribution system of Red Hat a Kwestie issue tracking |
| 12 | system would work best in this kind of configuration. |
| 13 | |
| 14 | Check out this ASCII art of the RH system of pulling from upstream and pushing |
| 15 | to downstream systems. Customers of Fedora (like BU Linux) and RHEL can be |
| 16 | running their own kwestie system if they are making local changes to the code or |
| 17 | distribution files. As each customer tracks their changes with Kwestie they |
| 18 | can forward issues upstream as the issue is realized to be an upstream issue |
| 19 | instead of an issue in their downstream system. |
| 20 | _________ __________ |
| 21 | | | | | |
| 22 | | GNOME | | Kernel | |
| 23 | |_________| |__________| |
| 24 | \_________/ |
| 25 | | | |
| 26 | | Fedora | |
| 27 | |_________| |
| 28 | _______/_ \__________ |
| 29 | | | | | |
| 30 | | RHEL | | BU Linux | |
| 31 | |_________| |__________| |
| 32 | |
| 33 | |
| 34 | Technologies such as XML representations of issues on every kwestie allow for |
| 35 | pulling an issue from one kwestie to another. Each Kwestie system is an OpenID |
| 36 | provider and OpenID account consumer so that a user from a downstream Kwestie |
| 37 | can push an issue upstream without creating an account on the upstream Kwestie. |
| 38 | Likewise an upstream kwestie user can push an issue downstream without creating |
| 39 | an account (via OpenID) at the downstream kwestie. |
| 40 | |
| 41 | == Email Interface == |
| 42 | |
| 43 | Kwestie make explicit use of an email interface. The email interface is |
| 44 | designed to provide the exact same functionality as the web interface. |
| 45 | |
| 46 | There is an open email account for every kwestie, defaulted to issue@DOMAIN and |
| 47 | each issue has it's own individual email address of issue+ISSUE_GUID@DOMAIN. |
| 48 | |
| 49 | When an email is received to the open address a new issue is created using the |
| 50 | subject for a title, the body for the description and all attachments as issue |
| 51 | attachments. If the person sending issue email to the open address does not |
| 52 | have an account with the Kwestie an account is initialize for them. An |
| 53 | initialized account requires activation which is done via email with an |
| 54 | activation link. A person needs to activate their account before their issues |
| 55 | become active on the Kwestie system, this is in hopes to prevent spam systems |
| 56 | from creating issues. |
| 57 | |
| 58 | With an activated account the created issue is assigned to the default Track in |
| 59 | order to be processed by the users of the Kwestie system. The created issue |
| 60 | now has it's own unique email address. When a person replies to the issue email |
| 61 | address their reply is inclued as a comment to the issue. |
| 62 | |
| 63 | Most people using an issue reporting system for the first time (or even first |
| 64 | few times) don't understand the complexities of the system and how issues are |
| 65 | processed. However most people in this circumstance _do_ understand how to use |
| 66 | email and reply to messages. Kwestie essentially acts as an email conversation |
| 67 | documenting system to the average user. As developers post questions to an |
| 68 | issue a customer can simply reply to the message sent and their reply will be |
| 69 | shown as a comment. |
| 70 | |
| 71 | A common scenario is that a developer will ask for a type of log file from a |
| 72 | customer. Using an email interface the customer can simply reply to this |
| 73 | request with the log file attached to their email reply. |
| 74 | |
| 75 | Because the email is unique and follows a pattern of issue+ID mail filters can |
| 76 | easily be created in most email clients. |
| 77 | |
| 78 | == Tracks == |
| 79 | |
| 80 | Every issue often needs to be processed by a number of people before it can be |
| 81 | considered closed. In a software engineering environment with customers this |
| 82 | simplistic version of an exchange usually runs (and is designed in Kwestie to |
| 83 | run) like this. |
| 84 | |
| 85 | -- Support Kwestie -- |
| 86 | Issue Created By Customer (likely via the email address) |
| 87 | 1st Line Support Group Receives and Processes Issue |
| 88 | 1st Line Support Escalates Issue to 2nd Line Support |
| 89 | 2nd Line Support Receives and Processes |
| 90 | 2nd Line Support Escalates Issue to Engineering |
| 91 | -- Engineering Kwestie -- |
| 92 | Engineering Receives and Processes Issue |
| 93 | Engineering Passes Issue to Engineering Sub Group |
| 94 | Engineering Sub Group Receives and Processes Issue |
| 95 | Engineering Sub Group Assigns Issue to Developer |
| 96 | Developer Triages Issue and Creates Fix |
| 97 | Developer Passes Issue Fix to Q/A for Testing |
| 98 | Q/A Tests Issue Fix and Declares Fix Ready for Release |
| 99 | -- Support Kwestie -- |
| 100 | Customer Receives Issue Fix |
| 101 | |
| 102 | Through out that scenario there is a lot of meta processing happening with |
| 103 | milestone and product tagging for project managers to understand trajectory and |
| 104 | priority of issues. |
| 105 | |
