2

I'm on a team of 10 people contributing to a book organized by the department. As the only contributor under 30, I'm in charge of technical stuff.

The team is comprised of members who are not computer savvy.

Management of citations and changes in a large text are critical to the project.

What features would benefit such a team and how could one convince collaborators to learn & use them?

10
  • 2
    Will the book contain a lot of figures, tables, and math formulas, or almost only text? Do you need a lot of cross-referencing?
    – Orion
    Oct 4, 2016 at 16:40
  • 1
    Consider arranging a 1-hour workshop, provide the co-authors with Google accounts (if they don't have), share a Google document with them, and train them: demonstrate how collaboration would be easier and much more productive and exciting (live co-editing, comments, track changes and revisions, chat, notifications by email, no backup needed, editing while in the train and from smartphone, etc) than exchanging a WordPad file in an email thread.
    – Orion
    Oct 4, 2016 at 16:54
  • 1
    Are the authors responsible for different part of the book (e.g., one chapter each on different topics), or do you have to work together on the same text? Oct 4, 2016 at 17:05
  • 3
    Personally, the first alternative that I would eliminate is Dropbox. With such a large number of collaborators, editing conflicts will drive you mad pretty quickly. Oct 4, 2016 at 17:16
  • 1
    For this site, I think the question should focus on the selecting of the tools more than the tools themselves. That is, a question about how to herd cats and so pick tools that everyone can and is willing to use together does fit academia. As worded, this doesn't really fit, but the bones are sound.
    – The Nate
    Oct 4, 2016 at 20:25

2 Answers 2

2

If you're the only technically-literate person on a team of academics, I would eliminate the options with a learning curve. Especially since academics tend to be quite resistant to change (well, most people are, but academics even more so) and you mentioned someone uses WordPad (yikes).

Yes, Git or Subversion or the many other collaboration tools out there would work great, but unless you're going to oversee the training of everyone AND they are motivated to change the way they work, it's destined to fail. It takes practice to be good at these things.

I would recommend two steps:

  1. Use Dropbox with extended version history that everyone can treat just like a drive on their computer

  2. Split the various parts of the book up into many different files. This way someone can open the file for chapter 1 and work on it while someone else works in chapter 13.

This way, if there ARE any mistakes, or someone edits someone else's work out of existence, Dropbox will handle version control in the background that allows for recovery. And most importantly, your collaborators won't really need to change many habits for it to work. Work in a format everyone knows, like Word, and deal with formatting like LaTeX later when the text is completed.

1

TLDR summary: Start with your team and figure out what editing tools they are willing to use. Each choice will restrict the next selection: users, writing, editing & reference management, and version control & sharing.

In more detail:

You need a suite of tools covering a range of needs.

(Google Docs represents multiple of these at once, but nowhere near best of breed for any of them.)

I'd focus on the writing and editing. (two very related activities)

The file format matters. TeX-based file formats make a lot of sense, as do SGML formats or XML, but learning and teaching those to everyone may be beyond you.

("DocBook" is a good place to start. IIRC, DocBook is now an XML std..)

If you pick a file format that makes combining constituent files and formatting consistently simple, then you just need to handle version conflicts. If the format is text based, (as all the forms I've mentioned so far are) then you can use pretty much any of the version control software options to show your edits and conflicts betwixt.

For your version control needs, I'd recommend Mercurial. Hg uses a distributed model, so each of you is king of your own castle: you can edit to your heart's desire and synchronize when two of you huddle. If you want a central spot to act as a canon, you simply define one and use it that way.

(It can thus act as a CVCS, while retaining the advantages of decentralization.)

Git and SVG are other popular options. Turning on a document's versioning can also work in some word processors. (WordPerfect and Word among them.)

Speaking of which, if you go with an SGML or XML form, you can still edit it in certain word processors. Word is notoriously bad at this, as well as picky about formats. WordPerfect is surprisingly good at it, and allows a wide array of formats, including user-defined formats. OpenOffice derivatives are very selective in what they do, but, with appropriate extension, can work like this or even LaTeX.

If you want documents that require complex formatting and a word processor for writing and formatting, WordPerfect is best. It creates the fewest hurdles when used as intended. Note, though, it does require a very different way of setting up a document than the others, especially if you are using a non native format like DocBook.

References: There are multiple options for just the approach to managing references and numbering. One approach is a common storehouse of all the works to be cited. (usually stashed distinctly) It's possible to simplify, allowing redundancy and just using end or foot notes. Most word processors have really bad tools built-in. There are multiple competing options, hiwever, for separate reference management utilities.

For my thesis, I used EndNote, which was surprisingly good. It found all of my references and bibliography in my document written and imported them correctly into my archive. Later, when I changed my mind on citation format, it took seconds to update the entire document from parenthetical by name to classical footnotes. Saved at least an hour right there. I don't know if it supports DocBook or any of those sorts of things.

(LaTeX folks use BibTeX among other things)

One nice feature of many version control software packages is smooth integration with web service. Mercurial, for instance, can refer to repositories via uri effectively as any other path. GitHub is an example of a website providing a central stash for various projects, if you don't want to set up your own.

The level of technical ability required for some of these choices is higher, though, and the least common denominator is going to set your options. You really need to get feedback from each member to find out what they are comfortable with.

As noted, DropBox can lead to edit conflicts, but of that's the best you can get everyone to use, well, reality wins. (DB could work as a common share with Hg pretty well)

Choice of format sets editor/noted processor which determines which other tools are available. Hence, your first step is talking with the team.

4
  • 1
    This is not a bad answer, but unfortunately the question is not really a good fit for this site.
    – Cape Code
    Oct 4, 2016 at 19:37
  • 2
    Most of these suggestions have large learning curves. It's hard to imagine getting 10 technically-inept academics to use them all together effectively.
    – Jeff
    Oct 4, 2016 at 19:40
  • I agree with both of you, of course.
    – The Nate
    Oct 4, 2016 at 20:11
  • Maybe I should promote the part about selecting tools based on the team to the top.
    – The Nate
    Oct 4, 2016 at 20:12

Not the answer you're looking for? Browse other questions tagged .