- Registered users must belong to Nottingham University Hospitals NHS Trust or be approved external collaborators.
- They must use their nhs.net email and have set up a 2 factor authorisation.
- If users leave the organisation, or are inactive after 6 months, they will be converted to outside collaborator, and after 6 more months removed.
- Users will be respectful of other users and follow code of conduct extracted from here.
- Repositories must be set to private until approved by an owner of the organisation repository.
- The first commit must be the .gitignore file included in this repository extracted from here
- Users must follow the open code checklist extracted from here
- In case of a data Breach, users must follow the breach action steps extracted from here
- Parts of code containing business/analytical logic must be covered by unit tests to provide assurance that the code works in the way that it says it works
- Code must be free of known malicious dependencies
Additionally, Here is a list of mandatory items to include in any organisation repositories (modified from NHS england way of working):
Every repo should have a README which as a minimum specifies clearly the purpose of the repository. Ideally this README file would be concise and include additional components covering ownership, development status, context, support for the user and how to contribute to the code. An ideal example readme can be seen here
Every Repo should have an apporpiate associated license and copyright notice. There are some cases when a license is not needed but this should be a thought through exception rather than the starting point. The NHS Open Source Policy states: "NHS staff exert intellectual property rights for code and documentation through Crown Copyright. Using a copyright notice e.g. Copyright (c) 2021 Crown Copyright ensures that rights to the relevant work reside with the UK Government, and that unless otherwise specified no-one else can copy, distribute or modify your work without risk. Licences then dictate further terms for how people may use copyrighted material.
All open source projects must be accompanied by a licence. The default option for NHS open source code is the widely permissive MIT Licence. Your project may choose to use APLv2 instead, and should consider doing so if your code is subject to regulatory requirements (see below). If you wish to ensure that no-one can make proprietary or closed source versions of your code, please use GPLv3. For all associated documentation you should use the Open Government 3.0 Licence: projects may use multiple licences for a project as long as they are explicit about which licence applies to which part of the project. Beyond licence assignment in a project’s README file, the full text of the relevant licences should be included in a top level directory LICENCE file."
| Licence | Use |
|---|---|
| MIT Licence | Default licence for all new code |
| APLv2 | Where code must be accompanied by legal notices |
| GPLv3 | To prevent proprietary or closed re-use of code |
| Open Government 3.0 Licence | Default licence for all documentation |
A markdown file in your repository that tracks noteable changes to the code. Recommendation is to use semantic versioning which reflects Breaking changes, New features, and
Fixes clearly.
A piece of text that encourages contributions in the forms of raising new issues and submitting pull requests. Include reference to the code of conduct and any guidance about branching strategy or style of commit messages to help contributions be made is a standardised way.
When your code contains a piece of code which someone else may use or reproduce then it's best to make clear the intended use for the code and any known limitations. One way to do this is to use a model card stating:
- model details
- Intended use
- Out-of-scope usage
- Training data
- Performance and Limitations
- Notes to the user
to support contributions being submitted in a standardised form you can include a pull request template for fixes and new features. This will then help contributors know what information to include to support these requests.
Contact details in the README are useful but this often depends on an appropriate shared mailbox being avilable.