Paul pointed me to recommendation by the Off the Tracks workshop for a Collaborator’s Bill of Rights. This document nicely starts a discussion about collaboration and credit which is important to the digital humanities. The comments are also worth reading. For example, Adam Crymble raises questions about where we draw the line between collaborators and other forms of support or inspiration. Does an RA for a prof who writes a book deserve to be credited as a co-author? Is the builder of a tool like Omeka a collaborator? My philosophy is generally:
- Credit should be discussed at the beginning of a project with RAs, colleagues and programmers. As most of my projects now come out of labs where groups of people meet, we try to discuss credit at the start of any particular project.
- In general most projects don’t lead to one outcome. Interdisciplinary projects will often lead to papers written up for different communities. Working with CS folk we have a general rule of thumb that we can each propose and write papers (conference and print) as long as inform others at the start of the writing/proposing and recognize the key players from the other side. Thus I am encouraged to present/publish in my community and I get to be first author on any paper I initiate. The same is true of grad students and other faculty.
- Listing co-authored papers on a CV for purposes of merit, promotion and tenure leads to problems at the level of Faculty Evaluation Committees. At U of A you are explicitly asked for each item for which you want merit to specify whether you had co-contributors and what your role/percentage of work was. I try to avoid in my own CV specifying percentages of contribution even though that is encouraged. Instead I try to describe the role I played in a collaborative paper in a consistent fashion. Some of the roles include “led the project”, “wrote the paper”, “edited the paper”, “programmed the site”, “managed the usability research” and so on.
- A couple of the comments to this post mention the constraints on programmers and research assistants to starting projects. This is perhaps one of the major reasons I left a nice job in university IT support to take up an academic position – I was tired of waiting for others to initiate projects or trying to be a tail that wagged them. This is the fundamental split in our academic caste system that we have to overcome in the small workings of our labs. In my experience it is often to my advantage to ask research assistants to take leadership and propose things within the context of a research area. The more ideas, the more directions taken, the better the research coming out.
