Safe Notes contribution guidelines

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/Java/Flutter 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.

Stick to Safe Notes's minimalist style.
Stick to Google developer guidelines.
In particular do not bring non-free software (e.g. binary blobs) into the project.

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 the changes you are planning to introduce. 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.
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.
Create PRs that cover only one specific issue/solution/bug. Do not create PRs that are huge monoliths and could have been split into multiple independent contributions.

Make changes on a separate branch with a meaningful name, not on the master branch or the dev branch. This is commonly known as feature branch workflow. You may then send your changes as a pull request (PR) on GitHub.
Please test (compile and run) your code before submitting changes! Ideally, provide test feedback in the PR description. Untested code will not be merged!
Respond if someone requests changes or otherwise raises issues about your PRs.
Try to figure out yourself why builds on our CI fail.
Make sure your PR is up-to-date with the rest of the code. Often, a simple click on "Update branch" will do the job, but if not, you must resolve the conflicts on your own. Doing this makes the maintainers' job way easier.

The #safenotes channel on Matrix Chat has the core team and other developers in it.
Some convenient Matrix clients, available both for phone and desktop, are listed at that link.
You can post your suggestions, changes, ideas etc. on either GitHub or Matrix.