Friday, April 25, 2008

Book Management

Talking about a "group-book" is a lot of fun. Actually putting one together, maybe less fun.

I like to think this project will be self-promoting, if it just gets started. A few people write their chapters. I put them online, blog about them, maybe push others to blog about them, a few more people think that's a good idea and look people are actually doing it, a few more chapters come in, and so on. Soon we have 20 or so chapters, and we think an actual book. (Maybe soon after that it catches on so well we get 40 chapters, and we make an omnibus.) To me, though, the hard part is getting started.

We need some rules of management, and if I'm currently the editor assigned to your paper for say SICOMP, you might now that management is not always my strong suit. (In self-defense, I'll say it depends on the situation. Corralling referees is not my best skill. And probably not corralling authors, leading to the failure the first time around.) So here, I'm happy to take advice. Send advice! Indeed, I've had a prod or two from people who'd be interested in co-managing/editing this project, so it won't be just me-- which is great!

I'll eventually work it out with co-editor(s), but here's my rough thoughts -- totally open to change.

1. We'll send annoying e-mail to people who we might like to write chapters. (Those who were on the old list, you're not off the list.)
2. People who want to write chapters can pick (and send me) a topic, so we don't get many people writing on the same topic.
3. Authors can make their participation public, so their name and a working title goes on the Web site, or private, so they can back out.
4. There has to be some notion of deadlines -- if you say you're going to write a chapter, after time x, you have to back out (and someone else might take the topic), or show significant progress.
5. I'd hope that several people might take time over the summer to write chapters, and then maybe some others over the fall, and so on. So if you think you can spare cycles over the summer to put a draft together, let me know!

3 comments:

NickH said...

Here's one question to consider. Do you know of any well-written books whose chapters are written by different authors? I don't usually enjoy such books.

There are exceptions. One that comes to mind is Dorit Hochbaum's "Approximation Algorithms for NP-hard problems", which is great.

This issue may be particularly acute for books aimed at high-school students. They're not used to reading technical documents so the need for polished writing is much higher.

Michael Mitzenmacher said...

Just looking at my bookshelf, besides Hochbaum (which I agree is a great book), I like the new Algorithmic Game Theory; the AMS book Computational Complexity Theory looks pretty good (though I'm no expert); I also like Probabilistic Methods for Algorithmic Discrete Mathematics, and I don't know the process used in the Lothaire books on combinatorics on words, but they're pretty good.

I think one point here is that these chapters should not be "technical documents". They should be vignettes, lots of the high level ideas and inspiration. Sure, the writing should be polished, but it's different from a paper.

NickH said...

Thanks for this list of books. After a quick perusal, I agree that these books are also very nice. I suppose there is some bias in this sample, though: the books that end up on your shelf are presumably good ones!

I would presume that writing a book takes great effort to ensure consistency between chapters: notation, flow of technical ideas, expected level of background, etc. (Of course, you have much more experience with these issues than I!) The point that I was trying to make is: I would expect that this task is even harder with multi-author books.

Let's consider specific examples. Would Godel-Escher-Bach have been equally enjoyable had it not all been written by Hofstadter? I suspect not. On the other hand, would the New Turing Omnibus (which I have not read) have worked well as a multi-author book? I think it could work.