Digital skills and scholarship for researchers 3: New Zealand workshops
Mozfest had given the project a good kick and start. Working with Billiy Meinke helped me reframe my way of thinking, and I was impatient to find out what the session would look like with a room full of academics. I went back to talk about how to go about this with Cameron McLean, who had been part of the original biscuit eating exercise that got this started.
Cameron McLean was a PhD student at the University of Auckland who I was co-supervising. He had contacted me after coming across this blog, and I encouraged him to contact Mark Gahegan from the Centre of eResearch to discuss a possible PhD. Part of his thesis work focused on trying to understand how to make the implicit knowledge we have in our research workflows explicit. (His thesis is about more than that – so hey, go read some of his work).
I related to him what I had learned at MozFest from Billy Meinke. I introduced him to the concept of the 3 objects and 3 actions that we had used at our sprint at MozFest, and he stared back at me with the same confusing gaze that I must have given Billy on our first day of work. Nonetheless, we went ahead.
We managed to gather a number of people from the University of Auckland that were involved in research and we ran a session. Like we had done at Mozfest, we asked people to write down statements in the form of ‘I [action] [object]’ and mapped those into the action/object tree. Like at MozFest we followed that with a second capture in the form ‘I [action] [object] for [context]’ which gave us an idea of what the motivation for those things were. As in MozFest we saw that the action/object combinations that were produced were slightly different when a justification was needed. In other words, there are things we do, and then other things that we do because there is a ‘because’. For example, in the context round we started finding statements related to ‘because my job requires it’. For some reason, adding the context to the statements somewhat elicits a different set of combinations (or makes values explicit), which was useful to know.
At Auckland we added another round which was divided into two phases. By now we were moving forward in our thinking about what this ‘semester course’ would look like. So we wanted to ask researchers what were the digital skills that they kept teaching over and over again as new people entered their research group, and that they wished they didn’t have to. We captured some more of this, we looked for what were the commons skills and which skills were more ‘lab-specific’. This was a first step towards identifying what topics would have to be included in the course.
In the next round we did something slightly different – we tried to get at what they wished people entering the lab knew how to do. While it seemed not too different from the previous round, what this did was elicit (we didn’t plan for this) a total accelerated venting of what actually frustrated researchers. A lot of what came out of this round were behavioural attributes, such as collaboration, knowing how to ask questions, etc.
The overview of the map did not look too different from the one at MozFest. We also saw that there was an accumulation of paper notes around the ‘paper’ object. Not surprisingly, it is the main artefact through which we measure value of our researchers.
At the eResearch Symposium in Queenstown in 2015 Cameron and I teamed up with Matt McGregor from Creative Commons Aotearoa New Zealand to run a workshop. This time we would have a group of people who were more tech savvy, but also from diverse institutions from New Zealand. We essentially ran a similar workshop, with more of a focus on what topics would you teach if you were given the opportunity to decide the content of the course.
We learned from all of these workshop that if we were to build a course to solve the issue of digital literacy we would need not only to teach the skills but also tackle, explicitly, specific behavioural attributes. More importantly we needed to focus on creating an understanding of the value of treating non-traditional research artefacts (data and software) with the respect they are due. We also found agreement in that a course for students was not going to be enough to solve the problem: other research staff also needed access to this training. The problem was becoming bigger. It was also becoming more exciting.
It also reinforced the importance of providing not solely a set of skills, but also the social context which potentiates the value of these skills. We also agreed that the objective should not be to encourage students to become seasoned software developers, but instead to give them enough confidence to undertake small software projects and to provide them with a common language that they could share with software developers for larger projects.
We had been shown a pretty clear roadmap and a pile of bricks to make the awesome happen.
We now needed to find an architect.