👍🎉 First off, thanks for taking the time to contribute! 🎉👍
We want to make contributing to this project as easy and transparent as possible, whether it's:
- Reporting a bug
- Discussing the current state of the code
- Submitting a fix
- Proposing new features
- Becoming a maintainer
- How to Contribute to the codebase
- How to localize SoruSora into a different language
- Report bugs using Github's issues
- Write bug reports with detail, background, and sample code
- Use a Consistent Coding Style
- License
- Code of Conduct
Pull requests are the best way to propose changes to the codebase (we use Github Flow). We actively welcome your pull requests:
- Fork the repo and create your branch from
main. - If you've added code that should be tested, add tests.
- If you've changed APIs, update the documentation.
- Ensure the test suite passes.
- Make sure your code lints.
- Issue that pull request!
We use GitHub issues to track public bugs. Report a bug by opening a new issue; it's that easy!
This is an example of a bug report that I think is not a bad model.
Great Bug Reports tend to have:
- A quick summary and/or background
- Steps to reproduce
- Be specific!
- Give a sample code if you can. This stackoverflow question includes sample code that anyone with a base R setup can run to reproduce.
- 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)
People love thorough bug reports. I'm not even kidding.
Follow PEP 8 Guidelines, which are standard coding style guidelines for Python
- You can try running
pylintfor style unification
If you have any questions, please don't hesitate to ask. You can contact me via Discord or email: [email protected].
By contributing, you agree that your contributions will be licensed under its MIT License.
Consider reading Code of Conduct.