I’m looking for engagement, critical reflection, and experimentation.

Push yourself!

Active engagement

Don’t just take it in, be active in the class discussion. Leadership and positive contributions to the class discussion, wherever that takes place. Each session will involve hacking, poking, prodding, and otherwise doing digital history. We can spend time every session considering how all of this will play to the experiment as well.

Open Notebooks

9 meeting entries (you are encouraged to make a repository in github just for these). Your entries should/could reflect on the readings, the discussion, and what you learned from the session leader’s experience that week. Ideally you’ll write these during class time.

You should also be frequently documenting your experiment as it develops. If you are working on a Programming Historian tutorial, make a particular note about any hidden ‘gotchas’ you encounter. Video notes/walk throughs are encouraged. You can post these on youtube, vimeo, or similar. You will select your nine best entries for me to grade. Again, YOU WILL WRITE THESE DURING APPROPRIATE CLASS TIME Therefore bullet points etc are appropriate. These are like ‘lab notebooks’ that help you document your experiments and understanding. They are not great works of literature. They are notes to help ‘Future You’ to understand what the hell ‘Past You’ was up to.

Discussion Leading

For 1 or 2 sessions (depending on enrollment numbers) you will lead the group through your experience with a paricular Programming Historian tutorial (these will be assigned). Walk us through the goals of the tutorial, the nature of the examples, the hidden gotchas, the tacit assumptions, the hiccups, rough patches, dead ends, frustrations, and triumphs. Expand on the tutorial by thinking through how you might use it on a research question pertinent to your own MA work; think through what the tutorial might usefully help us do or learn or see in Mallory’s writings.

The tutorials in question are listed on the schedule page; I’m open to alternatives at The Programming Historian or elsewhere if they are germane to the larger thrust of the week or there is some compelling reason; talk to me first though.

Experiment

The major experiment in this class will be to explore the issues of digital history as discussed in this course in the context of Mallory’s papers. You will deploy (and document) at least three congruent tools/approaches learned from the The Programming Historian (and/or other resources) using Mallory’s writings as datasource. By ‘congruent’ I mean, ‘makes sense that these things go together towards a reasonable goal’.

This experiment can be an individual effort, or a collaborative effort. The experiment will have a public-facing website that you create documenting the data, its transformations, your analytical apparatus, observations or conclusions.

Reflective Short Unessay

This unessay reflects on the issues of digital history as experienced by the student in the course of completing the major experiment. The length and format need only be ‘appropriate’ and ‘compelling’. It can be built into a ‘paradata’ section to accompany your experiment (where ‘paradata’ is a document that explains how/why/etc for a digital project, the hidden work to make the thing real). This unessay may be highly personal, and does not necessarily need to be ‘written’ in a text-forward dead-tree format.

The grading of the experiment and the reflective essay will follow the unessay conventions. We will talk about this.

It would be a good idea to bring your laptop or device to each session. Remember, you don’t need to be ‘techy’, whatever that means. You just have to be willing to give it a go and to be open and frank about what happened next. And you know what else?

You do not have to work in isolation

Digital history can be very frustrating. You don’t have to work in isolation. You may collaborate; you can google for solutions (but for the love of god DO NOT accept any ai-generated ‘answer’); you can ask for advice where ever seems appropriate. Make sure, when you do get frustrated (and you will), to just walk away from the computer. If it doesn’t come after 30 minutes it won’t come after 3 hours of faffing. I don’t want to here about heroic hours spent fighting with the computer. There is more than one way to do things digital, and when you’re frustrated you won’t find any of them. Shut it down, go for a walk, have a coffee. Come back when you’re fresh.

But do acknowledge in your work any collaboration or help you have received. Failure to acknowledge help received will be regarded like a failure to cite.

But what about AI?

‘AI’ is mostly a marketing term. But there may be cases where it is appropriate to use things like LLM (large language models) or other such tools in the context of doing digital history.

  • for understanding what code does
  • for making alterations to example code for a particular use
  • for expanding code to do new things.
  • when a tutorial or how-to employs such a technology

However:

  • you may NOT use such tools for your open notebooks, because… what would be the point? The open notebook is for Future You. So… just don’t, ok?

Grading

The university makes me put percentages on these different aspects, though I like many other scholars view such things as antithetical to real learning. Take these numbers as indications of the relative effort I would like you to expend.

Class Participation: 10% + 10% for your session(s) that you lead.

Open notebook entries: 30%

Experiment: 30%

Unessay: 20%

Caveat

I reserve the right to rejig these assessment exercises and criteria to take into account the enrollment in the class; if we happen to be a smaller-than-average class size, these elements will be adjusted to reflect the higher levels of engagement needed for a successful class. Any such rejigging however will be discussed with you within the first two weeks of the class.