prasule/CONTRIBUTING.md
Matyáš Caras 3e0e2409a2 chore: publish version 1.1.1 (#43)
Co-authored-by: Renovator <kontakt+renovator@caras.cafe>
Reviewed-on: #43
2024-04-22 17:05:22 +02:00

5.8 KiB

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 for more details), unless otherwise stated. Localizations are published under CC0 1.0.

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

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 so we don't have to deal with duplicates.

If you ever find something, file a new issue using the relevant template here, make sure to fill up as much information as you can.

Template preview:

### Operating System + Version
<!-- for example "Android 13" -->

### App version
<!-- 
Can be found in the app by clicking 
the three dots > 'About' or in app info in your device's setting
-->

### What was expected to happen
<!-- Enter what you thought SHOULD happen when the bug occured -->

### What actually happened
<!-- Here describe what ACTUALLY happened -->

### Relevant logs

Paste your logs here

Make sure it is a codebloc


### Steps to reproduce
<!-- 
Enter the exact steps that you made when you encountered the bug,
so we can reproduce it
-->

- [] I have checked the [list of issues](https://git.mnau.xyz/hernik/prasule/issues) and I'm sure this is not a duplicate
<!-- This is a checkbox, either check it after creating the issue or change [] to [X] -->

Suggesting features

Features can be suggested using the same issue tracker, make sure to choose the feature request template when creating a new issue.

Template preview:

- [] I have checked the [list of issues](https://git.mnau.xyz/hernik/prasule/issues) and I'm sure this is not a duplicate
<!-- This is a checkbox, either check it after creating the issue or change [] to [X] -->

### Is your feature request related to a bug or an issue? If yes, describe it or link it
<!-- You can link issues by simply writing # followed by the ID of the issue or PR, for example #12 -->

### Describe your request, how you'd like it to be implemented etc.
<!-- This is the space for your requests to be made -->

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 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 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 specification.

When all your changes are ready to be pushed to the main repo, submit a new pull request 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.