For the rest of this year I'm using Drupal's book module for a substantial collaborative research document (250,000 words, 50 authors, 130 peer reviewers). This is a useful project to test Drupal's ability as an academic authoring tool, and I will document some experiences as I go along, hopefully working towards a longer howto article for later publication (and perhaps a collaborative authoring branch of drupal-on-a-stick).

general comments
--> for those working in a windows environment, particularly when working with technophobe colleagues, the drupal-on-a-stick project is fantastic (http://www.ratatosk.net/software/onastick) and encourages people to try out drupal at home

--> for new users, it's worth buying one of the Drupal books as a desktop reference.

--> the process of choosing, installing and relevant modules takes time. While it makes sense to keep Drupal core simple and to encourage the plug-in process, Drupal.org should perhaps begin a series of 'use cases' or 'kickstart lists' to get users up-and-running quicker (e.g. 'drupal for academic authoring', 'drupal for media content', 'drupal for media screening', 'drupal for magazines')

drupal for academic authoring - kickstart list

For academic authoring, the list of relevant (non-core) modules is as follows:

book (tip: under admin/settings/content types, switch on 'Create New Revision' )
contact
collapsiblock
dba (database administration)
diff (the patched version - see comments below)
excerpt
export_docbook
forum
glossary
linenumbers (needs some improvement for peer reviewing/comment response, but a decent start)
locale (for customising interface text without messing about with module code)
masquerade
jstools
nicemenus
path
sidecontent (tip: style the sidecontent block to look like post-it note for reviewers )
tinymce (tip: educate users on the 'toggle to fullscreen' button)

In addition to this module list:
marvin (chameleon) theme: clean and very white (suitable for editing publications) -- you'll need a lot of screenspace, so consider removing logos/primary/secondary links sections from the template

If your audience includes speakers of other languages, the machine translation block is a simple way to
facilitate gist translations: see http://www.digitalraindrop.com/Drupal-CivicSpace-Translations

bibliography module: this should soon be available - http://drupal.org/project/biblio

shoutbox (and in the future, better integration of phpfreechat) is useful for basic communication with authors: the phpfreechat will in particular be useful for scheduling virtual meetings about chapters/articles

glossary2 is useful, but lacks the the filtering offered by the basic glossary module; a full dictionary module (multiple definitions, multi-language equivalents, citations, concordance info, etc.) would be helpful for the drupal project.

linenumbers -- for peer review (that is, enabling comment on nodes and not edits) the linenumbers module is a useful way to cross-reference comments with node content without changing its base content -- ideally, this module will be improved to add links on linemodule's paragraph ref. numbers to open a comment that is prepopulated with (i) the paragraph ref. number and (ii) the content of the paragraph with quotes

The Collaborative Editing project currently in the Summer of Code 2006 is likely to help authors work concurrently on the same chapter; while synchronous/Ajax reporting is a little too 'realtime' for most academic publications (they typically have a production cycle where authors work on a document in separate sessions), why not raise the bar for collaborative editing with Drupal?

My experiences so far:

diff
The diff module is essential for collaborative editing, but needs work. It could benefit from:
(i) a full 4.7 release (catinthehat's patch integrated into core)
(ii) update to the latest diff features within the PEAR library
(iiii) features to 'rewind/forward' views of revisions over time
--> see http://phiffer.org/projects/wikipedia-animate and http://ejohn.org/projects/aniwiki/
(iv) .css styling to highlight additions/deletions/changes in a richer way (with graphics)

-- I know it's peanuts, but I would put up a bounty of $100 to see all these features (particularly item (iii), which oozes geek cool) implemented into Drupal's diff module. A few other similar contributions and we might have enough to make this happen.

taxonomy administration
--> add term - adding terms manually is time consuming: could we build a shortcut way to upload multiple terms (for example, using txt files with new lines and hyphens to indicate parent/child relationships)? This can currently be done using free tagging, or using an xml-based taxonomy import, but adding several terms in a single submit direct using admin/categories/add/term would be great.
--> list terms - I would like to see a possibility to delete (with confirm, naturally) or rename multiple terms on this page (without proceeding to a new edit page)

permission settings and general admin interface
-- setting up individual users and permissions with the taxonomy access module is time-consuming and onerous
--> any way to improve the admin interface of taxonomy access is welcome
----> in particular, any js widgets to select/deselect all radio buttons throughout a column in a page
----> enabling admin control over paging and the number of rows listed on a page would be helpful
----> how about some kind of 'duplicate role' function would help speed up the process of creating roles with similar (but not identical) access permissions?
----> on the url alias list, it would be useful to be able to edit/rename multiple aliases in a single submit

text-based buttons and links
--> in order to beautify the interface and user experience, it would be good to be able to replace text links with graphical buttons (perhaps using the tango project for many of these icons)
--> could the locale module be tweaked to enable the replacement of text strings with images?

tinymce save button
--> As most authors are used to MSWord, the interface is generally similar and easy-to-use. However, there is a tendency for users to be lazy, and to associate tinymce's HTML 'update' button with saving/submitting the document into drupal, or just to open a new browser window, get sidetracked and forget that there is no autosave feature if they inadvertently close the browser. Adding a save button on the TinyMCE toolbar (which submits the form) is the solution: see -http://sourceforge.net/tracker/index.php?func=detail&aid=1091350&group_i...

Drupal version: Drupal 4.7.x