A Pilot for Code Peer Review

This project aimed to provide Statistical Science students the opportunity to give peer-to-peer feedback on their computer coding, allowing for more peer learning.

This project addressed an identified issue where Statistical Science students received coding feedback solely from lecturers, limiting opportunities for peer learning. Statistical Science includes several modules where students are required to write computer code for data analysis and modelling. Currently, weekly computer lab tutorials run alongside lectures, where students write code to answer set questions. These assignments are submitted via Moodle for formative assessment by the module lead, who provides feedback.

We proposed introducing peer review for coding assignments. Peer review offers several benefits: students can learn from each other's work, develop skills in reviewing code, and gain experience with widely-used computing tools. These skills are valuable as students will likely use similar tools in their future careers.

Our approach involved a student-led discussion and development of a peer review process. We used GitHub, a free platform designed specifically for software development, as the peer review tool.

This initiative is novel and allowed the small group of student partners to take ownership and shape the process and outcomes. They defined the review workflow, determine the tool’s features, and influence the overall user experience.

The final results of the project addressed the identified issues, producing a workflow and accompanying documentation to facilitate implementation in other Statistical Science modules and beyond. Several module leaders have expressed interest in trialling and adopting this approach.

What did you set out to do and why was this project important?

We developed and piloted an innovative code peer review system for undergraduate computing modules in Statistical Science. In these modules, students were receiving a general feedback on their coding assignments, missing opportunities to learn from peers and develop collaborative skills for their future careers.

Our goal was to enable the integration of code peer review into modules with software components to enhance student learning. Through this approach, students can provide and receive timely feedback, develop critical skills, and learn to use career-relevant software.

This initiative is important as it exposes students to diverse problem-solving approaches, fosters collaboration, and builds critical thinking skills. It also prepares students for professional coding practices.

How did it go?

A key piece of student feedback, based on their past experiences, was that Moodle's tools are not designed for conducting thorough code reviews. Based on this observation, our team of staff and students co-created a workflow that integrates GitHub – a popular software development tool - with existing Moodle systems to facilitate an improved peer learning experience. In other words, one feature of our workflow is that, not only do we capitalise on the advantage of code reviewing on GitHub, but we also keep the collection and distribution processes on Moodle, which is more familiar for students and manageable for teachers. This was a consideration highlighted by the students themselves.

Another feature of our workflow is that it offers flexibility for the students, as we are aware that the willingness to be exposed to the GitHub platform could be different among students. While a student may use only a small number of GitHub operations to do the whole peer-reviewing, if a student, for example, wants to gain more experience of using the GitHub platform, then we have the additional guidance for them to go deeper on their own.

What was the outcome of the project? What difference has this made to staff or students?

The primary outcome was the successful development of an end-to-end, documented workflow for implementing code peer review in computing modules. This system innovatively integrates GitHub's powerful review features with Moodle's familiar interface for assignment management, a design choice based on direct student feedback.

The student partners' leadership and work on the project were formally recognised when they won a UCL Open Science and Scholarship Award in the award category for activities led by undergraduate or post-graduate students. For staff, this provides a framework that can be adopted to enrich their modules. As a result, several module leads have already agreed to beta test the workflow for potential adoption.

What was involved in terms of approach, logistics, time or resources?

Practically, at the start, the project team met in person to discuss the scope and plan. We held a few more in-person meetings including a wrap-up meeting but most of the communication was informal and virtual. The approach was highly iteractive and practical. An important lesson we learned after initially getting stuck trying to design a complex system from the outset was to take a step back, question our assumptions and simplify the problem. Instead of planning everything in theory, the student partners started small by taking a simple piece of code and trialling different review processes directly on GitHub. We held meetings as and when to discuss findings of this, share technical tips, and collaboratively refine our ideas into a workable system. In the main the autonomy and skills of the students was very high.

ChangeMakers projects are intended to support students and staff working in partnership. How did this aspect of the project go?

The partnership between staff and students was absolutely essential to this project's success and went beyond our initial expectations. What surprised us most was how quickly our student partners were genuine co-creators and project leaders.

Our student partners brought irreplaceable insights about the student experience of coding modules, identifying specific pain points not considered beforehand - such as the difficulty around GitHub for students with no prior experience, and the importance of maintaining familiarity with Moodle (which they were familiar with) while introducing new tools. They designed the peer review templates and testing protocols, ensuring the system would genuinely serve student needs rather than imposing assumptions and what was considered extra work.

Moreover, the PhD student team member provided a unique bridge perspective, helping translate between undergraduate issues and ideas, and senior statistician. Last but not least, the staff member, who is very experienced in collaborative coding on GitHub, could provide valuable technical guidance to the students as and when requested so that they could realise their ideas.

What was your specific role in the project? What did you learn as a result of being involved?

The most important lesson was that, although being creative and brainstorming are important, it is best to start with a practical, simple approach rather than designing a complex system in theory from the outset. At the beginning, although we were very creative about a lot of potential ideas and features the workflow should cover, we got stuck from time to time because of the difficulty of designing a complex workflow that could take in all those points and the lack of practical knowledge about the implementation of these ideas. So, instead of trying to “bite off more than we can chew”, we started from a very simple piece of R code and requirement, created repositories on GitHub and trialled with different types of reviewing and GitHub operations on it. We discussed our findings in the meetings, shared technical tips that might be useful, and excluded or improved upon those ideas we had during the brainstorming. During this process, not only did we learn about how each of the GitHub features operates and potentially being of use, but we also clarified and validated our ideas and converged to a more complete and workable system.

A second key lesson was that designing an adaptive system that gives students choices is far more effective than trying to persuade them to adopt a rigid process. By offering flexibility in how deeply students could engage with GitHub, we catered to different comfort levels and created a more inclusive and user-friendly tool.

What, if any, are your next steps for this project?

• Beta testing of the tools and workflow with a small number of module leads
• Department of Statistical Science podcast episode and department blog on their Sample Space website
• Dissemination/presenting to (UCL) conferences and meetings