It would also be interesting to plot the number of TODOs against the size of the code base too. One would assume that as a project grows, the number of outstanding TODOs would grow too. Where and when this isn't true, might reveal something more interesting.

We took some action on this internally at a place I worked.

We had a couple of projects that had unit tests neglected so we enforced that you had to round up to the next closest 1% on the package.json for your merge to be approved (as well as adding some unit tests)

In 3-4 weeks, code coverage slowly went from 20% to 73%.

I bet it's more to do with rate of growth than total volume.

I believe that one of the cognitive dissonances with people who think a lot of code is good news is that they become overwhelmed by how much they would actually write if they stuck to their convictions and so they start using TODOs to make themselves feel better about doing the wrong thing.

Projects that grow slower I suspect have fewer TODOs.

I suspect that in postgres'case that is just because a TODO list was moved out of the code...

While it's probably the case for postgres or Django, todos getting less could also mean high code churn.

Yeah I noticed several cases were there to do's drop dramatically. I wondered if that was because that was a module that had a lot of to-dos that was also low quality, and the subject of a complete rewrite or replacement at some point. Golang was also interesting because of a huge increase followed by an almost equally huge decrease a short time later, both of them seemingly vertical. I wonder if something got reverted, or if they actually went back and addressed a bunch of to-dos.

Might be some type of automation / tool adding a bunch of TODOs (as part of a migration?) which are then automatically removed in a later step.