Merge pull request #225 from NLeSC/end-of-life

Improve Description of end of project support

nlesc_specific/projects/end_of_a_project.md

@@ -2,7 +2,7 @@
 
 ## End-of-project document
 
-Project proposals are focused on their scientific domain, and are not always clear on the necessary escience. Also, during a project the escience requirements can change, and its actual escience component can be different from the originally proposed methods and tools. A final project report will focus on the scientific domain (published papers) and financial accounting. All in all, this leaves the escience part of projects a bit undocumented. Therefore, we could use a small informal document, for internal use, describing the project from the perspective of an escience engineer. 
+Project proposals are focused on their scientific domain, and are not always clear on the necessary escience. Also, during a project the escience requirements can change, and its actual escience component can be different from the originally proposed methods and tools. A final project report will focus on the scientific domain (published papers) and financial accounting. All in all, this leaves the escience part of projects a bit undocumented. Therefore, we could use a small informal document, for internal use, describing the project from the perspective of an escience engineer.
 In principle the escience is shared with the engineer and coordinator, and is discussed during the project reviews. Any reusable software is added to eStep, or to the knowledgebase. This document can therefore be high-level and short. It is meant to facilitate re-using tools and techniques for other escience projects, provide (links to) information and background material for escience presentations / PR, and provide a possible starting point for continuation of the project.
 
 As this kind of documentation is only valuable if engineers can freely share their opinions and experiences (also negative ones!), this document itself is not meant for external distribution.
@@ -32,11 +32,15 @@ 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 outside of projects. We have a strong preference for building top of and contributing to existing packages supported by a community -- do not reinvent the wheel!
+During a project we make every effort to create low-maintenance code and put 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.
 
 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:
 
-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.
+```
+> 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.