You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Idtentify who the research active team members are and what software development they are contributing plus what they need to get out of it in what time frame along with ideintifying who the research inactive team members and what they are contributing plus what they need to get out of it in what time frame.
1, Make it clear to research active members that you respect their research confidentiality and make an agreement about what is sensitive to their research and what is not. Make any agreements about when, if and how long data and software needs to be kept confidential.
2, Make agreements about when and how software changes will be integrated. You may want to fork off some researchers (particualrly inexperienced ones or ones who are making dramatic changes to the codes, perhaps parallelising it, so that they can learn on their fork) and integrate their work comes later.
3, Once you understand the context of those developing and using the code you can develop a plan.
The text was updated successfully, but these errors were encountered:
As per #3, this pushes the lesson toward "building digital scientific instruments" rather than exploratory coding - which is OK, we just need to make it explicit.
Idtentify who the research active team members are and what software development they are contributing plus what they need to get out of it in what time frame along with ideintifying who the research inactive team members and what they are contributing plus what they need to get out of it in what time frame.
1, Make it clear to research active members that you respect their research confidentiality and make an agreement about what is sensitive to their research and what is not. Make any agreements about when, if and how long data and software needs to be kept confidential.
2, Make agreements about when and how software changes will be integrated. You may want to fork off some researchers (particualrly inexperienced ones or ones who are making dramatic changes to the codes, perhaps parallelising it, so that they can learn on their fork) and integrate their work comes later.
3, Once you understand the context of those developing and using the code you can develop a plan.
The text was updated successfully, but these errors were encountered: