Skip to content

Latest commit

 

History

History
81 lines (66 loc) · 3.36 KB

CONTRIBUTING.md

File metadata and controls

81 lines (66 loc) · 3.36 KB
Raw

Contributing

First of all, we want to thank you for considering contributing to this project. You are already awesome!

Below are a few guidelines to help you get started. These are just guidelines, not rules. Use your best judgement, and when in doubt Discussions is the best place to ask questions.

This document is part of the project. If there is something wrong or you want to propose a change, please do so in a pull request.

We welcome contributors of any level. If it is your first time contributing to an Open Source project, you can learn how from this free series: How to Contribute to an Open Source Project on GitHub

This document is a work in progress. You may notice that some parts are empty or incomplete. Please, be patient! It is a very young project. Alternatively, you may consider contributing to this document. 😉

What can I contribute?

At this point, anything! Here are some contributions that we will gladly accept:

  • Ideas about how to do things better
  • Feature suggestions
  • Bug reports
  • Documentation improvements
  • Bug fixes
  • Feature implementation

Feature suggestions

Before suggesting a feature, please have a look at the roadmap to see if it's not something we are working on already or plan to work on in the future.

The best way to suggest a new feature is to start a new discussion. That way, we will collect more details and see the community sentiment before creating an actual issue.

Bug reports

Template TBD

How to set up the environment

TBD

Code contributions

Before you submit any code for review, please consider the following:

  • We want our code to run on any platform, make sure your change doesn't break cross-platform compatibility.
  • Write tests for the code you are submitting and make sure that your tests pass and that existing tests don't fail either.
  • Comment your code extensively!

Just a side note on licensing. If you bring an external dependency, consider the license. This project is MIT licensed. For example GPL licensed code cannot be included in this project without violating the GPL.

Commit messages

We highly value commit messages that follow established forms within the project. Generally speaking, we follow the practices outlined in the Pro Git Book. A good commit message will look like the following:

  • Line 1: A short summary written in the present imperative tense. For example:
    • ✔️ Good: "Fix post rendering bug"
    • ❌ No: "Fixes post rendering bug"
    • ❌ No: "Fixing post rendering bug"
    • ❌ No: "Fixed post rendering bug"
    • ❌ No: "Post rendering bug is fixed now"
  • Line 2: [left blank]
  • Line 3: An added description of what changed, any rationale, etc. -- optional
  • Last line: A mention of any applicable task or issue
    • For GitHub issues: Ref #000 or Fixes #000

Code review

Once you submit a pull request, someone will have a look at it as soon as possible. Generally within 48 hours. If the reviewer is happy, the pull request will be merged. We may ask you some questions or suggest changes. Any pull requests with pending questions will be closed after seven days of inactivity.