Hey all, recently we came up with a short manual on how to create tickets for developers properly. And by ‘properly’ I mean in a way to save time for unnecessary communication and analyzing the text. We found it very useful and wanted to share with you:
ISSUE CREATING RULES:
– Subject should be self-explaining e.g. contain general state of what is this issue about.
– Set up priority (don’t keep more than three tasks with similar priority).
– Set up status if this is important for the developer.
– Always set up due date if there is a due date for the task.
– Always set up Estimated time if the task was already estimated.
DESCRIPTION STRUCTURE:
– Short general description of what functionality does.
– Description of the problem (if the issue is a fix)
– Possible solution (if proposed or agreed with client). This could be a plugin, module, api, direct web development suggestion.
DESCRIPTION STYLE:
– If issue is a new feature than p.1 from description structure is mandatory (2 and 3 are complementary). If issue is a fix then p1 and p.2 are mandatory (p.3 – complementary)
– The style should be describing, not copy-pasted from client’s words.
– include client’s direct speech if you are not sure if you understood the point right. If you include client’s direct client’s comment start it with ‘Client’s comment: …’
– Please make sure that developer could understand what exactly to do in the issue.
Maxim Brynza, CEO, Bineks
