Client research groups need to understand and agree our ways of working as set out below.
Personnel and communication
The developers working on the project will be chosen by the RSDG, based on skillset and time availability. Our preference is for two engineers per project, for the benefit of robustness in the event of changes in the group, and sharing of knowledge. We also reserve the right to change engineers throughout the project. The research group has the option to have the RSE(s) located at their premises half time.
There will be fortnightly meetings organised for status updates, at times convenient for the researchers and the RSE(s), but more meetings and other means of communication (eg. project Slack channel, GitHub issues, etc) are encouraged for efficient exchange of information.
Refactoring is important to RSDG.
Researchers will be asked to understand that developing code which is sustainable is one of the main purposes of RSDG. They might see several development cycles go by with no apparent feature work while we work on the software structure.
We will always work to a software quality assurance standard based on test-driven development and continuous automated testing. Therefore, researchers may see time pass while we are working on establishing the test scaffold and framework for the code, again without apparent feature work. We also expect to be given realistic test data, in order to design meaningful tests.
Researchers will agree to try to continue to keep up a testing approach following work ending, committing to fix broken tests in a reasonable time.
RSDG will always endeavour to understand the codes with which we work; we do not believe effective research software can be constructed without an understanding of the code's purpose. Again, researchers will commit to giving the team time to read in to the field, and will supply appropriate literature to the team, when necessary.
RSDG costs for work on either a pay-scale or day-rate basis. These costs assume 100% FTE includes appropriate allowances for meetings, holidays, training, and sick leave.
We use tools for tracking the time spent in projects and are willing to give updates on this at catch-up meetings and when requested.
Estimating the duration of tasks accurately on research projects is by nature difficult. Where tasks take longer than anticipated, we will notify researchers as early as possible and discuss how to prioritise the remaining work. If, on the other hand, work progresses unexpectedly quickly, we can work on additional tasks up to the time agreed.
All projects must use version control and an issue tracker. Researchers agree to learn and understand GitHub where they're not using something else already. Researchers agree to review issues on the issue tracker, and review code on pull requests (where desired), in a timely fashion.
After the end of the project, small support requests will be taken care of by the RSE(s) for a finite time (twice the project duration) on a best effort basis.