Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 38 Next »

This space is intended to capture the extensive documentation on all answer changing code features that you want to include in E3SM model code base. Before such a feature can be integrated into the code, it needs to go through the Code Review process that is defined in /wiki/spaces/CNCL/pages/25231511 page.

The procedures and pages described below in Instructions exactly follow the defined review process.

 Follow this steps to integrate your answer changing code into E3SM code base:

 Click here to expand...
  1. Give your feature a name that includes the component and short description:
    1. Use a format [ A, O, L, C, P,W, S ]number_Feature-xyz   that starts with a capital letter of your Group followed by a number (unique consecutive number for your group), followed by underscore then any short feature description, for example: O1_MPAS-Ocean-in-ACME ,  A1_CLUBB
  2. Create a main Confluence Page to contain all the documentation on your the new feature to be integrated into ACME code, use template 'ACME Code Review' (to create this page, make sure you are on the Code Review Process Implementation page, click on the three dots (...) icon next to Create icon at the top, blue navigation bar, choose appropriate template and click on 'Create'). Title it with the name of your feature. This page contains two tables, fill them in as described in the template
    1. A feature dependency table – info from this table will feed the New Features Dependencies Overview page, that will help display the dependencies between feature pull requests
    2. A table with the checklist of all stages of the review and to obtain approvals for each of the stage of the Code Review
      As you work on integrating your feature into ACME code, step along the Checklist table on your main page, obtain the approvals before going to the next step
  3. Click on your new feature main page (created in #2), and as you go through the checklist of the code review process (second table #2.b) create and fill the appropriate pages: 
    1. Design Document Confluence page for your new code feature  - using template 'ACME Design Document'
    2. Verification , Validation and Performance Phase 1 pages with appropriate templates: 'ACME Code Validation Phase 1', etc..
    3. Phase 2 Plan - use 'ACME Code Review Phase 2 Plan' (TBD)
    4. Coupled Performance and Coupled Validation pages use 'ACME Feature Coupled Performance ' or 'ACME Feature Coupled Validation' templates (TBD)
  4. When the Phase 1 documentation checklist (table #2.b) is satisfied and you have the approval from a Group Lead (the blue section of the table), you are ready to issue a PR and assign it to an integrator. At that point fill in the blue section in the dependencies table (table #2.a) with the name of the PR integrator's name, and after he integrates the code, provide the integration date.
  5. Phase 2 starts with the Plan document (#3.c). The coupled system integration and testing can and should be done with the aggregate of features, and the planned coupled simulations may validate a combination of feature aggregates if feasible.

(thumbs up)  See competed example documentation:  A1 Ozone Hole (Linoz-v2)

New Feature Dependencies, PR Dates, Git Branch Overview 

To check dependencies between new features, what blocks them and what do they affect, the dates they are ready for Pull Request (PR), their git branch, date PR was issued, who it was assigned to, when it was integrated into ACME and the associated ACME git hash/tag (remember the table is sortable):

Design Document Overview

For the quick overview of all design documents, which part is already done, if it is ready for GLs approval, please see:

Code Features

Generating page properties report...

Children Pages Listing

  • No labels