- Alphabetical (the norm in theoryCS and communities heavily influenced by it)
- Advisor-student: student name comes first, advisor comes last.
- Work-ordering: first author did all the work, last author provided the funding, intermediate authors ordered by contribution (common in systems work)
- alphabetical ordering conceals who did the real work ("but the cream rises to the top")
- Work ordering allows advisors to slap their names on anything coming out of their lab ("But they did all the work needed to fund this research: grant writing, selling, etc")
- alphabetical gives undue eminence to authors whose names begin with 'A', (but see here for a counter-theory)
- alphabetical ordering makes authors with names in the end of the alphabet lazy (Who're you looking at, punk ?)
- theory papers can't be work-ordered, because ideas "float in the air without ownership" (yes, I have heard this argument many times, so don't snicker)
He also links to an interesting set of axioms that Hardy and Littlewood developed before their famous collaboration started. I actually admire this approach. As a general rule, theory folks tend to be very allergic towards detailed discussions about contributions and what-not, but in collaborations, it's critically important to lay out the ground rules in advance, and the Hardy-Littlewood axioms are good because they lay out rules in advance that eliminate any problems later on: for example,
And, finally, the fourth, and perhaps most important axiom, stated that it was quite indifferent if one of them had not contributed the least bit to the contents of a paper under their common name . . .Agreeing to such an axiom requires great trust between the collaborators, because of the immense potential for abuse, and maybe that's exactly the point: a good collaboration requires trust, and you can't agree to such an axiom unless trust already exists.
If name-ordering is followed, a (very short) "contributions" section could be added to the paper stating who was responsible for what part of the work (it's commonly a practice for student project reports :)). Or rather, it could be sort of a footnote (or at the end -- after list of references) so that it doesn't come under the actual paper content. Well, there is the question of anonymity while the paper is under review but it shouldn't be an issue. The under-review draft can just mention author ids such as "author-1" etc, and the final version can have the actual names of the authors.
ReplyDeleteI agree with your "allergic" comment about formalizing relative contributions. The real question is who needs to know the answer? I can understand it for a large project in which all the pieces build on each other and many parts are peripheral. Would this really be a big benefit for theory? For hiring considerations, the details of the contributions can be spelled out by letter-writers, assuming the right ones are chosen. I see little value in spelling it out in the papers themselves.
ReplyDeleteA more important question is "What are the standards required for co-authorship?" Collaborations can be of widely varying forms. Often co-authorship is a result of a conscious decision to work together in solving a problem. One tricky point is what happens if there is insight gained about what won't work but nothing publishable and the actual solution is done outside the planned collaboration?
For the advisor-student relationship this is a little different. I think of the bar as somewhat higher for the advisor than other collaborators. If it is just a matter of the normal guiding the direction of the student, it does not seem that co-authorship by the advisor is warranted. (One could argue, though, that having the advisor's name on a paper can be of benefit to the student because it helps people remember them.)
Paul, you make good points. The "who needs to know" is particularly pertinent. Although my post may have given a different impression, I actually prefer the model that our community uses, because in most collaborations it takes away from the sordidness of attempting to formalize contributions which are hard to quantify.
ReplyDeleteWhat I think we miss though are explicit understandings (a la hardy and littlewood) about "terms of collaboration". What I found particularly striking about their axioms is that they are inherently negative, merely specifying what is not required of either party, rather than specifying what is required. It's a particularly elegant structure.
My advisor, Alistair Sinclair, gave me great advice about author-ordering.
ReplyDeleteOn a very early paper of mine, with all grad-student authors, I had done the bulk of the work, and had informally obtained the others' agreement to be "first author". When it came up with Alistair, he told me that if I did this now, I'd have the issue of deciding the author-ordering come up for every paper I did for the rest of my life.
Thinking about this, the answer was simple; use the alphabetical ordering standard. Life's too short for fights about author-ordering. (Thanks Alistair.)
Since I write a lot of systems papers too, the ordering issue still comes up, and my way of handling it is to say, "Put me wherever you like." I suppose that's a luxury afforded by having been around for more than a decade. I think alphabetical is best, for the reasons you and Paul give.
How do you decide who should give the talk on a paper? Is it usually the most junior author?
ReplyDeleteHow do you decide who should give the talk on a paper? Is it usually the most junior author?
ReplyDeleteIf it's among collaborators at "the same level" i.e all students, or all post-Ph.Ds, any mutually acceptable decision is fine: there doesn't have to be a consistent rule.
If the author list has exactly one student on it, then generally I'd let the student give the talk. If there are multiple students, then it depends on levels of contribution, and need. For example, a student who did significant work on the paper might be on the job market soon, and needs the exposure. On the other hand, if they didn't contribute that much, the job-situation alone should not warrant letting them give the talk.
In general, apart from the "easy" cases, I think it depends a lot on the context.