Writing tickets

Some disparate #thoughts on writing tickets

Especially in an async team, be really explicit. You lose the ability to check in with people, both ad-hoc and even intentionally. Err on the side of overcommunication to avoid things being 'done' and having to go back to everything to clean it up.
- If being too prescriptive is a concern, be prescriptive but acknowledge it. e.g. call out that it's your opinion, but invite other discussion through explicit actions on the ticket. "Do x, but raise in Slack for other opinions"
- Focus on setting boundaries.
Add multiple forms of replication for bugs, etc. A Figma design or a code sandbox is good - but a screenshot also helps. The former two can change.
Overcommunicate. You will forget what you were trying to say in a few weeks/months.
"Done when"'s can be really useful here. They help be explicit about the goals of the ticket so that tickets don't run on too long. Also prevents misalignment and sending people down rabbit holes that aren't relevant.