How to make good tickets?

What is a ticket

Tickets are units of worked that we agree upon in the team.

We use them to organize our work meetings and communicate our ideas amongst each other. Therefore:

• tickets should be understandeable, see below.
• tickets should be not be to big or too small; about three tickets per personweek is enough
• tickets are often shared between multiple people
• 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

Tickets always have a description that explains for all team members to understand:

• Motivation: why or for whom do we do this? For example?
• Expected output: what will we have in hand when the tickets is closed?
• (Optional) what is the plan of actions to achieve it.
• (Optional) how do we measure this output. For example a 'test case'.

Please use the discussion mechanism to log your progress on the ticket.

For example: For medgen and bbmri (=for whom): we compare imputation methods Beagle, Impute and MACH to the percentage correctly estimated SNPs (=output). We take existing genotype data from 1M arrays and split the data randomly in two. The first half we input into the impute methods. Then we calculate percentage correctly estimated SNPs on the other half for each method (=actions).

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.