Important notes on using GitHub
Caution when using GitHub
This notice was emailed to us from UK Biobank.
Use of 3rd party code-sharing repositories (e.g. GitHub)
It has come to our attention that researchers are increasingly uploading software tools and analysis scripts - which is an acceptable practice and required by some journals - to web-based repositories (such as GitHub). Given that such scripts may have been run on underlying UK Biobank data, please ensure that no UK Biobank data are uploaded to these repositories (either as a result of being incorporated within the analysis code, or otherwise being referenced in a manner that leads to its inclusion).
This callout block added by us to clarify things. When they say don’t upload UK Biobank data, they dont just mean saving a data file but also if you paste any data into the code or Quarto files themselves. This is also NOT allowed.
Making any participant-level UK Biobank data available on a web-based repository is not acceptable. As such, UK Biobank would re-iterate that all researchers exercise appropriate oversight, care and control to ensure that such uploads of data do not occur.
UK Biobank considers that the great majority of researchers are aware of UK Biobank’s requirements with regard to processing and storing of its data, and reminds all researchers that UK Biobank participant data must always be treated in a manner consistent with the provisions of the Access Procedures and the MTA (and the data security provisions of the MTA) and specifically:
- may not be shared (directly or indirectly) with other third parties (outside of an approved application).
- may not be uploaded (directly or indirectly) to web-based or other repositories accessible by third parties.
Aside from any legal consequences, any default in complying with these obligations may lead to applications and registrations being terminated.
A guide to researcher best practice for use of 3rd party code sharing repositories is available on the UK Biobank website here: https://www.ukbiobank.ac.uk/media/1vhh2vip/github-3rd-party-sharing.pdf
Best wishes,
UK Biobank
Your access to RAP will be revoked if you don’t use Steno’s GitHub
This is to clarify the importance that you need to use the repository we set up for you on GitHub within the Steno GitHub Organization. If you don’t use this repository to do your work, we will remove your access to the RAP and you will no longer be able to work on the UK Biobank data within our project.
Why does we have this policy? Because we need to be able to monitor the work being done on the UK Biobank data to make sure we are following their rules and don’t accidentally upload data to a public GitHub repository. We have several automated and manual processes in place that work with our Steno GitHub Organization setup, so if you aren’t using that, it makes the steering committee’s job a lot harder.
Your access to RAP and GitHub repo will be removed if you haven’t worked on the project for a while
We follow the security practice of giving the minimal required access permissions to the RAP and GitHub repositories. This includes only giving access to those who are actively and regularly working on the UK Biobank data for an approved project. So these are the conditions under which we will remove your access to the RAP and the GitHub repositories:
If you are done with a project where the paper has been published, you no longer need access so we will remove you.
If you go on paternity leave, sick leave, or any other kind of longer-term leave, we will (temporarily) remove your access until you are back and ready to work on the project again. You can easily request access again when you are back. You will need to inform us of these leaves, so we know not to delete your repository permanently. It’s easy enough to give you access again when you are back.
If you haven’t worked on the project actively for 6 months, we will remove your access and convert your repository to an archived state (or delete it completely), and declare it abandoned. This is just a security and management practice we have to make sure that the number of repositories doesn’t become unmanageable and that the existing repositories actually reflect the work that is being done.
We will only delete your GitHub repository permanently if you haven’t finished your project, haven’t worked on the project for more than 6 months, and have made very little changes to the repository (meaning there isn’t much work to save). So importantly, we will convert it to an archived state only if you haven’t done much work on the repository and there isn’t much work necessary to save.
Update your project status through GitHub issues
Whenever your protocol is ready to be uploaded to Zenodo, or when you are ready to publish and so need to upload a preprint, or when your paper has been published, you need to update the status by creating a new issue in the GitHub repository for your project.
This is important because it allows us to keep track of the status of all the projects and to know when to assist or do certain tasks (e.g. upload the files to Zenodo).
What you do in your paper doesn’t have to be the same as what you wrote in the protocol
The purpose of the protocol is not to make a strict, inflexible plan that you have to follow exactly as written. The purpose of the protocol is to help give you a guide and to clarify to others what you intended to do when you started the project. It helps a lot to take a step back and design how you might do your work. This can help immensely when you come up to challenges later on if you’ve taken the time to think about what it is you actually want to do.
Protocols are used to communicate initial intent for the research so that you can communicate to others that you aren’t doing “fishing expeditions” or “p-hacking”. But it also is completely fine to deviate from the protocol, as long as you describe why you had to deviate from it and what you actually did in the paper. So that it is an explanation of the process and that you are trying to be transparent about it.