Skip to content

Latest commit

 

History

History
36 lines (28 loc) · 2.77 KB

CONTRIBUTING.md

File metadata and controls

36 lines (28 loc) · 2.77 KB
Raw

Splitfit contribution guidelines

Thanks for contributing!

Issue reporting/feature requests

  • Already reported? Browse the existing issues to make sure your issue/feature hasn't been reported/requested.
  • Already fixed? Check whether your issue/feature is already fixed/implemented.
  • Still relevant? Check if the issue still exists in the latest release/beta version.
  • Can you fix it? If you are an Android/Kotlin developer, you are always welcome to fix an issue or implement a feature yourself. PRs welcome! See Code contribution for more info.
  • Is it in English? Issues in other languages will be ignored unless someone translates them.
  • Is it one issue? Multiple issues require multiple reports, that can be linked to track their statuses.
  • The template: Fill it out, everyone wins. Your issue has a chance of getting fixed.

Code contribution

  • If you want to help out with an existing bug report or feature request, leave a comment on that issue saying you want to try your hand at it.
  • If there is no existing issue for what you want to work on, open a new one describing your changes. This gives the team and the community a chance to give feedback before you spend time on something that is already in development, should be done differently, or should be avoided completely.
  • Do not bring non-free software (e.g. binary blobs) into the project. Make sure you do not introduce Google libraries.
  • Stick to the F-Droid contribution guidelines.
  • Stick to the Google Play Policies.
  • Make changes on a separate branch with a meaningful name, not on the master branch branch. This is commonly known as feature branch workflow. You may then send your changes as a pull request (PR) on Codeberg.
  • Please test (compile and run) your code before submitting changes!
  • Make sure your PR is up-to-date with the rest of the code.
  • Please show intention to maintain your features and code after you contribute a PR. Unmaintained code is a hassle for core developers. If you do not intend to maintain features you plan to contribute, please rethink your submission, or clearly state that in the PR description.
  • Respond if someone requests changes or otherwise raises issues about your PRs.
  • Send PRs that only cover one specific issue/solution/bug. Do not send PRs that are huge and consist of multiple independent solutions.

Communication

This is a modified version of NewPipe's CONTRIBUTING.md