From 14cdf6f3e8c5de0a1d794ad415be9789b496e532 Mon Sep 17 00:00:00 2001 From: Sergey Mashkov Date: Fri, 5 Jul 2019 16:31:20 +0300 Subject: [PATCH] Create CONTRIBUTING.md --- CONTRIBUTING.md | 41 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 00000000000..8bf8bf4b568 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,41 @@ +# How to contribute + +Before contributing to ktor, it could be advisable +to check [Slack](https://surveys.jetbrains.com/s3/kotlin-slack-sign-up) **#ktor** channel first +and discuss the problem with the communitity. + +If your contribution is a bugfix, try to [search](https://github.com/ktorio/ktor/issues), +if there is already an open ticket and open a new one if not yet opened. + +Contributions are made using github [pull requests](https://help.github.com/en/articles/about-pull-requests). + +1. [Create](https://github.com/ktorio/ktor/compare) a new PR, your PR should request to merge to the **master** branch. +2. Ensure that the description is clear, refer to an existing ticket/bug if applicable. +3. When contributing a new feature, provide motivation and use-cases describing why +the feature is important enough to be delivered with ktor to everyone. +4. Adding and updating features may require to update the [documentation](https://github.com/ktorio/ktorio.github.io). +Create a documentation PR and link both pull requests. +5. Make sure you have adequate tests added and no existing tests were broken. + +# Styleguides + +Your code should conform to +the official [Kotlin code style guide](https://kotlinlang.org/docs/reference/coding-conventions.html) +except that start imports should be always enabled +(ensure Preferences | Editor | Code Style | Kotlin, tab **Imports**, both `Use import with '*'` should be checked). + +Every new source file should have a copyright header. + +Every public API (including functions, classes, objects and so on) should be documented, +every parameter, property, return types and exceptions should be described properly. + +Commit messages should be written in English only, should be clear and descriptive, +written in Present Tense and using Imperative Mood ("Fix" instead of "Fixes", "Improve" instead of "Improved"). +Add the related bug reference to a commit message (bug number after a hash character between round braces). +See [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/) + +A questionable and new API should be marked with `@KtorExperimentalAPI` annotation. +Public API that is not intended to be used by end-users that couldn't be made private/internal due to technical reasons, +should be marked with `@InternalAPI` annotation. + +