Deadling with Deadbeat Co-authors
Problem scenario: you are working with a bunch of other folks on a technical paper, and some folks do the lion's share of the work (usually one or two really productive people), while the others don't do much yet expect to be a co-author on the paper.
FWIW, I believe (or hope) that situations like this can be avoided, or minimized, using a two-pronged strategy. One is a variation on the "no asshole rule": co-authors on a paper should have "like minds" about what level of effort/contribution warrants a co-authorship role vs. an acknowledgment. Some people I know, particularly faculty who came through certain academic systems, believe strongly they should be a co-author on every paper their student writes. While that's bad enough, what's worse is those students graduate and go on to be on teams where they have had a skewed role model.
OTOH, I believe it is also important to recognize and even accommodate situations where not all co-authors are going to contribute equally. I'm not trying to make excuses for those on your team who are not performing. Instead, I'm saying that in future gigs, it is important to be aware there are differences between co-author contributions.
The second element of the two-pronged strategy is to have a clear agreement of all co-authors of their expected contribution. This discussion should be one of the first ones the team has to flush out potential problems.
To aid you in your discussion with your team, most journals/societies that I'm aware of use the following measure as the baseline for determining co-authorship: did each co-author make a substantive technical contribution to the paper? If so, what was it?
It is my opinion that all co-authors on your paper team should be able to clearly state their substantive technical contribution, as well as the substantive technical contribution of all other team members. If everyone on the team can't do that, than I believe you might have a problem.
Again, the way to minimize the likelihood of ending up in this situation is to have clear and open discussions with your team early in the process.
April 13, 2009, Berkeley CA