Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
69 lines (49 loc) · 3.74 KB

CONTRIBUTING.md

File metadata and controls

69 lines (49 loc) · 3.74 KB

How to contribute

I like to encourage you to contribute to the repository. This should be as easy as possible for you but there are a few things to consider when contributing. The following guidelines for contribution should be followed if you want to submit a pull request.

Contributions welcome!

Before spending lots of time on something, ask for feedback on your idea first!

Please search issues and pull requests before adding something new! This helps avoid duplicating efforts and conversations.

This project welcomes any kind of contribution! Here are a few suggestions:

  • Ideas: participate in an issue thread or start your own to have your voice heard.
  • Writing: contribute your expertise in an area by helping expand the included content.
  • Copy editing: fix typos, clarify language, and generally improve the quality of the content.
  • Formatting: help keep content easy to read with consistent formatting.
  • Code: help maintain and improve the project codebase.

How to prepare

  • You need a GitHub account
  • Submit an issue ticket for your issue if there is no one yet.
    • Describe the issue and include steps to reproduce if it's a bug.
    • Ensure to mention the earliest version that you know is affected.
  • If you are able and want to fix this, fork the repository on GitHub

Make Changes

  • In your forked repository, create a topic branch for your upcoming patch. (e.g. feature--autoplay or bugfix--ios-crash)

    • Usually this is based on the master branch.
    • Create a branch based on master; git branch fix/master/my_contribution master then checkout the new branch with git checkout fix/master/my_contribution. Please avoid working directly on the master branch.

  • Make sure you stick to the coding style that is used already.

  • Make use of the .editorconfig-file if provided with the repository.

  • Make commits of logical units and describe them properly.

  • Check for unnecessary whitespace with git diff --check before committing.

  • If possible, submit tests to your patch / new feature so it can be tested easily.

  • Assure nothing is broken by running all the tests.

Submit Changes

  • Push your changes to a topic branch in your fork of the repository.
  • Open a pull request to the original repository and choose the right original branch you want to patch.
  • If not done in commit messages (which you really should do) please reference and update your issue with the code changes. But please do not close the issue yourself.
  • Even if you have write access to the repository, do not directly push or merge pull-requests. Let another team member review your pull request and approve.

Rules

There are a few basic ground rules for collaborators:

  1. No --force pushes or modifying the Git history in any way.
  2. Non-master branches ought to be used for ongoing work.
  3. External API changes and significant modifications ought to be subject to an internal pull request to solicit feedback from other contributors.
  4. Internal pull requests to solicit feedback are encouraged for any other non-trivial contribution but left to the discretion of the contributor.
  5. Contributors should attempt to adhere to the prevailing code style.

Releases

Declaring formal releases remains the prerogative of the project maintainer.

Additional Resources