Changes between Version 21 and Version 22 of Developers/DevelopingCodeChanges

Timestamp:

2016-02-09T05:42:28+01:00 (8 years ago)

Author:

clevy

Comment:

--

Developers/DevelopingCodeChanges

@@ -8 +8 @@
 Until end of 2015,  the PI if a given development action was expected to develop the code and its documentation in a development branch, to go through the different validation steps, and to submit it at the end to a reviewer, the positive answer of the review being a prerequisite for a merge into the NEMO reference. [[BR]]Since Merge Party meeting end of 2015, the process has been changed to a more efficent and reliable process, in order to avoid disagreement and a lock at the review step. The sequence described below is presently to be followed for each development of the NEMO System Team's workplan.
 
-'''A brief overview of the process is given below:'''
+A brief overview of the process is given below:
 
- 1. Workplan content: Each development action is expected to be described in the yearly workplan
- 1. Detailed description of tasks and Preview step
- 1. Start the coding. The branch is a copy of the up to date reference that will be used to develop the changes.
- 1. '''Develop your Change!'''. Checkout your branch base code, develop and commit changes to your branch.
- 1. '''Test your Change!'''. Make sure you test your changes adequately.
- 1. '''Document your Change!'''. Update your !ticket with all the information that another user/developer might need.
- 1. '''!Science/Tech/Code Review!'''. Review of the change by an expert on the scientific or technical area you are changing and for adherence to coding standards.
+'''Phase 1: Description in the yearly workplan:'''
+
+Each development action is expected to be described in the yearly workplan including name of PI, and name(s) of pre- andre-viewer(s)
+
+'''Phase 2: Implementation plan and preview'''
+
+'''Phase 3: Coding and validation'''
+
+'''Phase 4: review'''
+
+'''Phase 5: Merge into NEMO reference'''
 
 Merging back with the trunk is not described here.
@@ -23 +27 @@
 The yearly workplan is discussed within System Team, submitted to Developer's Committee, and approved by Steering Committee. It must include, for each development action, its motivation, status, main tasks so as a PI name, and a previewer (which will also be the reviewer) name. If needed, previewer can be divided into a "Science Previewer" and a "System Previewer". The name of Previewer should be added only once he did accept the task, and before submission of workplan to Developer's Committee.[[BR]]
 
-== Detailed description of tasks and Preview step ==
+== Detailed description of implementation plan and Preview step ==
 Once the workplan has been approved, the code development is planned. The PI should