Description of end of project support #225
Conversation
|
|
||
| After a project has finished the eScience Center will in principle not further support the software. Reported bugs in our own software will of course have a high chance of being looked at, but this also has its limits. We cannot in any way contribute to the administration of infrastructure needed after a project has ended. | ||
|
|
||
| Because of the lack of support after projects is is a good idea to start to think about and make agreements on where software will land and who will maintain infrastructure at the very beginning of a project. The project proposal should already contain a plan. | ||
| Because of the lack of support after projects it is a good idea to start to think about and make agreements on where software will land and who will maintain infrastructure at the very beginning of a project. The project proposal should already contain a [plan](https://doi.org/10.5281/zenodo.1451750). When the software will no longer be maintained, this should be clearly indicated in the repository. For example, a warning should be added in the `README`, of the repository, such as: |
There was a problem hiding this comment.
This is not a very viable approach, contributing to existing software with an existing community has a much higher chance of survival after the project ends than 'thinking about where new software will land'.
There was a problem hiding this comment.
Yes. But contributing to existing software does not work when we build something new -- there it would be good to know that the project partner will continue to maintain it on their next project (or will have someone from his institution maintaining it, etc).
How about:
When new software is developed, it is a good idea to plan from the start of the project who will maintain the software after the project is finished. The project proposal should already contain a plan.
There was a problem hiding this comment.
It might be good to add that these after project people should be already involved and funded during the project, because if you only add them afterwards it seems unlikely to happen?
There was a problem hiding this comment.
Anyway, I think there should be a stronger focus on contributing to existing packages, even if they currently have a small community and low code quality, in favour of starting from scratch without a community.
There was a problem hiding this comment.
Anyway, I think there should be a stronger focus on contributing to existing packages, even if they currently have a small community and low code quality, in favour of starting from scratch without a community.
+100
Below, describe what this Pull Request adds:
This PR updates
end_of_project.mdto describe the level of support (or not) which software gets once a project is completed. We also removed mentions to eStep and replaced it with links to the RSD and software sustainability protocol.