The best way to familiarise yourself with the internals of OpenCOR is by having a look at its source code.
All of the source code is and must be made available under the
OpenCOR namespace (e.g.
There are only two exceptions to this rule:
[OpenCOR]/src/windows/main.cpp (i.e. OpenCOR’s two main
Request a for or an to a future version of OpenCOR.
Report a or a issue with the current official version of OpenCOR.
Specify a that needs to be carried out for the next official version of OpenCOR.
Specify the binding () associated with a , or issue.
Specify the platform(s) (, and/or ) associated with a , or issue.
Although it can technically be done, no work should be carried out on the master branch.
Instead, anyone wanting to contribute to OpenCOR should first fork the Git repository.
Work for issue
#XXX should then be done in a branch called
The work done, a pull request should be created.
This will trigger OpenCOR to be built and tested on Jenkins.
Assuming everything goes well, the project manager will decide whether to merge the pull request.