¶ 1 Leave a comment on paragraph 1 2 After the rush of last week, I’ve started to focus on the details of end/line (the new, group-approved name for the “encoding as close reading” project). I’ll be serving as project director and project manager, articulating its overall vision and ensuring that our group of five keeps it on track. Obviously, the need to communicate its goal of providing a platform for a particular mode of poetry/poetics and digital humanities pedagogy will prove challenging, as will the quick turnaround required for this project. Though I’ve never directed a project before, I hope to attend the 13 March GCDI workshop on digital project implementation. And while I do have some professional experience managing web development projects, I’ve only done so in existing infrastructures where, for example, third-party vendors handled all hosting or database tasks and details or we hired a professional designer to produce the marketing material. With end/line, I’ll need to think all of those tasks that I’ve previously taken for granted. I’d also like to hone my existing project management skills, and have started reading a host of articles on the subject at A List Apart.
¶ 2 Leave a comment on paragraph 2 0 Despite these challenges, however, I’m excited about the prospects for end/line for numerous reasons. First, the Textual Coding Initiative is a longstanding digital humanities community (dating back to the 1980s) and, by interacting with its verse module, even in this small way, I think we can articulate its ongoing importance to the field (and to literary studies in particular). Second, my work at the Graduate Center has drawn me, increasingly, to twentieth- and twenty-first-century experimental poetry that might frustrate encoders and challenge close readers. When the class workshopped my initial proposal, Eddie mentioned Susan Howe as an example of someone whose work would be difficult to encode. I’d love for our final prototype to demonstrate, technically and visually, how encodings are themselves acts of reading that produce interpretations. Third, as Professor Brier often explained last semester, much digital humanities work ignores pedagogy; this project does not. And, finally, translating last semester’s thoughts, ideas, and curiosities into an application like this seems like a worthwhile goal.
2 Comments
This is a great starting place, Tom. Your sense that the “overall vision” is large and keeping 5 different groups on task will be challenging sounds accurate.
I’m wondering how you could drill down into that general description and enumerate more specifically how this will look on a daily/weekly/monthly basis. For example, will you communicate weekly with everyone? How will you do check ins? How often will you touch base with everyone? What platforms will you use, and how will you respond when someone doesn’t finish what they are working on? What is the best way to communicate deadlines, and what strategies will you use to help make sure that everyone receives the support they need?
Thanks, Lisa. In addition to class time, we’re also planning to hold weekly check-in meetings. I plan to send weekly digest emails too (I’ve used these at the work—basically they break down what we’ve done this week, what we’re doing this week, and what everyone needs from everyone else—and they’ve been successful). The platforms we’ll use are on our GitHub page: https://github.com/tlewek/encoded-poetry/blob/master/project-workplan.md. Communicating deadlines and strategizing about how to support everyone else on the team will be the big challenge, though—definitely need to spend more time thinking about the details here.