|
| 1 | +# Contributing Guidelines |
| 2 | + |
| 3 | +There are two main ways to contribute to the project — submitting issues and submitting |
| 4 | +fixes/changes/improvements via pull requests. |
| 5 | + |
| 6 | +## Submitting issues |
| 7 | + |
| 8 | +Both bug reports and feature requests are welcome. |
| 9 | +Submit issues [here](https://github.com/Kotlin/kotlinx-benchmark/issues). |
| 10 | + |
| 11 | +- Search for existing issues to avoid reporting duplicates. |
| 12 | +- When submitting a bug report: |
| 13 | + - Use a 'bug report' template when creating a new issue. |
| 14 | + - Test it against the most recently released version. It might have been already fixed. |
| 15 | + - By default, we assume that your problem reproduces in Kotlin/JVM. Please, mention if the problem is |
| 16 | + specific to a platform. |
| 17 | + - Include the code that reproduces the problem. Provide the complete reproducer code, yet minimize it as much as possible. |
| 18 | + - However, don't put off reporting any unusual or rarely appearing issues just because you cannot consistently |
| 19 | + reproduce them. |
| 20 | + - If the bug is in behavior, then explain what behavior you've expected and what you've got. |
| 21 | +- When submitting a feature request: |
| 22 | + - Use a 'feature request' template when creating a new issue. |
| 23 | + - Explain why you need the feature — what's your use-case, what's your domain. |
| 24 | + - Explaining the problem you're facing is more important than suggesting a solution. |
| 25 | + Report your problem even if you don't have any proposed solution. |
| 26 | + - If there is an alternative way to do what you need, then show the code of the alternative. |
| 27 | + |
| 28 | +## Submitting PRs |
| 29 | + |
| 30 | +We love PRs. Submit PRs [here](https://github.com/Kotlin/kotlinx-benchmark/pulls). |
| 31 | +However, please keep in mind that maintainers will have to support the resulting code of the project, |
| 32 | +so do familiarize yourself with the following guidelines. |
| 33 | + |
| 34 | +- If you fix documentation: |
| 35 | + - If you plan extensive rewrites/additions to the docs, then please [contact the maintainers](#contacting-maintainers) |
| 36 | + to coordinate the work in advance. |
| 37 | +- If you make any code changes: |
| 38 | + - Follow the [Kotlin Coding Conventions](https://kotlinlang.org/docs/reference/coding-conventions.html). |
| 39 | + - Use 4 spaces for indentation. |
| 40 | + - Use imports with '\*'. |
| 41 | + - Build the project to make sure it all works and passes the tests. |
| 42 | +- If you fix a bug: |
| 43 | + - Write the test that reproduces the bug. |
| 44 | + - Fixes without tests are accepted only in exceptional circumstances if it can be shown that writing the |
| 45 | + corresponding test is too hard or otherwise impractical. |
| 46 | + - Follow the style of writing tests that is used in this project: |
| 47 | + name test functions as `testXxx`. Don't use backticks in test names. |
| 48 | +- Comment on the existing issue if you want to work on it. Ensure that the issue not only describes a problem, |
| 49 | + but also describes a solution that has received positive feedback. Propose a solution if there isn't any. |
| 50 | + |
| 51 | +## Building |
| 52 | + |
| 53 | +This library is built with Gradle. |
| 54 | + |
| 55 | +- Run `./gradlew build` to build. It also runs all the tests. |
| 56 | +- Run `./gradlew <module>:check` to test the the module you're currently working on to speed things up during development. |
| 57 | + |
| 58 | +## Contacting maintainers |
| 59 | + |
| 60 | +- If something cannot be done, is not convenient, or does not work, — submit an [issue](https://github.com/Kotlin/kotlinx-benchmark/issues). |
| 61 | +- "How to do something" questions — [StackOverflow](https://stackoverflow.com). |
| 62 | +- Discussions and general inquiries — use `#benchmarks` channel in [KotlinLang Slack](https://kotl.in/slack). |
0 commit comments