How to make good tickets?

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 in such case:

• 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 on the wiki of your component.

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.