Skip to content

Latest commit

 

History

History
42 lines (29 loc) · 2.26 KB

CONTRIBUTING.md

File metadata and controls

42 lines (29 loc) · 2.26 KB

Contributing

When contributing to this repository, please first discuss the change you wish to make via issue, on our Discord, or any other method with the owners of this repository before making a change.

Please note we have a code of conduct, please follow it in all your interactions with the project.

🐛 Reporting Bugs

Before reporting a bug or issue, please make sure that the issue is actually being caused by or related to Icicle. Please also make sure, that you have the latest version of the library in

  • your development environment (aka. Gradle/Maven) - DEVS
  • the projects you're running - END USERS

If you're unsure about the above, feel free to ask our community at our Discord BEFORE making a report. If all of the above check out, then feel free to continue by creating an issue.

📝 Contributing code

When contributing code, make sure to do so in a style that fits our project. Our code style follows the official Kotlin style. Feel free to ask if you're unsure, whether your code fits our style. P.S: your IDE should format it properly.

If you're considering submitting a substantial pull request, please open an issue so we can discuss the change before starting work on the contribution. (for ex.: You don't have to do it for fixing typos, but you should absolutely do it when deprecating stuff)

Most pull requests are happily accepted, but larger changes may have an impact on the maintainability of the project, and require more consideration.

Our project uses the gitmoji standard for commit messages, please apply the respective emoji to your commit message as well!

Pull Request Process (checklist)

  1. Ensure that your code is clean of unused imports, dependencies and so on.
  2. Increase the version numbers in any changed files to the new version that this Pull Request would represent. The versioning scheme we use is SemVer.
  3. Please write proper KDoc for your additions. If your changes alter interactions with the library (ex.: deprecation, method refactoring, etc.)
  4. You may merge the Pull Request in once you have the sign-off of two other developers, or if you do not have permission to do that, you may request the second reviewer to merge it for you.