Issue tracker guidelines
The project backlog is a special milestone that never ends. The user stories does not need to be tangible yet.
Sprints and sprint-logs
Each sprint is created as milestone with a specific deadline. When the sprint is started tasks are not reassigned from the backlog but is created anew and given estimate and priority.
A task is created as an issue. A task must never be without a proper description, priority and complexity estimate.
Internally we divide the tasks as programming and research tasks. Programming tasks should have a technical description (aimed at the developer) and a user story (aimed at the product owner). Research tasks should have a technical description (aimed at the developer) and a research goal (aimed at the product owner) that describes what the product owner will get as result of the task (usually a report with some contents) and why the task is necessary (what are we able to do after completing this task)
The task priority is configured by adding one of the labels prefixed with "Priority: "
The task complexity estimate is configured by adding one of the labels prefixed with "Complexity: "
The task status is configured by adding one of the labels prefixed with "Status: ". A task is implicitly started by assigning it to a sprint. Tasks are completed by the programmer by marking the task with "Status: resolved".
When a task is checked out it is done by assigning the task to a team member.
The bug label is a special label so that it fits everywhere. Implicitly the task/story is a feature if not a bug ;)
Done and Done done
Programmers specify when a task is done by labeling it "Status: resolved". The product owner accepts that a task is finished by closing the issue, the task is now "done done".