Ah, yes, everyone’s favorite: group projects!
I will be the first to admit that collaboration is not, nor has it ever been, my strong suit. I like having complete control over a project and often work in intense sporadic bursts, so I tend to struggle with the shared accountability and slow, steady pace group work requires. However, my personal opinions on group work do not change the fact that collaboration is a crucial, and largely unavoidable, part of the DH field.
As Griffin and Hayler’s article points out, collaboration within DH is extensive, spanning across disciplines, oceans, and often including groups and communities outside the university environment. However, their definition of collaboration also includes that between humans and technology, both hardware and software.1 Though the idea of “humans and non-humans co-[producing] knowledge” initially confused me while reading, Chris pointed out during our small-group discussion that every technological tool is built by a team of people making decisions about what it can and cannot do. His example of the Google Maps Street View tool, for instance, presents a seemingly objective representation of geographical space without noting deliberate choices made by both its developers and its data-collectors (i.e., the people driving the Street View imaging cars) that influenced the result. From this perspective, I find the term “non-human” collaborators misleading: when a DH-er uses certain hardware or software, collaboration arises between them and the distinct methods, decisions, and biases of the humans behind the digital tools.
Collaboration in all forms is necessary for producing complex, well-organized, and accessible DH projects, as is developing a shared understanding of project and data management strategies. As Dr. Otis explained in her video lecture, establishing a timeline, defining content scope, and identifying and mitigating risks early on is key to producing a cohesive final product within necessary time and budget parameters. Additionally, file-naming and metadata creation methods must be standardized and practiced among all members so the research and/or data behind the project can be accessed, checked, and used for further historical inquiry (don’t be that guy from the video!) It’s also beneficial to keep copies of project data in various places and formats in case of emergency. By using these strategies and more, our project teams should be able to move through the stages of development described in Tabak’s article, from initial vision to dissemination of the final project to closing, reflection, and sustainability protocols.2
Until next week,
Alexa
Alexa, your analysis here is really good and the example you mentioned from your small group session helped put the things we learned in the reading into perspective that was really informative! You are right that with all these digital tools we must understand them as something curated by a group of individual programmers and DH historians, something to really consider as we’re brainstorming our final projects
While the video was somewhat tongue in cheek, it came way too close to the norm for data management in the past. Only with the replication crisis of the last two decades has reproducibility now become a central concern of research. This requires the data be available in a form other researchers can understand and use. “We have no idea what those column headings mean anymore” is no longer an acceptable research practice.
Alexa, I really related to your first paragraph because I also prefer working independently and having control over my own work. I liked your point about the people and decisions behind digital tools. Your Google Maps example makes the idea of human and non-human collaboration much easier to understand.
A good project manager is key to handling your personal obversions to group projects. I share them. I find that it is better for me to either have the role of project manager or team lead, as that gives me more control over the chaos of my ADHD world. Have a PM in place that can accommodate various work styles is key to success.
I also dread group projects in class. I’m glad we read these texts about collaborative DH projects before being assigned to our groups. I think they gave us an added perspective on what it takes for a group to achieve its goals, as well as how easily things can fall apart. That said, once we got into our groups, we had a heads-up on how to prepare better. Plans will always go astray, but the more prepared you are, the easier it is to handle it when it happens. Another added bonus was Dr. Otis forming groups with similar disciplines and backgrounds, so at least something connects us rather than being randomly assigned to people. This supports the idea that it is about coming up with a project and executing it through tools as a learning process. Rather than learning how to find survival skills in a group setting.
Hi Alexa! You mentioned that you find Griffin and Hayler’s use of the term “non-human” misleading in the context of their article. What do you think a better term might be? Or maybe there need to be multiple terms for the different types of digital tools and structures used? Language is super important in communication and in collaboration; I’m curious to know what language you might use here.