Coding rules

• Paperwork is made to be simple to use (think simple enough that your own grandmother could install and use it)
• Paperwork is open-source software (GPLv3+)
• Your changes must respect the PEP8 (you can use the command 'make check' to check your changes)
• You must not break existing features. You're strongly encouraged to discuss the changes you want to make beforehand (on the bug tracker, the mailing-list or IRC).
• Your contribution must be maintainable: It must be clear enough so that somebody else can maintain it. If it is a complicated piece of code, please comment it as clearly as possible.
• Your contribution must and will be reviewed (most likely by me, Jflesch)
• If you make an important contribution, please try to maintain it (fix bug reported by other users regarding features you added, etc).
• Please try to have one change per commit.
• If you see pieces of code that doesn't follow these rules, feel free to make a cleanup commit to fix it. Please do not mix cleanups with other changes.
• All commits go to the branch 'develop'. I (Jflesch) will cherry-pick them in master or release branches if required.
• If you add new dependencies, please update:
  • setup.py: for Python dependencies
  • src/paperwork/deps.py: frontend ; for non-Python dependencies
  • paperwork-backend/deps.py: backend ; for non-Python dependencies
  • flatpak/develop.json: Used to generate Flatpak packages (see flatpak-builder). To test your changes, you can generate standalone Paperwork Flatpak bundles with "cd flatpak ; make bundles" (it's quite long ; beware it will use your local develop.json but will package Paperwork from Github).

Same rules apply for all the libraries in Openpaperwork: PyOCR, Pyinsane, etc.

Regarding PEP-8, the following rules must be strictly followed:

1. Lines are at most 80 characters long
2. Indentation is done using 4 spaces

(again, please run "make check" before submitting a change)