An idea for another task shows up while I'm coding. If I follow it immediately, the work I started stays unfinished. That's what I want Linear to help with: keeping the work in one place and knowing what I'm doing right now.
A title like “fix the backend” doesn't tell me much when I return to it. What breaks, under what conditions, and what should happen instead? A few sentences answering those questions save me from repeating the same investigation.
That's how I try to write Navly issues too. For a bug, I describe what I observed. For a feature, I describe what someone should be able to do. I try to understand the problem before putting a technical solution in the title.
When the list gets long
It's easy to treat every idea as a commitment. I want to keep recording an idea separate from deciding to work on it. I don't want to lose it, but I can't fit everything into this week either.
A useful task list tells me where I left off when I come back. I'd rather spend time on that than keep rearranging labels and views.
What goes into an issue
Here's an example of a map issue. This isn't a real bug report; it's an example of the level of detail I want:
Title: Switching days leaves the previous day's stops on the map.
Steps: Open a two-day trip. Select day one, then switch to day two.
Observed: The day heading changes, but the map markers stay the same.
Expected: Show the selected day's stops and route.
That gives me somewhere to start reproducing it. With “map is broken”, I'd first have to rediscover what the problem was. A screenshot or relevant log can stay in the same issue.
It also gives me a completion check: repeat those steps and see whether the map follows the selected day. Changing the code alone doesn't tell me the work is done.
A Linear cycle groups work for a period of time. The backlog can hold work that hasn't been scheduled. Keeping those separate helps me avoid putting every new idea beside the tasks I'm actively doing. Linear's cycle documentation covers the behaviour in detail.