How to keep track of necessary changes (“todo”) for a large document?

Working on my Ph.D. thesis I use the fixme package to add notes and comments to my pdflatex document and I have defined several types of notes for easily seeing the difference between "substantial" changes (like "text might be wrong" or "there is some info missing") and "cosmetic" changes (like "alignment of this table is not perfect" ...).

I have loads of notes in my document now and I'm quite desperate, as it seems impossible to get an overview of the changes to make and to sort them in order to be sure to do the most important ones first and make some time management and planning not to loose too much time just for creating one beautiful graph.

Does anyone have a good solution or workflow to

• efficiently edit a large document like a thesis or book
• and keep track of notes, ideas and things to do?

Some thoughts:
It would be great if there was a possibility to create kind of an "anchor" in the source code (or pdf), so that I could jump there with a hyperlink from the todo note directly.

I think that I'd need an external solution which allows me to sort, re-arrange and tag those notes for prioritizing and overview – maybe with a mind map or a table which can be filtered, sorted and rearranged.
On the other hand, I'd like to leave them in the latex document, so that while looking at a certain page I can see the corresponding notes. But it does not make much sense to type them in the LaTeX-editor and then re-type them in the external application again, but all that sounds very complicated to me. :-(

-

I've used a combination of fixme and todonotes for my thesis to achieve this effect, where the first page contains hyperlinks to the places that need attention. You can see source of my thesis here.

The fixme package has extensive facilities for prioritizing and formatting your list of corrections, but personally I think that is way overkill for a single-person project like a thesis. I just used a single type of fixme note. In my opinion you just want to have a way to keep track of things you need to come back to, and let readers of your drafts know which parts are due for extra attention: by the time you've pondered whether this is a "warning" or a "note" or a "fatal", and whether it is "anchored" or not, and all the other options the package gives you, you may as well have just fixed the problem in the first place. So, my advice is don't try to be too complicated. There are already ample possibilities to procrastinate while trying to write a thesis, so don't give yourself even more.

EDIT: for your question about linking back from the todo notes to the latex source, look into SyncTeX, as described in answers to this question. In a comment, you mentioned that you use Skim, which I believe can be configured to use SyncTeX.

-
thanks for your comments. You're right, it should not be too complicated, but at least I need a way to separate the MUST from the CAN (and even "would love to, but...."). Why did you use both packages? –  Martin Apr 5 '11 at 7:55
@Martin, when I started writing, both fixme and todonotes were much more limited in their features. I've forgotten now what it was that made me decide I wanted to combine them both at that time. Currently, I would say the advantage of doing this is that todonotes gives nicer formatting of the notes, whereas fixme has more options for prioritization and is also has features to output information on the notes to the log file (you can then extract this information and produce reports, etc, if you want to be fancy). –  Lev Bishop Apr 5 '11 at 18:34
Chapeau and a +1 for that thesis draft. I will certainly check what packages you used because the result is excellent –  YuppieNetworking Apr 5 '11 at 19:16
@Lev: I agree with YuppieNetworking, I had a close look at your thesis and I think it is a very beautiful document. It made me think about my approach to save space and paper, as the first pages of the chapters look very good... (mine are more MSWord-like at the moment). But at the moment I "unfortunately" have to concentrate on the content and can (must!) deal with the cosmetics later. –  Martin Apr 6 '11 at 0:53
@Lev Bishop: I tried to send you an e-mail to the yale address on your webpage, but it seems to be out of date. How can I contact you? (there seems no means to send a private message to another user here...) –  Martin Apr 7 '11 at 12:27

A fancier solution, that I use myself, is PDF comments with the pdfcomment package. It has the virtue of being natively supported by PDF readers. With Acrobat, at least, you can edit, reply to, delete, checkmark, import/export, search and sort comments.

-
Another way to achieve this is via the fixme package, which has the feature to optionally render its notes as PDF comments. –  Lev Bishop Apr 5 '11 at 4:52
@Lev: thanks for mentioning that. I wanted to try it with fixme but it did not work, maybe because of problems with my TeXLive installation and a wrong PATH, I should give it a second try. But I do not use Adobe Acrobat or Reader (if I can avoid it), so the question is, if Skim also can deal with the pdfcomments.. –  Martin Apr 5 '11 at 8:07
@Lev Bishop fixme uses pdfcomment internally. It's if you want one abstraction level above. –  Josef Apr 5 '11 at 13:30

I'm not familiar with the fixme package, but I think the todonotes package could be what you're looking for. Using the color options described in the documentations, you could define different colors for your different types of notes. \todototoc provides you with a list of what's still to do, and you can even display the colors in there, in order to get a quick overview and find major flaws fast. With hyperref, the items in the list even become clickable so you can get to the point in your text elegantly.

Edit: The todonotes manual refers to fixme directly under 1.8.5, you mind find this particularly interesting.

-
The programming API of fixme has changed in the meantime, and the method described in 1.8.5 of the todonotes documentation is out of date. (Personally, I think it is not a very good sign for fixme to have completely ignored backwards compatibility this way, and it makes me rather disinclined to use this package in the future -- in the tex/latex world stability is considered vital). –  Lev Bishop Apr 5 '11 at 4:43
@Lev Bishop: Yes as a user of fixme, I also was very surprised that everything I had defined was broken with the new version and I had to start again and read the fine manual... however, the new start also had a "cleaning" effect (but everything has become messy again) –  Martin Apr 5 '11 at 8:05

Thinking outside the box for a moment, might it make sense to keep this kind of thing in a system designed for tracking a project?

Personally, I use fossil for version control of all my software and writing projects. I like having a my text under revision control, and TeX and LaTeX are well suited to being kept under revision control. (Unlike Word documents which are fragile binary files.) I also try to work in a repository that is kept in sync with a clone on another machine. That provides for a backup copy of my work, without hassle or headaches.

I've used this technique for everything from project documentation (written in a mix of Markdown and LaTeX and compiled to finished PDFs with Pandoc and pdflatex managed by my project's build system) to a personal book-length project destined for a print-on-demand service.

The reason I think of using fossil for your specific issue is that it includes an integrated trouble-ticket mechanism. Tickets can be reported on, are included in the timeline views, and can be referenced by specific checkins.

It would be easy to use ticket IDs in marginal notes, footnotes, or comments to refer to the full explanation found in the repository.

On several of my projects, I have the identifier for the revision of the document included in a footnote so that I can always relate a paper copy back to the repository.

The cool bit of integration would be a script that extracted all of the referenced tickets (and checkin comments) and produced an appendix....

-
thanks, I've never heard about fossil before and quickly looked at its homepage. Sounds good, but: I already use svn to regularly save "snapshots" of the documents and show the current version with svn-multi. How can you do the latter with fossil? –  Martin Apr 5 '11 at 8:03
@Martin, there probably isn't a package that does what svn-multi appears to do. I use ad-hoc scripts in Lua to do that sort of thing when I need it, and take advantage of the fact that fossil can leave the ID for the current checkin sitting in a text file (manifest.uuid) where \input can read it. It wouldn't be that difficult in LuaLaTex to write a Lua module to do more interesting things like svn-multi can do. It would probably need to shell out to fossil, or access some content from the repository directly with LuaSQL. –  RBerteig Apr 5 '11 at 8:31
Any version control system (and, IIRC, SVN can) that can produce a "git fast import" dump of a repository can be moved to fossil without too much pain. The TCL/TK project did just that recently. SQLite moved to fossil a while back. Of course, fossil was created by the clever folks who created SQLite to address some issues they had with other distributed version control systems not quite meeting their needs. –  RBerteig Apr 5 '11 at 8:36
thanks for your comments. If the current ID would be in a text file and could be read by \inputthat should be enough to clearly identify the current version (together with creation date in the footer). I'm just not sure if moving to a new tool is a good idea in this time critical phase. For the first steps I took 2 sheets of paper to make some notes about what to do next. :-) –  Martin Apr 5 '11 at 8:42
@Martin, obviously if the deadlines are looming then don't go switching tools. But after the dust settles, give it a try for something where you have time to play with it. You could also soft-start by playing with just its ticket tracker as new ideas and issues arise. You don't have to use all the features at once, after all. –  RBerteig Apr 5 '11 at 8:49