Skip to content

Latest commit

 

History

History
59 lines (39 loc) · 3.16 KB

CONTRIBUTING.md

File metadata and controls

59 lines (39 loc) · 3.16 KB

Contributing to tgtg_client

Welcome to tgtg_client

If you intend to contribute to this project, please read following text carefully to avoid bad misunderstandings and wasted work.

Contributions are appreciated but just under correct terms.

Table of contents

  1. Introduction
  2. Expectations
  3. Style guideline
  4. What we're looking for
  5. How to contribute
  6. Community

Introduction

Please start by reading our license and code-of-conduct. If you don't agree with them, this isn't your project.

Expectations

  • We're mentoring but just to a certain degree. An initial effort should have been done, training in programming basics or computer science isn't part of the offer. We want to speed up development, not slowing it down.
  • Quality has priority, not getting quickly done. Faults by unnecessary hurry or sentences like "at least it works" are the opposite of "being welcome" here. Putting experiments on users is disrespectful for their time investment.
  • Don't get emotional, act logical. Personal taste has to back off if there's no explanation why xy makes more sense for others too. Let's combine the best of all!
  • Contributing should happen as teamwork, not as competition. Join discussions, look through PRs and issues, merge compatible forks. Ignoring the progress of others leads to lost time (and motivation).

Style guideline

  • Continue present conventions and follow best practices. Don't break our pattern, code needs no multi-culture.
  • Comment and document your changes. Keep in mind others may work on same project parts too and don't want to spend much time understanding what you've done. 10 seconds you saved costs another contributor 10 minutes.
  • Include unit tests when you contribute new features, as they help to:
    1. prove that your code works correctly
    2. guard against future breaking changes to lower the maintenance cost
  • Bug fixes also generally require unit tests, because the presence of bugs usually indicates insufficient test coverage.
  • Format your code using the standard provider linter.

What we're looking for

  • Bug fixes
  • Feature ideas
  • Examples or tutorials
  • Tests

How to contribute

Main contribution ways are to open issues and fork with later pull requests. Furthermore, you can discuss issues, review PRs or mention this project in public/chat with the community about your experience.

If you want to contribute with a pull request, please remember to:

  • Fork the repository.
  • Check if your changes are consistent with the style guideline.

Community

The community has a high value for this project!

As much as possible should be discussed in public, important decisions made by multiple individuals and people not getting excluded just because of a little dispute.