There is already a bunch of nice features from KMath contributors. But since the code is usually sophisticated, some community design process needs to be enforced in order to make them play together. So here are some rules.
- Any contribution with new classes/features must have test coverage of algorithmic part (not necessary 100% code coverage).
- Any feature contribution must include a set of examples (goes into
examples project), short feature description (goes into readme/feature section of appropriate module build file) and a design document (goes into docs directory). The design document is made to explain the design decisions made for the specific features (look at how KEEP works). Designing mathematics library is hard and we want all decisions to be consistent. The discussion in Kotlin Slack is welcome.
- Any changes made to
stable maturity modules must be ABI compatible between major versions and development maturity means ABI compatibility between minor versions. If your change is breaking it should be moved to a separate module or to the next release branch.
There is already a bunch of nice features from KMath contributors. But since the code is usually sophisticated, some community design process needs to be enforced in order to make them play together. So here are some rules.
examplesproject), short feature description (goes intoreadme/featuresection of appropriate module build file) and a design document (goes intodocsdirectory). The design document is made to explain the design decisions made for the specific features (look at how KEEP works). Designing mathematics library is hard and we want all decisions to be consistent. The discussion in Kotlin Slack is welcome.stablematurity modules must be ABI compatible between major versions anddevelopmentmaturity means ABI compatibility between minor versions. If your change is breaking it should be moved to a separate module or to the next release branch.