[jbjorge]

If you don't use an issue tracker, then to-dos is your issue tracker.

If you're using an issue tracker as well as to-dos in the code, then you've got two issue trackers.

If you're using an issue tracker that also reads to-dos in the code, then you've got one issue tracker.

Where I work we don't have an integration between the tracker and our code, so we disallow to-dos, but allow comments with references to issues. So in other words - one issue tracker.

I can't quite understand why people would want to have multiple places to list code issues.

[kjeetgill]

In practice they work quite differently in a number of ways, depending on your workflows. I'll outline mine, but from this thread you can probably tell, it's not unique.

Jira/Github-like issue trackers can often become blackholes for certain kinda of work. Not all TODO's NEED to get done, they're often just reminders to revisit decisions with the full context of the code. The two most common cases that come to mind are deferred possible optimizations and deferred generalization.

In my workflow, it's more of a counterbalance against premature optimization, abstraction, and distraction. It also has the benefit of:

a) informing reviewers what wasn't done and why right in the diff. It can often spark good conversations of if it's worth scoping them in or maybe scheduling in (Jira!) soon.

b) Allowing people to revisit the above when the next engineer is changing things in the neighborhood.

In my experience, if and engineering side ask isn't addressed in a month or 2 it quickly turns into one ticket that sits in the backlog forever and maybe another that get's created when the "idea" get's floated again.

Naturally, your milage may vary.