Due to the fact that I'm using gitflow as code versioning methodology, you as developer should always start working on develop branch that contains the most recent changes.
There are many features/improvements that are not on my roadmap but someone else could decide to work on them anyway: hunt for issues tagged as Help Wanted to find them!
Feel free to add yourself to contributors.md file.
This kind of contributions must have screenshots or screencast as demonstration of the new additions.
If you plan to manipulate the code then you'll have to do it by following a specific code style. Also pay attention if you're using any plugin that automatically formats/cleans/rearrange your code and set it to only change that code that you touched and not the whole files.
All code changes and additions must be tested. See the related section for more informations or this two pull requests comments: one and two
When forking the project you'll have to modify some files that are strictly dependent from my own development / build / third-party-services environment. Files that need some attention are the following:
- gradle.properties: this is overridden by another file with the same name inside the omniNotes module. You can do the same or leave as it is, any missing property will let the app gracefully fallback on a default behavior.
A public instance of SonarQube is available both to encourage other developers to improve their code contributions (and existing code obviously) and to move the project even further into transparency and openness.
Checkout for it here
Pull requests will be automatically analyzed and rejected if they'll rise the code technical debt.