Thanks for taking the time to contribute to SystemDS!
The following are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.
Before contributing a pull request for review, let's make sure the changes are consistent with the guidelines and coding style.
- Inclusion of unit tests when contributing new features, will help
- prove that the code works correctly, and
- guard against future breaking changes.
- Formatting changes can be handled in a separate PR.
Example
bf4ba16b - New features (e.g., a new cutting edge machine learning algorithm) typically will live in scripts/staging or its equivalent folder for specific feature to get some airtime and sufficient testing before a decision is made regarding whether they are to migrated to the top-level.
- When a new contribution is made to SystemDS, the maintenance burden is (by default) transferred to the SystemDS team. The benefit of the contribution is to be compared against the cost of maintaining the feature.
Before contributing a pull request, we highly suggest applying a code formatter to the written code.
We have provided at profile for java located in Codestyle File ./docs/CodeStyle.eclipse.xml. This can be loaded in most editors e.g.:
Including a license at the top of new files helps validate the consistency of license.
Examples:
- C/C++/cmake/cuda
- Python
- Java
- Bash
- XML/HTML
- dml/R
- Makefile/.proto
- Markdown - refer to the top of this file!
Thanks again for taking your time to help improve SystemDS! 👍