3.1. Tickets
Contents
3.1.1. General
This page talks about how we manage the tickets/issues/tasks/defects.
For now we are using GitHub Issues for managing tickets.
When working on something, that something should have an associated issue in GitHub.
A GitHub issue is opened when some work needs to be done, a problem is found or someone has an idea about a new feature or how to improve something.
The ticket workflow is described in a computer friendly manner here: https://gist.github.com/adiroiban/c1991d524cc5e14d27b4
Try not to upload attachments to tickets.
For text files, try to use the descriptions or create a dedicate wiki page.
For logs, errors, long code samples from test reviews, use gist.github.com.
For pictures and other non/text data, you can attach these as a last resort.
It is ok to attach screenshots as a last resort but always try to describe the issue in a way where the screenshot is not really required and where you can report a text log or text error.
When you start working at a task, you can optionally accept that task and the task will be considered ‘in work’. At any given time, a team member should not have more than 3 ‘in work’ tickets.
When creating a ticket you can set yourself as the owner if you are implementing the task.
3.1.2. Work priority
Below is the list of priority order for work items. Top of the list is top priority:
Critical tickets should be solved first.
Support tickets. It is known that nobody likes them, but keeping customers happy is one of our main goals, and apart from that, support contracts are covering a big part of our income.
Your ticket that passes the review and requires to be merged.
‘Need review’ tickets which require your review.
Your ticket that did not pass the review.
Bugs for active milestone
Tasks from active milestone with ‘High’ priority.
Task from active milestone with ‘Normal’ priority.
Any other ticket from ‘Important’ report.
If you ran out of tickets, you discuss with the team to assign a new ticket or to add a new ticket to the current milestones.
3.1.3. Support tickets
THIS SECTIONS NEED EXPANSION.
Tickets related to support issues should contain the following information in description:
* The customer name
* Affected products
* Version of each affected product
* Operating system version and architecture
3.1.4. Bug / Defect reporting
We have multiple bug levels:
Those found after a need-review request, but before the code reaches the master. Developer to get full blame.
Those found in master, but not in a release. Developer and Reviewers get internal team blame.
Those found in a release version. Developer and Reviewers get the blame, product get public blame.
Level 1 are reported as review comments and needs-changes and they don’t need separate bug reports.
Level 2 are reported as bug tickets with high priority and assigned to the in work milestone, as they should be fixed ASAP. They are also release blocker.
Level 3 can be reported by QA or support team. QA team will report them just like Level 2 bugs. The developer who analyzes the bug and finds that it is a Level 3 bug, will mark it as a bug and set it’s priority to critical.
Support team can also report level 3 bugs, after receiving a report from the customer and reproducing it.
When closed, Level 3 bugs will also have an associated release note.
3.1.5. Ticket details
3.1.5.1. Ticket triage
Read Launchpad Bug Triage page for some general information: https://dev.launchpad.net/BugTriage
In GitHub, we do not allow external parties to add tickets, so we do an initial triage process at the same time when we add a bug (we choose component, priority… and sometimes milestone)
3.1.5.2. Ticket types
Task - are the usual/normal internal tickets.
Story - User stories - are high level tasks describing features which we want for our product
Bug - are defects detected by us or by end users.
3.1.5.3. Assigning priorities
In Chevah tickets usually have a priority value of ‘’’High’’’ or ‘’’Low ‘’’. All tickets that are ‘’’undecided’’’ should get a Low priority. Critical are for very special cases when someone is dying and we can help with an action in the next days, otherwise the priority for such cases can be ‘’’High’’’.
When we ran out of ‘’’High’’’ priorities we can re-evaluate tickets with ‘’’Low’’’ and change some of them to ‘’’High’’’.
3.1.5.4. Ticket Labels
We don’t use free form keywords or tags for tickets. Only set keywords are really required. Below is a list of used tags:
tech-debt
Any task that should have been done in the past, but was postponed
Technical debt should be ‘payed’ as soon as possible since the longer it takes to ‘pay’ them, the bigger the cost is.
For more information about the subject start by looking here: http://en.wikipedia.org/wiki/Technical_debt
easy
These are tasks that don’t require knowledge of the product or operating system ‘know-how’ in advance.
3.1.6. Milestone planning
At the start of each cycle, we create a milestone that represents our focus for the next month or week. We add new tickets to the new milestone.
Milestones can be next-release, followed by Y-Near-Future, Z-Long-Term.
Milestones associated with a release are also included.
Until the all tickets from the milestones/sprint are done, we should not work on any other task/ticket. If we start working on something, that something should be added to the current milestone.
If new tasks/tickets are required, they are discussed with the team and if they are important they are added to the current milestone. If the milestone is already full, adding a new ticket might imply removing an already planed ticket.
3.1.6.1. How not to be turned down by the big amount of opened bugs ?
In the Chevah project, we add a bug for each action we consider should be done to improve the project state.
Adding a ticket is easy and quick, while closing a ticket is hard and slow :) This will cause the accumulation over time of a big number of opened tickets.
3.1.6.2. Horse’s Easter and Near Future
The ‘Horse easter’ milestone is used for all long term tickets. Many of the tickets will be added to this milestone at the time of creation.
You don’t need to bother about these tickets and most of the time they can be ignored.
Same for ‘Near future’ milestones.