I've seen something like this tried before. What ended up happening was that not all TODOs were handled in a short period of time, some of them expired, then everyone was cross the build failed and the offending TODO was promptly given an extension.
Maintaining code quality and TODOs turns out to be a surprisingly hard problem, but it's far more of a social / organisational one than technical, which is why technical tools don't solve it.
There's a much higher-ROI way to encode these, write a test that checks the current date. Maybe a very large project would prefer not to fail everyone's build for it, but this is fine for a couple dozen developers.
Not all TODOs are bad though, they may be a temporary turned permanent implementation that may be just as fine but the author may have wanted to do it properly or a bit nicer but which will never happen.
I always advocate that TODO comments include a link to a ticket tracking the TODO during code review.
It’s easy to get a team to make this 2nd nature and gets immediate debt in the backlog. It can of course still be ignored and unfinished for a long time still but no amount of automated nagging will change that in my experience
I am personally not a fan of TODOs, use tasks instead. TODOs are embedded in codebase - difficult to work with, that's why we have Jira where you can manipulate, filter and aggregate tasks. The only acceptable case of TODOs in my opinion is to leave them as suggestions to a future person in the case of refactor. Then you could have a task that says something like "Refactor feature xyz and solve TODOs".
The way I use them, is for annotating possible extension points or refinements that would improve things, but are more of the "nice to have" kind, or stuff someone coming across might want to take care of later. Many of these don’t warrant real issues in a tracker, as they would just clog the backlog and get eventually deleted anyway.
The codebase is only hard to work with in the ways it's meant to be - they are very easy to find with `git grep` and they are right next to the code in question so are easy to see when you're working on it. Conversely, they are hard to just 'lose' when some PM decides to have a "JIRA cleanup", which is also by design.
Expiring TODOs automatically is a dumb idea, about as dumb as closing unresolved issues automatically. TODOs in the code serve as documentation of the limitations of a feature, close to where a developer needs them. As such it's best to keep TODOs in the code, with an issue tracker serving only as a mirror, not a substitute.
In my experience this kind of thing works only with the discipline and will to actually get to it, and that really depends on the project, team and management dynamic.
I've been receiving a "stale issue, closing soon" notification on an open source project every two months for over a year, which I dutifully bump and the issue continues to be studiously ignored. Much respect to that team, but the techno-fix of quarterly reminders are not addressing the core issue of missing will, process or personnel. It's a bit like setting a clock ahead in order to leave on time: the will to be on time is the driver, not the clock.
However, for those teams with the will and process to address old TODOs, seems like a nice reminder. I might use it!
Maintaining code quality and TODOs turns out to be a surprisingly hard problem, but it's far more of a social / organisational one than technical, which is why technical tools don't solve it.
Example: https://github.com/lobsters/lobsters/commit/9e99fbf1d3cc441e...
It’s easy to get a team to make this 2nd nature and gets immediate debt in the backlog. It can of course still be ignored and unfinished for a long time still but no amount of automated nagging will change that in my experience
In my experience this kind of thing works only with the discipline and will to actually get to it, and that really depends on the project, team and management dynamic.
I've been receiving a "stale issue, closing soon" notification on an open source project every two months for over a year, which I dutifully bump and the issue continues to be studiously ignored. Much respect to that team, but the techno-fix of quarterly reminders are not addressing the core issue of missing will, process or personnel. It's a bit like setting a clock ahead in order to leave on time: the will to be on time is the driver, not the clock.
However, for those teams with the will and process to address old TODOs, seems like a nice reminder. I might use it!