| Archiving software |
How can you archive your software for preservation?
|
| Continuous Integration and Continuous Delivery/Deployment |
How can you use CI/CD in software development?
|
| Managing complex CI testing matrices for research software |
Efficiently test research software across multiple compilers, libraries, architectures, and platforms while managing CI resource constraints and maintaining fast feedback loops
|
| Citing software |
How can people cite your software?
|
| Creating and enforcing a code of conduct |
How to draft a code of conduct for a research software project and run a credible process for enforcing it, including reporting channels and proportionate responses.
|
| Performing a code review |
How do you review code?
|
| Creating software metadata with CodeMeta |
Guidance on creating a CodeMeta file for software projects.
|
| Computational workflows |
How to use computational workflows to automate and reproduce data pipelines?
|
| Creating a good README |
How to create a good README document for your software project.
|
| Credit and recognition for research software and people who write it |
Guidance on making software contributions visible, citable and verifiable, and building the evidence needed for career progression for people who write research code.
|
| Documenting code |
How to write technical documentation to explain to other developers and administrators how your code works internally?
|
| Documenting a software project |
How to write clear and useful software project documentation for end-users and collaborators?
|
| Documenting software using 'Read The Docs' |
How to use 'Read The Docs' tool for software documentation?
|
| Conducting dynamic analysis |
How to use runtime observation techniques — memory checkers, sanitizers, profilers, and fuzzing — to find bugs and performance issues in research software that static analysis and unit tests miss.
|
| Fostering equity, diversity, and inclusion in research software projects |
Practical guidance for research software projects on equity, diversity, and inclusion (EDI), covering inclusive contribution processes, accessible documentation and onboarding, support for underrepresented contributors, governance, and event accessibility, with attention to the academic power dynamics specific to research software.
|
| Adopting FAIR research software practices |
What practices and tools can help improve FAIRness of software?
|
| Future-proofing your research software |
How to design and build research software so that it remains usable and reproducible years after the initial project ends
|
| Improving environmental sustainability |
How to measure and improve environmental sustainability of software?
|
| Choosing languages, tools & infrastructures |
How to decide which programming languages, tools and infrastructures to use?
|
| Licensing software |
How to license your software for reuse?
|
| Using organisational GitLab CI infrastructure for your GitHub project |
Leverage local GitLab CI runners and specialized hardware for GitHub-hosted projects when standard CI resources are insufficient
|
| Packaging software |
How to package and release your software for distribution and reuse?
|
| Performance: profiling and optimisation |
How to profile research software to find performance bottlenecks and apply targeted optimisation techniques, with pointers to language-specific profiling and optimisation guidance.
|
| How do you sustain your research software project long-term? |
How do you sustain your research software project long-term?
|
| Publishing software |
How do you publish your software for reuse by others?
|
| Releasing software |
How to release your software for reuse?
|
| Reproducible software environments |
How to create a development environment for your software so others can run and contribute to your software?
|
| Improving research software security |
How to improve the security of research software by managing repository risks, secrets, dependencies, static analysis, CI/CD checks, and vulnerability reporting.
|
| Software documentation |
How do you document your software (code and project) for use by various different audiences?
|
| Software identifiers |
How to uniquely identify your software and its versions?
|
| Maintaining research software |
Guidance on keeping research software functioning, understandable, and usable over time — covering ongoing maintenance practices, dependency management, documentation, versioning, and the management of technical debt.
|
| Software Management Planning |
How to prepare a software management plan?
|
| Software metadata |
How to describe your software using metadata?
|
| Software project structure |
How to organise your code and software folders?
|
| Using static analysis |
How to use static analysis tools to detect bugs, enforce coding standards, check types, and improve the quality of research software before it runs.
|
| Task automation using GitHub Actions |
How to set up GitHub Actions on software repositories for task automation
|
| Task automation using GitLab CI/CD |
How to use and set up GitLab CI/CD for your GitLab repository
|
| Testing software |
How to test your software?
|
| Using containers |
Why and how to use containers for research software development?
|
| Using version control |
How do you choose and implement version control for your research software?
|
| Writing readable code |
How to write code readable and understandable by others?
|
| Writing a Research Software Story |
Capturing the context, community, and practices around a research software project.
|