Real time Tiki ticket statistics

Who

See: https://tiki.org/Wishlist-Triage-Team#Who

What do coordinators do?

• Click here to monitor all changes to the wishlist You will get quite a few emails. You can turn off later.
• Check all new submissions. (people use Make a wish and read How to Submit a new item on the Wishlist so make sure these pages are always clear.
  • Add any missing categories
  • Assign to people who have expressed that they want to maintain feature X or Y or who have caused the bug
• If there is a security issue reported, make sure it doesn't disclose the vulnerability until a patch is issued.
• Invite people to contribute directly to Tiki source code, especially if people submit a patch
• prepare next version

Below are some some explanations for usage of fields not on
How to Submit a new item on the Wishlist

Status

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.

Rating

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.

Resolution status

• Accepted
• Confirmed
• Duplicate
• Fix on the Way
• Fixed
• Invalid
• Later
• Not enough information
• Out of Date
• Please retest
• Postponed
• Rejected
• Remind
• Won't Fix
• Works For Me

Assigned to

Don't assign to other people unless you think they agree.

Areas

Only check one if it feels logical. This is not really used at the moment.

Related project

This is used to regroup tracker items into larger project. Think "big picture"

• AdminUIRevamp
• Edit User Interface Revamp
• Infrastructure Revamp
• TwoRevamp

Ideas to improve the process

Ticket rewamp phases

First phase - update the tracker structure

• introduce ticket types as described below
• make group assigment available (in line with community group structure)
• rename resolution status to "status"
• rename report type to "category"

Second phase

• rework prioritization principles
• introduce queues as described below
• Review and update tickets > all ticket should be put into a ticket type, in a queue, assigned to a group and have a status
• revise categories > create at lease top level and one sublevel
• refine groups

Third phase

• we'll see..

About ticketing in general

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.

About ticket ownership

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.

About ticket types

Instead of what we have now (Report type) we should introduce basic ticket types, such as:

Having these basic types makes reporting and channelling easier.

About ticket categorization

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:

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)

About queues, groups and users

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.

About Tiki Release indication

There are checkboxes to indicate the affected Tiki release, which is fine

Ticket statuses & status flow

_{Tickets usually have the following path*ML: Looks like a job for category transitions :}

• ticket opened by customer or servicedesk 1st line staff
• servicedesk 1st line tries to make a first contact resolution and close the ticket

_{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}

• if 1st line can't resolve, first it tries to collect as much info (symptoms/description) as possible to help the work of 2nd line. For certain type of tickets/categorization you define the necessary miniumum information (mandatory fields), they can have certain templates assigned. Where to dispatch than is decided by the rules associated to the type&category combo of the ticket.
• Dispatch goes to a queue (which has a default group), not to person
• if 2nd/3rd line finds the categorization right than first it accepts (it is an event), than one group member "takes" it and starts working. When he thinks the ticket is resolved it goes back to the 1st line who is taking care of the confirmation/closure
• if 2nd/3rd line dont find the dispatch (assignment) correct, send it back to 1st line or if assigns to the correct group

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)

About trackers

• it is slow
• maybe closed tickets could be archived&moved into another tracker with the same structure, maybe it would speed up the whole thing
• the fields would need a bit of restructuring, will attach a sample soon
• maybe rename "trackers" to "forms", I think it is a better name for marketing too, more easy to understand for newcomers what it is all about. ("Tiki has a built in forms builder, structure your information as want, etc")

About priorities

Ease Importance Priority

Mid term goal

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).

Other ideas

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.

Alias

• WishList squad