See: https://tiki.org/Wishlist-Triage-Team#Who
What do coordinators do?
Below are some some explanations for usage of fields not on
How to Submit a new item on the Wishlist
Open: Needs some love – No decision made yet
Pending: Fix is on the way but not yet in a stable release OR there is another issue.
Closed: Solved and available in latest stable release OR will not be fixed / is rejected / etc.
Add points (+1 or +2) to bugs which have affected you and to features which you would find useful. You can also vote -1 or -2 to bugs which bugs you can't duplicate and to features which would be a waste of developer time. This will help us all.
Don't assign to other people unless you think they agree.
Only check one if it feels logical. This is not really used at the moment.
This is used to regroup tracker items into larger project. Think "big picture"
First phase - update the tracker structure
Second phase
Third phase
The main idea mostly is to have a first line of support (guys there are not really experts, but can make some basic decision and channel the tickets to the rigth place), they handle the first contact, tries to resolve as much as possible to let the 2nd (more experienced supporters) and the 3rd line (programmers, area specialits, etc) work on only what they are really good at. This structure usually enables to respond to and resolve any request in a timely manner.
Of course Tiki is not a company and the community is not a servicedesk, so it should be a bit different, no complicated SLA or other things, but maybe we can incorporate some of those practical and proven ways and maybe follow some guidelines of ITIL.
Tiki should attract more "1st line supporters" who would like to do something but don't know the code and the implication on coding hours on the requests. 1st line could be a group where folks can volunteer (subscribe to group). The rest of the lines is not so open in order to avoid ticketing becoming a mess.
Tickets are always assigned to a group than the current groupleader (can be rotating every week/month/etc) would assign the ticket to a member of that group. A ticket should always be assigned to a person in the end. If the member does not want to deal with the issue, he can put it back to the group pool or assign to another group.
Instead of what we have now (Report type) we should introduce basic ticket types, such as:
incident | for something that is not working as expected. open for anonymus/registered users?. (it can be a bug or incorrect usage of the feature). Can turn into a simple usage question, or a bug/problem/request | |||
request | (sometimes also called as IMACs) things are working fine but I want to Install/Move/Add/Change something. Open for registered users | |||
problem | for recurring incidents are collected under a problem ticket. Wishlist squad members can open. It can be fixed or closed as a known error (something we know of but we wont fix, for example at older releases) |
Having these basic types makes reporting and channelling easier.
After the ticket type selection should come the categorization itself. (bug subtypes, etc).
Here should we have what is now "report type"
The problem here is that there is no "dependency" possibility in trackers (yet). I mean that if "Incident" is ticked that only those category options should appear that are dependent on the "Incident" checkmark to be ticked. I am thinking about the way the main administration option as working now in tiki - only when you put a checkmark into the box the related further options appear.
Category system is usually 2-4 levels deep. Tiki is quite complicated, so the depth should be discussed.
An example:
Field name | Description | Field type | Input type | Example
|
Category | The top level | drop-down | manual selection | Tiki Feature |
Subcategory | The level below category | drop-down | manual selection | Forums |
Area | The level below subcategory | drop-down | manual selection | Forum post |
Detail | The level below Area | drop-down | manual selection | Posting error |
The above mentioned dependency logic should be applied for the category selection too (if I select a category only those subcategories should be available that are defined as subcategories of that given category)
Queues are the place where you keep the tickets while they are being worked on
Groups monitor the Queues (usually a queue has a default group that is primarly responsible for the tickets in the group).
Users are members of the groups and have access to the queue through group membership
Concept of queues is sometimes hard to grasp, but it is handy, you can also define permissions for queues, manage better the workload, etc.
Proposed queues
|
|
Proposed groups To avoid duplication see here: http://tiki.org/Teams Wishlist should use the same! |
There are checkboxes to indicate the affected Tiki release, which is fine
Tickets usually have the following path*ML: Looks like a job for category transitions :
First contact resolution percentage is an important metrics of an effective helpdesk. If it is high it means that the info is distributed well, easy to find and understand for non-technical guys
Status name | Old status name | Description | Can arrive from | Can go to |
New | - | This is the status upon first save | - | Open - Accepted Pending - Information %% Pending - User test |
Open
| ||||
Open - Accepted | Accepted | The wishlist team reviewed and the ticket seems to address a valid issue. Mainly to rule out invali | Open - New, Pending - Information | Open - confirmed |
Open - Confirmed | Confirmed | The issue is confirmed | ||
Open - Work in Progess | Fix on the way | The ticket is being worked on by the responsible team | ||
Pending
| ||||
Pending - Information | Not enough information | Not enough information provided to continue with the resolution | ||
Pending - Postponed | Later, Postponed | issues that are accepted but no resource to work on | ||
Pending - User test | Please retest | The ticket seems to be resolved, the users should test. | Resolved statuses | Closed or back to the dispacth group |
Pending - Review | Remind | The ticket is pending too long, it should be reviewed | ||
Resolution
| ||||
Resolved | Fixed | The responsible team beleives the issue is answered/fixed, needs confirmation from the ticket opener before closed | ||
Resolved - Refused | - | The issue is refused, it will not be done for whatever reason (it is against the tiki policy, no time, no volunteer) | Closed - Refused | |
Resolved - Works fine | Works For Me | The issue could not be reproduced, it seems to be ok | ||
Resolved - Duplicate | - | Closed - Duplicate | ||
Resolved - Known error | Won't Fix | The issue is a known errow, which means that it is acknowledged but will not be fixed due to lack of time, volunteers, etc | Closed - Known error | |
Resolved - Refused | - | The issue is refused, it will not be done for whatever reason (it is against the tiki policy, no time, no volunteer) | Closed - Refused | |
Closure
| ||||
Closed | - | The issue is answered/fixed and it is accepted | Resolved | -
|
Closed - Works fine | - | See above | Resolved - Works fine | -
|
Closed - Out of Date | Out of date | for really old tickets | Resolved - Out of Date | -
|
Closed - Duplicate | Duplicate | The ticket is a duplicate, must reference the the other ticket | Resolved - duplicate | -
|
Closed - Known Error | - | See at resolved, we wont fix this and that is for sure | Resolved - Known error | -
|
Closed - Won't do | Invalid, Rejected | The ticket was found to be invalid | any | -
|
Wishlist squad reviews new tickets and correct the incident/request setting when necessary
Notes about ticket resolution & closure
Resolution when the person responsible for resolution thinks that he/she resolved the issue. This always needs a confirmation from the person who opened the ticket
Closure the person who opened the ticket confirms the resolution.
Usually the idea is to always send out a resolution email notifying user of the that we think his/her issue is resolved and also stating unless he/gets back to us within i.e 5 working days we consider the resolution to be accepted and close the ticket with the appropriate closure code.
Closed tickets can never be reopened, they are archived. Maybe a new ticket is opened later with the same issue, the 2 tickets should be linked together as can be identified as a problem (=recurring incident)
I think following some of these points could make Tiki also to a good support system, since it has all you need to make good support, integrated wiki & forum & ticketing, you don't often have that (and this could be offered as a profile too)
ML: Do you have list of feature requests / bug fixes to make this happen? (vs just reconfiguring).
pascalstjean: After reviewing the current bug reporting tool; I have been interested in creating a step by step bug submitting tool that will allow us to identify who is actually submitting the bug (Developer, User, Manager etc...) Being able to put the person who is reporting the bug in context is extremely important, we as a group will be able to better organize these bugs and hopefully take action.
I hope to be able to work on this tool over the next few months by refactoring the current categories and options found in the Bug Report. I was really intrigued to create this tool using the same technique that CGCom has done using Pretty Trackers for some of their customers.
Once I have a working prototype I will present it to the community for comment and hopefully get some good feedback. If anyone has opinions or other types of idea's that you have please feel free to get in touch with me. I'd love to hear your comments and concerns about the current Bug submitting process.
SEWilco: The categorization section above might be able to use Dynamic items list.