Usually the reason for me to leave a TODO is when something really minor doesn't work right and making it work would more often than not be a huge undertaking or at least require quite a bit of thought.
If the thing that didn't work right was important, I'd add a bug to the tracker in order not to forget it. If it was easily fixable, I'd fix it then and there.
This leaves these TODOs to be tasks I would not want a newcomer to the code base to tackle, because the first solution they would come up with is likely incorrect, so all the amount they'd put into fixing it might end up in vain.
That said: maybe others use TODOs differently. This really is judging from my own experience.
(Then there are the orphan TODOs - such as one strange ??TODO?? in some code I inherited that has no good documentation (just a vague reference to another class) but looks too important to remove. One of these days it's getting deleted.)
It depends on the project though. Other projects may rely more on an issue tracker.
Either way, don't let it stop you, most open source projects are glad to have help!
I think the general advise in this article is good, though. By searching TODOs, I'm sure there will be many non-trivial fixes that will be found. But at the same time, I'm confident that it's a good way to find little things that have been forgotten about in the code.
TODO: Add "busy" indicator while waiting.
TODO: Ensure that :foo_url and :bar_url parse.
TODO: Assemble absolute URL based on :foo_url if :bar_url is relative.
TODO: Verify that this is one of the user's foos.
TODO: Use protocol relative address in production.
TODO: Dynamically set hostname based on environment.
TODO: Document these; especially their options!
Documentation is the last thing to get done (if at all) and the least glamorous, but it needs to be done.
This is especially easy to do if the project has a wiki.
In addition to that we're working on creating the unit test for the contributor to uncomment before checking the fix in to verify that it does in fact do what we had intended when creating the issue.
We've also set up a contribute section on the site to help. I'd really love to know what more helps new developers that want to start contributing to an open source project.
Seems likely that an issue entry will provide better context to the problem than a simple TODO would. Issues may also be tagged with a rough indication of how much work they will require to tackle. Choosing issues that are a small amount of work seem to be a good way to get familiar with a codebase.
Fixing even minor details in large (and complex) projects can require for you to understand all the details of that project.
Here we see the Dunning-Kruger in its natural habitat. What if someone is a better programmer than you? What if that person is a random internet foobar who finds your code and wants to contribute?
The complexity of TODOs in code depends entirely on the style of the person who put it there. In my case TODOs are usually things that are going to require some refactoring.
* 8,082,861 TODOs (though some of these are to-do apps <:)
Vim even highlights TODO: in my code and it always starts with some type of comment on a line of its own.
I have written two or three apps over the years that parse source code for this and others, but nothing ever satisfying really felt right. If anyone has something perfect do shout.
* Compiler errors
* Unit test failures
* Compiler warnings
* FindBugs warnings
* Bug tracker
The IDE already highlights the first four, and for all but #2 it tells me what source line to look at, so I don't see much potential benefit from using the task list.
Having said that I do use XXX tags, but just for the syntax highlighting.