55 lines
2.7 KiB
Markdown
55 lines
2.7 KiB
Markdown
|
# Contributing to JELOS
|
||
|
|
We want to make contributing to this project as easy and transparent as possible. Contributors are able to
|
||
|
|
|
||
|
|
- Report a bug
|
||
|
|
- Discuss the current state of the code
|
||
|
|
- Submit a fix
|
||
|
|
- Propose new features
|
||
|
|
- Become a maintainer
|
||
|
|
|
||
|
|
## Becoming a maintainer
|
||
|
|
When contributing to JELOS you are expected to become the maintainer of your contribution. Please keep this in mind when submitting pull requests.
|
||
|
|
* Keep track of your contributions upstreams and keep your components up-to-date.
|
||
|
|
* Watch the issue tracker and resolve issues related to your contribution.
|
||
|
|
|
||
|
|
## We Develop with Github
|
||
|
|
We use Gith to host code, to track issues and feature requests, as well as accept pull requests.
|
||
|
|
|
||
|
|
## We Use [Github Flow](https://guides.github.com/introduction/flow/index.html), So All Code Changes Happen Through Pull Requests
|
||
|
|
Pull requests are the best way to propose changes to the codebase (we use [Github Flow](https://guides.github.com/introduction/flow/index.html)). We actively welcome your pull requests:
|
||
|
|
|
||
|
|
1. Fork the repo and create your branch from `main`.
|
||
|
|
2. Ensure your code is built locally and tested.
|
||
|
|
3. Any changes should be reflected in the documentation.
|
||
|
|
6. Issue a pull request.
|
||
|
|
|
||
|
|
## Any contributions you make will be under the Apache 2 Software License
|
||
|
|
In short, when you submit code changes, your submissions are understood to be contributed under the same license as the original project code or under [Apache 2](https://choosealicense.com/licenses/apache-2.0/) license when no other license applies.
|
||
|
|
|
||
|
|
## Report bugs using Github's [issues](https://github.com/jelos/distribution/issues)
|
||
|
|
We use GitHub issues to track public bugs. Report a bug by [opening a new issue](); it's that easy!
|
||
|
|
|
||
|
|
## Write bug reports with detail, background, and sample code
|
||
|
|
|
||
|
|
**Great Bug Reports** tend to have:
|
||
|
|
|
||
|
|
- A quick summary and/or background
|
||
|
|
- Steps to reproduce
|
||
|
|
- Be specific!
|
||
|
|
- Give sample code if you can.
|
||
|
|
- What you expected would happen
|
||
|
|
- What actually happens
|
||
|
|
- Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
|
||
|
|
|
||
|
|
## Use a Consistent Coding Style
|
||
|
|
* Follow the same style as the source you are editing.
|
||
|
|
* If you are contributing new code, keep the style consistent with other similar works.
|
||
|
|
* Parameterize as much as possible, try to avoid hard coded values whenever you can.
|
||
|
|
* Use 2 spaces for indentation rather than tabs when possible.
|
||
|
|
|
||
|
|
## License
|
||
|
|
By contributing, you agree that your contributions will be licensed under the license of the existing project code being modified or Apache 2.
|
||
|
|
|
||
|
|
## References
|
||
|
|
This document was adapted from the open-source contribution guidelines for [Facebook's Draft](https://github.com/facebook/draft-js/blob/a9316a723f9e918afde44dea68b5f9f39b7d9b00/CONTRIBUTING.md)
|