Close
Collaborating research groups need to understand and agree our ways of working as set out below. These supplement UCL’s general commitments on staff interactions for maintaining a healthy working environment, as set out in the Dignity at Work Statement.
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 at least two research software engineers (RSEs) 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 (although will endeavour to do so in a way which is mutually beneficial). The research group has the option to have the RSEs working at their premises for a portion of the allocated time.
There will be regular (e.g. fortnightly) meetings organised for status updates, at times convenient for the researchers and the RSEs, but more meetings and other means of communication (e.g. project Slack channel, GitHub issues) are encouraged for efficient exchange of information.
Scheduling work
RSDG supports many research projects across UCL simultaneously, and needs to manage the time commitments individual developers give to each project in order to ensure each one is successful, as far as it is within our power to do so. We are often under very high demand and hence need to schedule work several months in advance. While we strive to adapt to changes in research priorities and unexpected deadlines, we cannot guarantee being able to do so. In particular, if there is a lack of responsiveness from research groups during the scheduled work period, the project may need to be rescheduled resulting in significant delays. The collaboration will be most effective if we are informed of known deadlines well in advance, and schedule tasks together with you in order to meet these. We will update you on the forecast schedule at the regular meetings as desired and will let you know of any material changes on our side as early as we can.
Time tracking
RSDG costs for work on either a pay-scale or day-rate basis. Note in particular that we do not commit to produce specific deliverables for a given price, in the way that industrial IT contractors typically work. Instead we commit to a number of hours worked on the project. 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.
Research
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. Researchers will commit to giving the team time to read in to the field, and will supply appropriate literature to the team, when necessary.
GitHub
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, which is where development tasks will be recorded and prioritised, and review code on pull requests (where desired), in a timely fashion.
Refactoring
Refactoring is important to RSDG.
Researchers are asked to understand that developing code which is sustainable is one of the main purposes of RSDG. You might see several development cycles go by with no apparent feature work while we work on the software structure.
Testing
We will always work to a software quality assurance standard based on test-driven development (where relevant) 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.
After-project support
After the end of the project, small support requests will be taken care of by the RSEs for a finite time (twice the project duration) on a best effort basis.
Recognition for research software
One of the aims of RSDG is to raise the profile of research software within the wider research community. We do not require that we are named as authors on research papers, but we would be keen to co-author software papers with you, publish releases of software which can be given a DOI and cited, promote the software at relevant conferences, and generally disseminate the work we do as widely as possible. Such activities also help to enhance the group’s track record for subsequent grant proposals in which we collaborate.