Appendix C — Learner personas

These are learner personas for the Git for Scientists workshop, in the sense used by Greg Wilson in Teaching Tech Together: short, concrete characterisations of the people we actually teach, so the course serves real learners rather than an average of everyone. There are three, synthesised from the pre-course survey and the goals participants wrote in their own words. Each follows the same four-part shape: general background, what they already know, what they want to do, and any special needs. We use them as a check: every learning objective should answer a need that at least one persona has, and every formative check should target a gap one of them arrives with.

The three are Arti (the fearful outsider), Bianca (the collaboration-driven R user), and Cem (the controlled-AI researcher).

C.1 Arti, the fearful outsider

General background. Arti studied environmental sciences for their BSc and MSc, worked as a scientific assistant in the social sciences for a couple of years, and did a PhD in mechanical engineering. English is not their first language, but they are comfortable working in it. Arti now works as a post-doc in a research group where some people are highly proficient with Git and GitHub and some have little to no experience.

What they already know. Arti has written R scripts that run to a couple of pages and the occasional line of SQL. They are most comfortable communicating by email and writing in Google Docs and MS Word. They appreciate that files sync in the cloud, but still prefer to save versions by hand and share them as attachments. They know that CSV is the better way to store data, yet keep reaching for Excel because spreadsheets feel familiar. Arti uses LLMs for a wide range of tasks and has watched colleagues use agentic coding tools. They have used Git once or twice for basic things, but a command that returned an error stopped them cold, and now they tend to avoid it. Their honest goal, in their own words, is to “not feel afraid of Git”: a previous Git workshop left them demotivated, because they felt it was a personal failure that they could not follow what was happening.

What they want to do. Arti wants to collaborate confidently with colleagues who come from computer science, software engineering, and statistics. They once heard a research software engineer say “every PhD should be forced to learn Git”, and they are willing to try again, provided the room feels safe. What matters to them is realising that the buttons they click in RStudio and on GitHub are the Git commands: clicking the push button is git push. Using the point-and-click interface is not cheating or a lesser path, and seeing that equivalence is what lets them stop feeling like an impostor.

Special needs. Arti is uncomfortable in a group of new people and prefers working alone or in a pair rather than a larger group. Their attention span is short and their tolerance for noise is low. They have a family and can only work during regular hours on weekdays. For Arti, the safe-to-fail framing (almost everything in Git is reversible) is not a nicety; it is the difference between staying and leaving.

C.2 Bianca, the collaboration-driven R user

General background. Bianca is a PhD student and a confident R user. She has used R since the start of her PhD for statistical analysis and data visualisation, and writes programs a couple of pages long without much external help. Her research is increasingly collaborative: she now has several projects with co-authors, and the way she has always worked is starting to strain.

What they already know. Bianca is fluent in R and RStudio and stores her data in machine-readable formats such as CSV. She is comfortable with the concepts of version control (commits, branches, staging, pull requests) because she has clicked through them in the GitHub web interface, but she has never run any of it from a project on her own machine, and never as part of a team. Today she versions her analysis files by hand, with names like analysis_final_v3.R, and shares them by email or cloud folder. That approach makes it hard to track what changed, recover an earlier state, or let a collaborator work alongside her.

What they want to do. Bianca wants to document the evolution of her analyses so that changes are easy to follow, to recover earlier versions when she needs them, and to collaborate with co-authors and reviewers confidently rather than nervously. She frames it as using GitHub fluently for collaboration and transparency, and as a step toward open-science practice in her field. Reviewing and being reviewed through a pull request, the way people already leave comments in tracked changes, is exactly the workflow she is missing.

Special needs. Bianca is motivated and quick, so the pacing risk with her is impatience, not fear. She may finish a your-turn exercise early and get restless. Because she already knows the concepts from the web interface and is curious about what the underlying commands are, she is the learner who benefits most from seeing the command that sits behind each GUI action, which gives early finishers something to chew on without pushing everyone toward the terminal.

C.3 Cem, the controlled-AI researcher

General background. Cem is a researcher who has already folded LLMs into daily work and, in some cases, uses agentic coding tools most working days. They are pragmatic rather than enthusiastic: they see that opting out entirely would leave them at a disadvantage, but they do not trust these tools blindly.

What they already know. Cem uses LLMs regularly and has tried agentic tools, so they know what these tools feel like in practice, including how often they hallucinate. They store data in machine-readable formats and can find their way around R, but they have only used Git for basic tasks and have never leaned on it to keep AI-assisted work under control. They describe their current tool use as probably more immature than it should be, and they suspect some of these tools are easily misused but hard to avoid.

What they want to do. Cem’s goal is control and provenance: to produce work assisted by AI whose results are good quality and backed by reliable, traceable sources. In their own framing, they want AI to “do the time-consuming, annoying part” so they can do the fun work, without surrendering judgement. What they need first is the Git and GitHub foundation that makes every change (whether a human or an agent made it) versioned, documented, and open to review. Reviewing an agent’s pull request is the same skill as reviewing a colleague’s, and that is the concrete point where “controlling AI” stops being a slogan. They also want an honest overview of where and how these tools can be used securely in research.

Special needs. Cem wants the scope stated plainly. This workshop is the foundation, and the agentic-coding follow-up (agentsforsci) is where the AI-specific workflows come. Setting that expectation up front is what keeps Cem engaged rather than waiting for agent content that is not on today’s agenda.