diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 18d512d..6cc5509 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,5 +1,95 @@ -# Localization +# Contributing to Prašule +Hello! I'm glad you want to contribute to Prašule. It is currently a one-man project, so I alwaýs appreciate more help. + +Below you can see all the different ways you can help the project. Make sure to read the sections carefully, if there's something you don't understand or feel like is missing, don't be afraid to create an issue or send me an e-mail. :) + +## Before contributing +Prašule is an open-source project, all code and assets are licensed under the GNU AGPL version 3 (see [LICENSE.md](https://git.mnau.xyz/hernik/prasule/src/commit/cff9f6c8c72156d7c9ee761d2e6c15b37218c166/LICENSE.md) for more details), unless otherwise stated. Localizations are published under [CC0 1.0](https://creativecommons.org/publicdomain/zero/1.0/deed.en). + +By contributing to this project you agree that you are the author of your contributions (or have the rights to publish them to this project) and that they will be published under the license of the contribution, depending if it's localization or code. + +## Localization [![Translation status](https://hosted.weblate.org/widget/prasule/287x66-grey.png)](https://hosted.weblate.org/engage/prasule/) -You can help with localization through Weblate, join the translation project on https://hosted.weblate.org/engage/prasule/ \ No newline at end of file +You can help with localization through Weblate, join the translation project on https://hosted.weblate.org/engage/prasule/ + +## Filing bug reports +Probably one of the easiest ways to help the project is to use the app and find bugs and other problems. Before submitting a issue, check the list of [open and closed issues](https://git.mnau.xyz/hernik/prasule/issues) so we don't have to deal with duplicates. + +If you ever find something, +file a new issue using the relevant template [here](https://git.mnau.xyz/hernik/prasule/issues/new/choose), make sure to fill up as much information as you can. + +Template preview: +```md +### Operating System + Version + + +### App version + + +### What was expected to happen + + +### What actually happened + + +### Relevant logs +``` +Paste your logs here + +Make sure it is a codebloc +``` + +### Steps to reproduce + + +- [] I have checked the [list of issues](https://git.mnau.xyz/hernik/prasule/issues) and I'm sure this is not a duplicate + +``` + +## Suggesting features +Features can be suggested using the same issue tracker, make sure to choose the feature request template when creating a [new issue](https://git.mnau.xyz/hernik/prasule/issues/new/choose). + +Template preview: +```md +- [] I have checked the [list of issues](https://git.mnau.xyz/hernik/prasule/issues) and I'm sure this is not a duplicate + + +### Is your feature request related to a bug or an issue? If yes, describe it or link it + + +### Describe your request, how you'd like it to be implemented etc. + +``` + +## Code contributions +Code contributions can either be bug fixes related to open issues or new features. First let's get you ready with a dev environment. + +### Running the app locally +To have everyone use the same Flutter version, this project uses [Flutter Wrapper](https://github.com/passsy/flutter_wrapper) for version management. The version is kept using git submodules, so when you're cloning the repo, make sure to add a `--recurse-submodules` flag to your clone command. + +Because the wrapper operates using a shell script, you'll have to use WSL on Windows or download the specific Flutter version. We use the `beta` update channel. After the project has cloned with the submodules, use `flutterw` (not `flutter`) for every Flutter command. + +Make sure to set up your device (debug mode or VM for Android, simulator or physical device for iOS) and run the development build using `./flutterw run`. The app should now install and run on your device. + +### Code conventions +This project uses the [very_good_analysis](https://pub.dev/packages/very_good_analysis) lint package (with minor edits seen in `analysis_options.yaml`). If you don't have an IDE that shows lints, you can check for lint errors using the `./flutterw analyze` command. Certain issues have automated fixes, but don't rely on them, they can make mistakes sometimes. + +Certain lint issues, like `lines_longer_than_80_chars`, can be ignored in certain scenarios, but try to have the code issue-free. + +### Submitting new code to the repo +First of all, fork the repo to your own profile and clone it (if you've already cloned it, change the remote URL: `git remote set-url origin https://git.mnau.xyz/YOUR_USERNAME/prasule.git` and pull any changes). + +The `main` branch contains only stable code ready for shipping, all development occurs on the `dev` branch, so create a new branch **from the `dev` branch**. There are no branch naming conventions, but if it's a new feature, it could be `feat-featurename`, for bug fixes `fix-issuename`. + +Check out your branch in your workspace and start coding. When you're done and want to commit your changes, make sure the commit message adheres the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification. + +When all your changes are ready to be pushed to the main repo, submit a new [pull request](https://forgejo.org/docs/latest/user/pull-requests-and-git-flow/) **into the `dev` branch**. The PR will be reviewed by a maintainer, make sure to check back from time to time for any additional requests. +