...

1. Integration tests between different components can be started early and in parallel.
2. Code reviews to be strict and strengthened
3. A code review checklist can be maintained (including checkstyles, coverage, tests done, functionality covered, pending work , definition of done etc), we pushed code that did not build and did not have tests.
4. Internal demos can be started and made more frequent, when there is a demoable component.
5. Dedicated page of instructions for new joiners for Checkstyle/SONAR etc. Also the repositories that we need to use Nordix/Onap etc
6. Good knowledge of Policy and the Policy Framework codebase and practices work.
7. Add good descriptions of the reason for a commit and an explanation of the commit in comments in the review
8. How does our architecture align with the existing CLAMP springboot approach?
9. Understand the architectural path into the future.
10. Meetings!

Overall:

1. Wiki page should be updated and kept aligned before design start, as component functionality can be agreed among all. +
2. Jira tickets can be updated with new subtasks, an acceptance criteria defined and agreed per sub-task
3. Jira Tickets can be updated with progress and gerrit links, if acceptable.
   

...

1. Stick with the Wiki for documentation and convert to RST later, keep the wiki page up to date. Wiki page should be updated and kept aligned before design start, as component functionality can be agreed among all.
2. Set up CSIT tests for the control loop work. Also get some help from experienced people in CSIT.
3. Explain the concepts of Control Loops/Participants/Control Loop Elements in a good way with good diagrams and better documentation, also the TOSCA service template and node templates.
4. Put up a howto on the Wiki on how to run the demo.
5. Training on the Policy Framework and its principles.
6. Informal Demos at the standups from everyone of commits coming in, maybe where there are issues!
7. Get the Jenkins verify jobs running in Nordix
8. Code Reviews
   1. Follow ONAP guidelines as a minimum Code Review
   2. Check and perform reviews
      1. First thing in the morning
      2. After Lunch
      3. Last thing in the evening
   3. Be gentle and kind
   4. Provide suggestions on changes rather than just saying something is incorrect: Do How as well as What and Why
   5. Checklist for Code Reviews (Sirisha Manchikanti to champion)
      
      1. Code must pass verify job, unverified jobs are not code reviewed
      2. Checkstyle: Covered by build (Verified commit proves checkstyle is OK)
      3. Coverage: 80%, Put figure from Eclipse/IntelliJ in the commit message: Investigate how to do in IntelliJ
      4. Integration Tests done statement
      5. What Functionality covered statement
      6. What Functionality is not covered (if needed)
      7. What the Definition of done for this feature is and how near we are to that
9. Wiki page for new joiners, already is a lot of info out there but it's scattered. We should have a landing page for ourselves. Park this and come back
10. Jira (Sirisha Manchikanti )
    1. Jira tickets can be updated with new subtasks, an acceptance criteria defined and agreed per sub-task
    2. Jira Tickets can be updated with progress and gerrit links, if acceptable.

Action Points

1. Follow up on contract testing, also with CPS project test approach

...