Table of Contents

...

Here is a video on contributing to opensource.  Here is a course on how to contribute to open source : - https://egghead.io/courses/how-to-contribute-to-an-open-source-project-on-github

There is also a readme.md file at the top level that guides common activities.

The application components run in kubernetes.  As a result, they must be packaged as images that can be picked up by the deployment specs.

Local development works differently for this than for production uat and production releases.

The flow of activities is something like this:

Development Flow

• pull or clone the repo
• create a new branch
• make the necessary changes
• test locally
  • test out of that directory following directions in the local readme.md file
  • write and run tests using chai
  • build the docker image
  • update the helm chart to point to temporary image location
• test with local reference implementation
  • follow instructions for the reference impl in the root readme.md file
• deploy to cloud ?? how to do this?
• pull request for production ?? how to do this?
• distribute to distributed nodes ?? how to do this?

Getting Started

First pull or fork the latest from the develop branch.

Make a branch of for your changes

Development Flow

• Report the issue you are facing or the new feature you would like to introduce and get approval from the maintainers of the project. Alternatively, choose an already reported issue.
• Pull or clone the repository
• Create a new branch
• Make the necessary changes
• Test your changes
  • Write and run tests
  • Look for instructions in the README.MD file in the project where your changes are for additional instructions on testing the code
• Create a Pull Request and assign reviewers
• Once approved, merge the pull request

Pull Request Process

Every pull request must follow the guidelines set here to be approved and considered for merging. Every pull request should be linked to a reported GitHub Issue in the openIDL project. Pull requests have been set up with checks that all have to pass. At least two maintainers should approve the pull request.

Pull Request Requirements

Rule	Required	Comment
2 Approvals from maintainers from two different organizations
The pull request is linked to a GitHub Issue (new feature or a bug)
Developer Certificate of Origin (DCO)		Always commit your changes with git commit -s  (--signoff)
Automated builds pass
Automated tests pass

Active Maintainers

Developing

Each subdirectory has a readme.md file that helps with the details of local development.

...