...

1. 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.
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

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. Get the unit tests done
2. Probably introduce some unit ''integration tests'' with instantiation, CSITs
3. Redefine the API's needed. Exact GET's needed + checks to introduce, What do we actually need?
4. Pushing of control loop component definitions to participants? Flow of how you get from a commissioned control loop definition to an instantiated control loop.

1. Monitoring:

   ...

   1. 1. Monitoring and supervision functionality interchanged. Needs to be updated in the wiki.

   ...

   1. 1. Need to finalize the statistics data for participants and Control loop elements. Also need to decide, if we require to implement association between statistics classes and parent.

   ...

   1. GUI for monitoring?

   Considerations

   PMSH implementation

   ...