Skip to content

Latest commit

 

History

History
139 lines (107 loc) · 7.87 KB

CONTRIBUTING.md

File metadata and controls

139 lines (107 loc) · 7.87 KB

Contributing to Atrium

Thank you very much for taking your time to contribute to Atrium 😃

Following a few guidelines so that others can quickly benefit from your contribution.

Table of Content: Code of Conduct, How to Contribute, Your First Code Contribution, Coding Conventions, Pull Request Checklist.

Code of Conduct

This project and everyone participating in it is governed by Atrium's Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behaviour to info@tutteli.ch

How to Contribute

In any case, if you are uncertain how you can contribute, then write us via the Contributor Q&A discussion category. and we will figure it out together 😄

Your First Code Contribution

Fantastic, thanks for your effort!

The following are a few guidelines on how we suggest you start.

  1. Fork the repository to your repositories (see Fork a repo for help).
  2. Use an IDE which supports Kotlin and gradle projects. We suggest IntelliJ Community Edition. Because of IDEA-228368 you will need at least IntelliJ 2020.1, or the Gradle import will fail. Install the following plugins:
    • EditorConfig by JetBrains (might be already activated)
    • Spek Framework by Spek Team
  3. Import the project (import the build.gradle -> import as project, works more reliably)
  4. Open up a terminal (e.g. Intellij's built in -> usually ALT+F12) and run ./gradlew build This builds the project (compile, run tests etc.) via gradle
  5. Read up the Coding Conventions of Atrium (there are only 4 points).

Note: IntelliJ requires a few workarounds.

  • IntelliJ may warn you about duplicate content roots. Simply ignore it (IntelliJ doesn't support sharing of sources).
  • IntelliJ may warn you about a Symbol being declared in an unnamed module. This is an IntelliJ bug (feel free to upvote) which can be ignored as well.

Perfect, you are set up and ready to go. Have a look at help wanted issues where good first issues are easier to start with. Please write a comment such as I am working on this in the issue, this way we can assign the task to you (so that others know there is already someone working on the issue) and it gives us the chance to have a look at the description again and revise if necessary.

Git

Dealing with Git for the first time? Here are some recommendations for how to set up Git when working on an issue:

  • create a new branch for the issue using git checkout -b <branch-name> (preferably, the branch name should be descriptive of the issue or the change being made, e.g #108-path-exists.) Working on a new branch makes it easier to make more than one pull request.
  • add this repository as a remote repository using git remote add upstream https://github.com/robstoll/atrium.git. You will use this to fetch changes made in this repository.
  • to ensure your branch is up-to-date, rebase your work on upstream/main using git rebase upstream/main or git pull -r upstream main. This will add all new changes in this repository into your branch and place your local unpushed changes at the top of the branch.

You can read more on Git here.

Post a question in the Contributor Q&A discussion category whenever you need help to get up and running or have questions. It's also fine if you write down your question in the issue.

We recommend you create a pull request (see About pull requests for help) in case you are not sure how you should do something. This way we can give you fast feedback regarding multiple things (style, does it go in the right direction etc.) before you spend time for nothing. Prepend the title with [WIP] (work in progress) in this case and leave a comment with your questions.

Finally, when you think your PR (short for pull request) is ready, then please:

  1. read the Pull Request Checklist
  2. Create your first pull-request
  3. 👏👏👏 you have submitted your first code contribution to Atrium 😊

Coding Conventions

So far we do not try to enforce too much. We will review your patches and comment if necessary. However, here a few hints in order that your pull request is merged quickly.

  1. Try to write code in a similar style as the existing (We suggest you copy something existing and modify it).
  2. Write readable code and express comments with code rather than comments.
  3. Provide tests (see existing tests in src/...Test)
  4. Write your commit message in an imperative style.

Pull Request Checklist

Please make sure you can check every item on the following list before you create a pull request:

  • your pull request is rebased on the latest commit on main
  • Your pull request addresses only “one thing”. It cannot be meaningfully split up into multiple pull requests.

Once you have created and submitted your pull request, make sure:

  • your pull request passes Continuous Integration and all other checks