Skip to content

Latest commit

 

History

History
61 lines (44 loc) · 2.98 KB

CONTRIBUTING.md

File metadata and controls

61 lines (44 loc) · 2.98 KB
Raw

Introduction

To begin with, we'd like to welcome you to contribute to this project. Thank you for your effort, it's what makes this project a viable alternative to commercial solutions.

Please read through these guidelines to get to know how to join the development, submit new issues, pull requests etc... This should increase the effectiveness of time spent by the maintainers.

You're more than welcome to join in any way you see fit, each contribution counts:

  • developing new features
  • improving the code quality by refactoring
  • reviewing pull requests
  • writing documentation
  • suggesting new features
  • reporting and/or fixing bugs
  • discussing potential solutions
  • ...

Having said that, please make sure you don't pull the project your way, against the trends of the community. Strive for open discussion and generic solutions that satisfy the needs of others.

Ground Rules - Definition of "Done"

Our Definition of "Done" (DoD) includes:

  • close to full unit test coverage
  • code style according to configured linter
  • meaningful commit messages and branch naming
  • ensuring that the CI build passes
  • updating the documentation
  • reviewing the code by at least one maintainer

For issues, code reviews etc. please be respectful and considerate, promote open discussion and provide feedback.

Getting started

A general guide on contributing code to open source projects can be seen at contribution-guide.org. Here's a brief instruction:

  1. Fork the master branch
  2. Hack away
  3. Make sure you've met the DoD
  4. Create a merge request to the master branch
  5. Wait for code review and apply suggestions

How to report a bug

First of all, any security vulnerabilities should be submitted directly to [email protected].

Other bugs should be reported as GitHub issues. Please include:

  • a short description explaining the bug and its impact,
  • version(s) of the project module(s),
  • issue severity,
  • reproduction steps,
  • the expected result,
  • the actual result,
  • information such as operating system, tools version etc. can also be useful in troubleshooting.

How to suggest a feature or enhancement

If you think the project is lacking a certain feature or enhancement that could be useful for a wider audience please report this fact as a GitHub issue. Describe the potential use case, what problem it solves and why you would like to see this change implemented. If you also have an idea of how it should be implemented please feel free to include such suggestions.

Code review process

Each pull request is reviewed by at least one of the maintainers and they need to merge it to the base repository (preferably via a squash commit). Expect comments discussing the way you've solved the problem, as well as code quality and standards (e.g. DoD). You’re also welcome to join in on the code review.

The maintainers shouldn't take longer than a week to complete the first review. How long the merge request lives on depends solely on the discussion in the comments.