Subject and Object Required
Despite the title, this won’t be about objects and coding. It’s about the subject behind the requirements we gather, the people we gather those objectives from. For the past couple weeks, we’ve been bogged down in some of the practical instruction we’re getting as part of the Praxis program, so I had forgotten about some of the project planning and management instruction we got a few weeks ago. When introducing us to requirements gathering, Jeremy and Bethany modeled the methods we might use as project planners when meeting with a client for whom we’re building a tool. Jeremy asked specific questions and redirected Bethany to the issues he wanted to cover. As I wrote a few weeks ago, perhaps over-critically, this is how some of Prism’s history, and what I took to be its existing expectations, were revealed to the Praxis team. Now I want to step away from the content of that discussion and look at the form — what methods and approaches it modeled rather than what particular information it revealed. If we were to extend this model of client-focused project planning into project management and evaluation later on, we might continue to check back with our “client” Bethany to make sure the tool we build for her is coming along as she would like. It would be her goals as a user that would become our end goals as tool-builders. But this instruction on how requirements gathering works is at odds with the “Prism is whatever you want it to be” message of the Praxis program. Is our job to learn the many skills necessary in DH by building a tool for a given client’s needs, or is our job to create a tool for the broadest possible audience, being cautious not to assume too much about how it will be used? I wonder if this question is similar to a question about what kind of role in the DH community we want, or what role Praxis is preparing us to take. Are we collaborating on scholarship or are we in a support role, providing a technical service that shores up someone else’s scholarly project? If we’re creating a tool for a very wide audience, how does this activity fit into our own scholarship? Are we academics or “alternative academics”?
Now I realize that I was wrong to point to the specifics of Bethany’s history of Prism as the source of my confusion over just how much Prism comes with particular expectations and how much it’s really ours to create. I came into that meeting with the expectation that we could make Prism however we wanted, so I was surprised to see that we might be gathering requirements from outside the Praxis fellows. So now I’m interested in the higher level question of where we’re gathering requirements from and to whom we’ll be accountable throughout the process. Are we acting like Bethany is our client who has a scholarly project in mind but needs a technical team to help think it through and make it happen? Or do we get requirements from the entire Praxis team, with all our individual hopes and expectations but a potential user population so wide we have to somehow build for uses we will never anticipate? If it’s the latter, we would do well to take Sarah’s advice on our requirements document to heart: “we want to be careful about pigeonholing Prism” because it could have uses beyond the primary pedagogical and second-level interpretive ones we’ve talked about so much.
I’m not trying to disparage either framework, but I am hoping we can talk about which one applies to the Praxis program since this seems to cut right to the point of it all. This dichotomy makes a lot of sense to me, helps me orient Praxis in relation to the solitary academic scholar I’m so familiar with, but I realize that it’s a dichotomy that Bethany’s most recent post and some of the people whose work she cites all seek to break down. We all want to be visionaries and risk-takers, but sometimes I react quite critically to new things and, much like Kathleen Fitzpatrick’s grad student questioner, I might be a little too worried about the current academic “ecology” to feel confident in disrupting it. But it has only been a month.