# RSE Project Values and Default Practices We should where possible endeavor to make the software we create: - correct - accessible - maintainable - extensibile - (re)usable - performant ## Default practices Every project will vary slightly, depending on tech stack, domain and the research group we're working with, but here we propose a set of sensible default practices that should be applied in all projects unless there's a good reason to diverge. Where project teams are not already familiar with these practices, we will encourage them to see their value and to continue with these practices once we have moved on. ### Version control Projects should: - use git for version control - be hosted in a sensible location on one of: - https://github.com - https://github.kcl.ac.uk - https://gitlab.er.kcl.ac.uk - This will usually be within the e-Research group, or a group belonging to the project team - adopt a branching strategy appropriate to the scale and risk of the project - this will often include: - a stable main branch - a less stable development branch - short-lived feature branches - a workflow using pull-requests to merge branches when ready ### Documentation Projects should: - have basic documentation in the form of a structured readme - have a license - we encourage the use of Open Source licenses where appropriate Projects which provide a hosted service should: - be logged in an asset register - have a named contact for future queries Projects may, especially for larger projects: - have architecture documentation - have a documented handover process to support the transfer of ownership to new developers ### Code quality Projects should: - follow consistent code style guidelines - use automated formatting tools where possible - implement appropriate error handling - include meaningful comments and documentation strings - have regular code reviews as part of code quality assurance ### Testing Projects should: - adopt a testing strategy appropriate to the scale and risk of the project - this will usually include: - automated unit tests, using language/domain standard tooling - a basic continuous integration workflow - a basic linting setup ### Containerisation Projects should consider containerisation when they: - have complex dependencies or runtime requirements - need to ensure consistent behavior across different environments - are intended to be deployed as services - require reproducible research environments When containerising, projects should: - use Docker as the default containerisation tool - provide clear documentation on: - how to build & run the container - required environment variables - any volume mounts needed - provide a docker-compose.yml for multi-container applications ### Research output integration Projects should: - document how to cite the software - document publications that use this software