diff --git a/_sidebar.md b/_sidebar.md index b3e11f5e..5b848534 100644 --- a/_sidebar.md +++ b/_sidebar.md @@ -35,13 +35,6 @@ * [Chapter Owners](/chapter_owners.md) * [Access to (Dutch) e-Infrastructure](/nlesc_specific/e-infrastructure/e-infrastructure.md) * [DAS-5](/nlesc_specific/e-infrastructure/das5.md) - * [Projects](/nlesc_specific/projects/project_overview.md) - * [new Project()](/nlesc_specific/projects/new_project.md) - * [Kickoff Meeting](/nlesc_specific/projects/kickoff_meeting.md) - * [Project Planning](/nlesc_specific/projects/project_planning.md) - * [Project Reviews](/nlesc_specific/projects/project_reviews.md) - * [Communication](/nlesc_specific/projects/communication.md) - * [End of a Project](/nlesc_specific/projects/end_of_a_project.md) * [Checklist](/nlesc_specific/checklist.md) * [Development stages matrix](/nlesc_specific/checklist_matrix.md) * [Prototype phase](/nlesc_specific/checklist/checklist_prototype.md) diff --git a/nlesc_specific/projects/communication.md b/nlesc_specific/projects/communication.md deleted file mode 100644 index 00232948..00000000 --- a/nlesc_specific/projects/communication.md +++ /dev/null @@ -1,5 +0,0 @@ -# Communication - -## Pitch presentation (1 to 3 slides) - -Pitch presentation should be prepared, and updated on a regular basis. diff --git a/nlesc_specific/projects/end_of_a_project.md b/nlesc_specific/projects/end_of_a_project.md deleted file mode 100644 index 677e6601..00000000 --- a/nlesc_specific/projects/end_of_a_project.md +++ /dev/null @@ -1,47 +0,0 @@ -# End of a Project - -## 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. - -In principle the escience is shared with the engineer and coordinator, and is discussed during the project reviews. Any reusable software is added to the [Research Software Directory](https://www.research-software.nl/). 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. - -### Contents - -* high-level description of actual escience requirements in the project -* what went great, what could have gone better -* pointers (URL) to project documentation -* motivation for chosen approach, -* high-level description of used or developed tools and references to them (github, website, ) -* eScience presentation for (re-)use in the form of a powerpoint document (so the images, text, and or slides can be extracted). Check the pitch and project presentations to see if they are sufficient, ask coordinator. - -### written by - -* escience engineer(s) working on the project - -### target audience - -* escience engineers -* escience coordinators - -### schedule - -* should be written during the last weeks of the project -* Stored on the internal sharepoint site - -## Support - -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 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: - -``` -> 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. diff --git a/nlesc_specific/projects/kickoff_meeting.md b/nlesc_specific/projects/kickoff_meeting.md deleted file mode 100644 index e7a5f7d1..00000000 --- a/nlesc_specific/projects/kickoff_meeting.md +++ /dev/null @@ -1,23 +0,0 @@ -# Kickoff Meeting - -Each project starts with a kickoff meeting at the Netherlands eScience Center. At this meeting the PI, eScience engineer, Coordinator, and an MT-member are present. Other project partners are welcome. - -For this meeting the standard agenda is: - -* Round of introductions. -* Assignment of the eScience engineer(s) and coordinator. -* Netherlands eScience Center introduction presentation (by coordinator). -* Project introduction (by PI). -* Discussion on initial project planning and deliverables. -* Any other business. - -In the Netherlands eScience Center introduction presentation several important topics are explained: - -* How do we work. -* What is the role of the eScience engineer and coordinator. -* Project life cycle (annual reviews and rapports, payment, project end, etc.). -* How to communicate with the Netherlands eScience Center. -* Publications. -* Intellectual property (IP). -* Communication by the Netherlands eScience Center (project page at eScience Center website, pitches, etc.). -* Software and software quality. diff --git a/nlesc_specific/projects/new_project.md b/nlesc_specific/projects/new_project.md deleted file mode 100644 index 1e200b30..00000000 --- a/nlesc_specific/projects/new_project.md +++ /dev/null @@ -1,3 +0,0 @@ -# new Project() - -There are several ways a new project gets initiated at the Netherlands eScience Center. In general, projects are started via one of our project calls. See https://www.esciencecenter.nl/collaborate/ for more information. diff --git a/nlesc_specific/projects/project_overview.md b/nlesc_specific/projects/project_overview.md deleted file mode 100644 index d31a5e08..00000000 --- a/nlesc_specific/projects/project_overview.md +++ /dev/null @@ -1,3 +0,0 @@ -# Projects - -The Netherlands eScience Center is a projects based organization. Projects are done in partnership with scientists, usually from a Dutch University. diff --git a/nlesc_specific/projects/project_planning.md b/nlesc_specific/projects/project_planning.md deleted file mode 100644 index 49139d2f..00000000 --- a/nlesc_specific/projects/project_planning.md +++ /dev/null @@ -1,2 +0,0 @@ -# Project Planning - diff --git a/nlesc_specific/projects/project_reviews.md b/nlesc_specific/projects/project_reviews.md deleted file mode 100644 index 6975f966..00000000 --- a/nlesc_specific/projects/project_reviews.md +++ /dev/null @@ -1,21 +0,0 @@ -# Project Reviews - -For all project longer than a year (typically full projects and alliances), the MT organizes annual reviews. The details are described in Section 9.4.2 of the protocol document. The annual reviews are organized and chaired by an MT member, and the PI, eScience engineer(s), eScience coordinator, and other partners (posdocs, co-PIs, etc) are present. - -The goals are as follows: - -* Progress of project relative to planning. -* Innovation, research, deliverables. -* Identify key success stories/messages to share with key opinion formers. -* Ensure efficient use of engineer resources, identify bottlenecks and areas to improve. -* Financial status. -* Look for ways to extend collaborations. -* Consider project legacy and post-funding support. -* Potential interaction with other eScience Center projects. - -The standard agenda for this 1.5 hour meeting is: - -* Presentation by the PI (20 minutes) -* Presentation eScience Engineer (20 minutes) including description of role and deliverables. -* Discussion (40 minutes) -* Summary, action points and conclusions.