We all know that code reviews are generally a good practice, but what about reviewing documentation? Many devs that I work with will put up wiki pages, javadocs, etc, but most of the time, unless someone else needs it right away the docs will go unnoticed and unreviewed.
Are there any good tools or methodologies for peer reviewing code documentation?
Actually, I think your posting contains two different questions, let's start with the simple one first:
are there any good tools or methodologies for peer reviewing code documentation?
I don't think there are "special tools or methodologies", because there is nothing special needed. Peer reviewing documentation works like any other kind of proofreading - you give the documents to the reader, he reads it, adds comments or suggestions for changes and finally you discuss the suggestions. That's all, it works with any kind of documentation technology (of course, some technologies make proofreading and commenting a little bit easier, but that does not change the general methodology).
Many devs that I work with will put up wiki pages, javadocs, etc, but most of the time, unless someone else needs it right away the docs will go unnoticed and unreviewed.
That is actually your second question - in other words "why do lots of people do not take notice of separate code documentation, or don't care for their quality?"
I think this question has been discussed in-depth here on this site, as well as in lots other places. It is a very broad question, but it all boils down to "is additional documentation really worth the effort?" And as long as the answer is not clearly "yes", don't expect to get a different answer to ""is it really worth the effort to review it?"
My personal opinion about this is that any team which is responsible for a certain product has to find the amount of documentation, and the correct abstraction level for the documentation that works for the team and the product. And once you found that, and the team sees a lot of value in that docs, the demand for reviews will arise by itself.
Given that any quality produce requires documentation, even if its a getting-started document you should be creating, updating and reviewing the docs.
The problems come when documentation is hard to access, so if you have to check out a word document from sharepoint edit it and then upload it again, you're not going to find many people wanting to make the changes. So I find it best if you assume the documentation is part of the source code, and if you put the document sources alongside the code there's no excuse for not updating it - eg if your documentation is text files in a markup language then doc changes are as easy as editing a big comment. Your CI system can turn those sources into word or PDF or HTML, so you always have up to date documentation that is both easy to edit and easy to review (you just check the scm history diffs).
wiki pages are less easy as they do not closely correspond to SCM history, but you do still have their history you can check, the editor will have to say which pages they changed.
Other than that, there's no tooling for Word documentation reviewing that is any good (you still have to manually go in and read the whole thing to see if it it correct) so you end up having to add a review comment that you updated the docs in section X, chapter Y, page Z. The answer to this is obviously to stop using Word.
