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 |
---|---|---|
At least 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 | ||
Security scans pass (Snyk) |
Definition of Done
TBD
Active Maintainers
Name | Organization | GitHub ID |
---|---|---|
Jeff Braswell | openIDL | tahoeblue |
Sean Bohan | openIDL | SeanBohan |
Ken Sayers | AAIS | kens-aais |
Peter Antley | AAIS | antleypk2 |
Aashish | Chainyard | aashishchainyard |
Surya Lanka | Chainyard | suryalanka-cy |
Tsvetan Georgiev | Senofi | TsvetanG |
Yanko Zhelyazkov | Senofi | yzhivkov |
Note |
---|
New maintainers are welcome. |
Developing
Each subdirectory has a readme.md file that helps with the details of local development.
...
Standard object notation is JSON. Keys/Attributes will be named using PascalCase example:
Wiki Markup |
---|
{"Foo": "value"} |
...
{'Foo': 'val'},{'FooBar': 'val2'}
Objects will have singular names
...
. Lists of objects will be names as plural form of singular object.
...
ex: {"Foos" : [{"Foo":"val3"},{"Foo":"val4"}]
Developing Utility Code
Testing
...