arXiv subjects

Greg Wilson

Publications and source records attributed to Greg Wilson.

14 recordsLinked to original sources

arXiv2026

Twelve Quick Tips for Managing IT Disasters in Small Research Software Teams

In 2025, the US government launched an unprecedented series of attacks on its own scientific research groups. A year later GitHub dropped below 90% availability for the first time, while wildfires in Canada, France, Spain, and elsewhere forced researchers from the homes and labs. These events and others have reminded us just how fragile research computing systems can be, and that planning for disasters is one of the most effective ways to prevent them. This paper is a short guide to disaster planning and recovery for a small research software team. The tips assume you are doing everything yourself on top of your regular job, and that you aren't an experienced system administrator. Some of the tips do require that kind of expertise, but most research institutions have research computing groups, data librarians, and environmental health-and-safety offices whose entire job is to help with exactly these problems. This paper tells you what "done" looks like; they can often provide it.

cs.SE↗

arXiv2026

Turning interest into institutional change: teaching advocacy for sustainable research

Systemic change across the digital research landscape is required to reduce the environmental impact of digital research, but while many researchers and technical professionals are motivated to act, they often lack the skills required to translate motivation into lasting organisational change. We present an open-access course that teaches the foundations of advocacy and organisational change to researchers, research software engineers, and research technical professionals. Structured around the UNICEF five-step advocacy cycle, the course covers stakeholder analysis, power mapping, coalition building, storytelling, framing and messaging, and evaluation. It is grounded in the UK policy landscape, including the Concordat for Environmental Sustainability and the UKRI Environmental Sustainability Strategy, and uses a fictional case study to make concepts concrete. The course is designed as a dual-layer resource in which workshop slides and extended self-study notes are contained in a single source material. A short pilot was delivered at the NetDRIVE Net Zero DRI Summer School in June 2026. The course is freely available under a CC BY 4.0 licence.

cs.CY↗

arXiv2025

10 quick tips for making your software outlive your job

Loss of key personnel has always been a risk for research software projects. Key members of the team may have to step away due to illness or burnout, to care for a family member, from a loss of financial support, or because their career is going in a new direction. Today, though, political and financial changes are putting large numbers of researchers out of work simultaneously, potentially leaving large amounts of research software abandoned. This article presents ten tips to help researchers ensure that the software they have built will continue to be usable after they have left their present job -- whether in the course of voluntary career moves or researcher mobility, but particularly in cases of involuntary departure due to political or institutional changes.

cs.SE↗

arXiv2024

It Will Never Work in Theory

We have been trying to get software engineering researchers and practitioners to talk to one another for over a decade. This paper describes what we have done, assesses our impact, and recommends an approach that we hope will have greater success.

cs.SE↗

arXiv2017

Ten simple rules for collaborative lesson development

The collaborative development methods pioneered by the open source software community offer a way to create lessons that are open, accessible, and sustainable. This paper presents ten simple rules for doing this drawn from our experience with several successful projects.

cs.CY↗

arXiv2016

Ten Simple Rules for Making Research Software More Robust

Software produced for research, published and otherwise, suffers from a number of common problems that make it difficult or impossible to run outside the original institution, or even off the primary developer's computer. We present ten simple rules to make such software robust enough to run anywhere, and inspire confidence in your reproducibility, and thereby delight your users and collaborators.

cs.SE↗

arXiv2016

Good Enough Practices in Scientific Computing

We present a set of computing tools and techniques that every researcher can and should adopt. These recommendations synthesize inspiration from our own work, from the experiences of the thousands of people who have taken part in Software Carpentry and Data Carpentry workshops over the past six years, and from a variety of other guides. Unlike some other guides, our recommendations are aimed specifically at people who are new to research computing.

cs.SE↗

arXiv2015

Software Carpentry get more done in less time

The aim of this study was to investigate if participants of Software Carpentry (SC) get more done in less time. We asked 32 questions to assess 24 former participants to analyse if SC gave them the computing skills to accomplish this. Our research shows that time was already saved during the workshop as it could shorten the learning process of new skills. A majority of participants were able to use these new skills straight away and thus could speed up their day to day work.

cs.CY↗

arXiv2014

Which Sustainable Software Practices Do Scientists Find Most Useful?

We studied scientists who attended two-day workshops on basic software skills to determine which tools and practices they found most useful. Our pre- and post-workshop surveys showed increases in self-reported familiarity, while our interviews showed that participants found learning Python more useful than learning the Unix shell, that they found pointers to further resources very valuable, and that background material---the "why" behind the skills---was also very valuable.

cs.SE↗

arXiv2014

Code Review For and By Scientists

We describe two pilot studies of code review by and for scientists. Our principal findings are that scientists are enthusiastic, but need to be shown code review in action, and that just-in-time review of small code changes is more likely to succeed than large-scale end-of-work reviews.

cs.SE↗

arXiv2013

PLOS/Mozilla Scientific Code Review Pilot: Summary of Findings

PLOS and Mozilla conducted a month-long pilot study in which professional developers performed code reviews on software associated with papers published in PLOS Computational Biology. While the developers felt the reviews were limited by (a) lack of familiarity with the domain and (b) lack of two-way contact with authors, the scientists appreciated the reviews, and both sides were enthusiastic about repeating the experiment.

cs.SE↗

arXiv2013

Software Carpentry: Lessons Learned

Over the last 15 years, Software Carpentry has evolved from a week-long training course at the US national laboratories into a worldwide volunteer effort to raise standards in scientific computing. This article explains what we have learned along the way the challenges we now face, and our plans for the future.

cs.GL↗

arXiv2012

Best Practices for Scientific Computing

Scientists spend an increasing amount of time building and using software. However, most scientists are never taught how to do this efficiently. As a result, many are unaware of tools and practices that would allow them to write more reliable and maintainable code with less effort. We describe a set of best practices for scientific software development that have solid foundations in research and experience, and that improve scientists' productivity and the reliability of their software.

cs.MS↗

arXiv2010

The Wide Field Spectrograph (WiFeS): Performance and Data Reduction

This paper describes the on-telescope performance of the Wide Field Spectrograph (WiFeS). The design characteristics of this instrument, at the Research School of Astronomy and Astrophysics (RSAA) of the Australian National University (ANU) and mounted on the ANU 2.3m telescope at the Siding Spring Observatory has been already described in an earlier paper (Dopita et al. 2007). Here we describe the throughput, resolution and stability of the instrument, and describe some minor issues which have been encountered. We also give a description of the data reduction pipeline, and show some preliminary results.

astro-ph.IM↗