Sometimes, I work on projects for a week or so and then get side tracked for a few months doing something else. It's sometimes a pain to go back to the code and figuring out what I was last working on.
Any suggestions on how to document unfinished projects that are going to get sidelined for a few months?
For the most part, I do, php and C with some python.
I use Eclipse with subclipse and Trac plugins and Geany as my main IDEs
I find myself in your situation a lot. Mind Mapping's a nice, organized way to jog your memory: Try FreeMind - http://freemind.sourceforge.net/wiki/index.php/Main%5FPage
If you don't want to change too much, you might consider using your commit messages to not only describe what you did, but what you'd like to be working on next. I've been using unfuddle for a little bit, and have been really happy with its tickets and integration with subversion.
If you want to keep it simple:
Notebook with your project todo's and a good helping of notes on what you were doing, where you left off, what issues you had, what needed to be researched, what worked well, why you did something a certain way, etc....
The more the better from this aspect.
More Technical:
Comments in code, source control checkin notes, project wiki, etc....
I think the best solution is to use a local DVCS like git. Make sure you check in changes frequently. Then when you come back after a hiatus you'll have a really detailed log of what you were in the middle of doing.
I like to run through my task list and view the item's I've completed (as a refresher) and the items I was going to work on next.
In the end it still comes down to hours (if not days) of reading your old code and loading everything back into your memory before you'll be as efficient when you left off.
This has a free version which I've used. I find it quite helpful.
Sounds like you're mostly using open source stuff but one tool you might want to look at buying is Microsoft OneNote. I use it to keep everything related to a project together - emails, spec documents, questions, to-do lists, meeting notes and everything else. It keeps it all together in one easy-to-find location. Combine that with some good code commenting habits and a source control system and you're set.
I use ClockingIT and CloudPad. Both are free and work remarkably well.
Create a TODO file that you place in the root of the project. Modify whenever what is left TODO changes, especially just BEFORE a major checkin. Checkin the TODO file whenever it changes too. When you return to a project and grab the source from your source control (you are using source control, right?) the TODO file will be there to remind you of what you were doing and where you were going.
Keep the code and other resources well organised so you don't have to unravel complex links or find files that are missing from the obvious locations because you thought you'd remember where they were.
Write down brief overviews of the main systems, to get yourself back up to speed quickly later.
Comment your code as if you're writing it for someone else - when you come back to it it'll be much easier to remind yourself how it works.
Put TODOs in the code to mark unimplemented or unfinished sections, explaining what you intended to do there.
When you are about to 'park' a project, write down where you were up to (the last parts you just got working, and at least the next few tasks you intended to do, if not a list of all remaining tasks.
Make sure the code is safely stored under source control so you can easily find the latest version and resurrect it. Code and files left lying about have a tendency to get muddled up (e.g. "I've found 2 copies of my project but can't remember which one is the most recent one")
Use some kind of a simple issue racker. There are a couple of issue trackers that don't really need any sophisticated installation and most importantly don't need a server. They work by keeping the issue "database" inside your version control system. (This is basically a more tool-based version of the TODO suggestion by @jmucchiello ).
Here's some examples:
Dist-Bugs is a website which is devoted to discussing these kinds of "distributed bug trackers".
Fossil is a distributed version control system, which also includes a bug tracker and a Wiki. (Note: the Fossil website itself is completely running off Fossil.)
ikiwiki is a "Wiki compiler", which generates Wikis out of static text files in a version control system. It can also be used as a lightweight bug tracker, in fact, the ikiwiki bug tracker itself runs ikiwiki (as does the ikiwike website and also the dist-bugs website).