= How to make good tickets? =
[[TOC()]]

== What is a ticket? ==

Tickets are '''units of work''' that we agree upon in the team. 
We use them to lead our work meetings and communicate our ideas amongst each other. 

Therefore:
* tickets should be understandable by all, see below howto.
* tickets should be not be to big or too small; about THREE tickets per personweek is enough
* tickets are often shared between multiple people
* tickets can be moved from one milestone to another so they can be big (so don't duplicate them) but not too big, see below howto.
* tickets can have links to wiki pages or other tickets. Please use that in particular if you work from a Design
* tickets have a discussion option, plz use that to discuss actions and results while the ticket progresses.
* if you have many small todos, please put them in ONE extra ticket so we can still discuss them during work meeting.

== What makes a good ticket? ==

For a good ticket you can easily answer the following questions: 

When the ticket is new:
* Motivation: '''Why or for whom''' do we have this ticket? For example: for LifeLines.
* Scope: What is the '''expected output''' to close this ticket? For example: wiki page, Excel file, Working demo, Unit test, etc.

When the ticket is worked upon:
* Actions: What are we '''planning to do to''' produce the expected output? For example: interview, program, design, statistical test, etc.
* Evaluation: What are the '''criteria of succes''' on which we (or the customer) decides the outcome is good enough? For example: evaluated by person X, test-case passed, presented at meeting X.

Please use the discussion mechanism to have discussions on the actions. It is like a forum :-)

== Size of tickets? ==

If you can't easily answer the questions above for your ticket is probably too big!

In that case it needs to be in a chain of smaller tickets, and the first ticket is than to answer all these questions.
For example: 'Design a user interface for LIMS' is way too big. Expected evolution of your tickets:
* Ticket 1: 'Create a mock-up for lab data-entry based on protocols'. Expected output is a wiki page with the mock-up that has been evaluated with Morris and/or team members.
* Ticket 2: 'implement user interface for lab data-entry based on protocols'. Expected output is a working demo of (link to output of ticket 1 here) + manual that has been evaluated with Morris and/or team members.
* Ticket 3: 'User test interface for lab-entry'. Expected output is a log on where the user had trouble. Typical result may be that Ticket 2 is reopened for improvement..

Implicit in above is: the code is commited to SVN and there is a manual.



== Ticket types ==

Currently we have four flavors of tickets:

=== defect ===
A defect is a known error in our code base. Therefore the ticket MUST describe what you need to do to reproduce the defect.
ExpeIf possible you will first create a UnitTest that shows the bug so that it can never come back without us knowing.

{{{
To reproduce the defect:
1. checkout molgenis and molgenis_test
2. generate code
3. run handwritten/tests/TestThisBug.java

The error log is as follows:
<paste of error log>

}}}

=== Enhancement ===


'''todo''' - these are actions that don't produce code but something else. For example: an excel with quality scores for each NGS lane.