> You do not put these kinds of TODO items in an issue tracker because they are extremely local and contextual to the code they apply to. Filling the issue trac

> You do not put these kinds of TODO items in an issue tracker because they are extremely local and contextual to the code they apply to. Filling the issue tracker with thousands of these kinds of issues which can't be understood without looking at the specific lines of code the comment was applied to has high overhead with negligible value. This is one thing that really irks me about most code review cultures I've worked in - they can never stand to see a "naked" TODO (one without a reference to a tracking bug). You're spot on about the result. The instinct to put a TODO is a note to self that there is a future cleanup, optimization, or improvement. It's a flag to readers of the code that the original author was not quite satisfied with some dimension of a solution. It is _not_ a work ticket, especially in the timeframe that most issue trackers work on (< 1 year). Maybe there needs to be alternate semantics for these "contextual TODOs", so that people do not immediately get the instinct to either put them in the queue or remove them.