Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Description of end of project support #225

Merged
merged 3 commits into from
Nov 6, 2020
Merged

Description of end of project support #225

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
568cb7f
Address #67
c-martinez Sep 9, 2020
ccccabc
Update text on building on existing packages
c-martinez Oct 5, 2020
6c4207f
Add stronger 'not-reinvent-the-wheel' statement
c-martinez Nov 6, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 6 additions & 3 deletions nlesc_specific/projects/end_of_a_project.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -32,11 +32,14 @@ As this kind of documentation is only valuable if engineers can freely share the

## Support

The Netherlands eScience Center provides very limited support for software. During a project we make every effort to create low-maintenance code by building on as many standard components as possible, using software from eStep, and putting a lot of effort into documenting and testing software. Also, by using standard file formats and API's we try to limit the effort required to maintain software, and make it easier to continue development.
The Netherlands eScience Center provides very limited support for software. During a project we make every effort to create low-maintenance code by building on as many standard components (such as software listed in the [RSD](https://research-software.nl/)) as possible, and putting a lot of effort into documenting and testing software. Also, by using standard file formats and API's we try to limit the effort required to maintain software, and make it easier to continue development.
bouweandela marked this conversation as resolved.
Show resolved Hide resolved

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:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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'.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


For in-house developed eStep software we _do_ provide some support, though even here only limited time is available for this. See the technology page on the website (https://www.esciencecenter.nl/technology) for the list of supported software.
```Markdown
> This repository is currently not maintained. We welcome people to fork this repository for further development and maintenance.
```

Additionally the repository should be marked as archived.