Data Science @ The Strategy Unit – GitHub as a team sport

GitHub flow

Easy starter: tell people what the purpose of the repo is and how to use it. This is what a README is for. This is an absolute must to lower the bus factor.
We should be prevent accidental file upload immediately. Use a .gitignore to exclude likely data files (as well as other unnecessary files). We’re thinking about common templates/cookiecutters.
Communicative files (README, .gitignores) are good, but so is vigilance (code review).
Owners/deputies are in charge of ‘GitHub gardening’ (keeping issues in order, labelling, milestones, etc).
Deputies help with bus factor.
The owner can be auto-selected as the reviewer. We’re experimenting with this for repos with external contributors, especially.
Data is stored elsewhere, on Azure or Posit Connect, due to sensitivity and size. This should be planned before you begin and recorded in the README.

PRs should solve the issue they’re related to. Occasionally one fix may solve another.
They should be named to explain what they do. The issue might be ‘the red button doesn’t work’; the PR might be ‘fix the red button’.
They should be small in terms of lines of code and files touched. This will make it easier and faster to understand and assess the changes.
The submitter should mark themself as the ‘assignee’ and choose a reviewer. You may want to chat with the reviewer to let them know if they have time.
For context, link to the issue(s) being closed with the magic words (‘closes’, ‘fixes’, etc), which will also close those issues as completed.
Include a short explanation or bullet-points of what the PR does. Provide any extra information to make the reviewer’s life easier (areas of focus, maybe) or to ask a question about some aspect of what you’ve written.
The PR submitter is the one who clicks the merge button. This is in case the submitter realises there’s something they need to add or change before the merge.