Skip to content
This repository has been archived by the owner on Aug 24, 2021. It is now read-only.

Latest commit

 

History

History
70 lines (43 loc) · 3.18 KB

CONTRIBUTING.md

File metadata and controls

70 lines (43 loc) · 3.18 KB
Raw

Contribute to Kwik

Feedback and pull requests are very welcome.

Ask for help, request a feature or report a bug

Feel free to create an issue. Only make sure that your question/request/report is not the duplicate of an exiting issue.

The state of issues (backlog, todo, in progress, etc.) is tracked in a zenhub workspace.

Follow issues

For a detailed view of the issues you can look at the zenhub board.

Choose an issue to work on

Issues marked up-for-grabs should to be easy and isolated enough to be done by anyone having interest in contributing.

I assign myself to issues when I am working on them. So you can safely pick any unassigned issue.

You may (but don't have to) write a message in the issue to say you are working on it.

Build from source

Make sure that the environment variable JAVA_HOME points to a JDK installation (version 8, 11 or 15)

This project uses gradle. Here are the most important tasks you may want to run:

  • ./gradlew jvmTest Compile sources and run unit tests in the JVM (Best first task for a fresh clone)
  • ./gradlew check -PwarningAsError Build and test/check everything
  • ./gradlew sphinx Generate documentation (result will be in build/site/index.html)
  • ./gradlew detekt Run a static code analysis and report code smells (may fail if too many code smells are found)

Coding standard

Follow the Kotlin conventions

Favor immutable types and pure functions

Run the static code analysis (./gradlew detekt) to get a reports of the code smells.

Open a pull request

  • Make sure the change is wanted by discussing it first in the issues
  • Keep your pull request small, and split it in many smaller ones if necessary
    • a pull request that solves only part of an issue, is perfectly fine. It might still be merged and the issue split into many smaller ones.
  • Write automated tests covering the new feature or fix
    • if you are not sure how to test your changes, open the pull request as Draft. I'll gladly help you to write the tests.
  • Make sure the build passes (run ./gradlew check -PwarningAsError)
  • Write a description
    • explain what problem is solved (with a reference to an existing issue if applicable)
    • help to read and understand the code changes
    • point parts that requires special attention or consideration
  • Update documentation if necessary
    • documentation sources are in folder docs
    • you can generate it locally with ./gradlew sphinx
    • the locally generated documentation will be available in build/site/index.html

In case you are not sure about something, it is better to open a pull request early (as a draft) and discuss it ;-)