Creating Tickets and Reporting Issues
In issue tracking software there are two types of issues you may see reported: a request for a new feature; and a bug report. These types of issues need to have different bits of information captured in your ticketing system. Ideally, your commit message will tie back to the original ticket. Tips on great commits are available separately.
The biggest tip I can give you for really great issues is to make sure the "Card" clearly defines who benefits and how from this feature being built in other words: what is the business value? This will allow people who are working on the task to ask questions with the stakeholder about the implementation detail. Perhaps the developer can think of a much quicker way to do something if the feature was every so slightly different.
That conversation part of the issue is critical. Don't just have it as a heading. Really do have a conversation about how something could be built. Talk about "MVP" or "minimum implementations" but also talk about what this feature could be in the future. Understanding the context of how this tiny wee issue fits into the larger project will ensure the right scaffolding gets built and that the entire project isn't held together with duct tape.
Not all issues begin as new features. Occasionally bugs will sneak into your software. Excellent bug reports include: the steps to repeat the problem; the desired outcome; the actual outcome of the steps, including a screen shot, or movie of the result.