## Code style
The best thing you can do is follow the code style used in the files you are
changing or look for files in format same as those you are adding and use that
code style.

## Static data
In many cases using immutable static data rather than generating at runtime and
caching it is more optimal. If you want to add code that uses data tables use
naming such as `MIBTbl` which makes it easy to look for and Python script for
generating the data tables if possible. Check out the existing scripts in the
scripts directory of Katie source code for examples.

## Compatibility
Neither source nor binary compatibility is guaranteed between releases which
means hacks for binary compatibility and such are not required. If there is
breaking change, the changes that need to be applied to other projects should
be kept to minimum with backwards compatibility where possible.

## Standards
All standard and extension requirements for optional feature should be checked
for during build if they are newer than POSIX.1-2001
(https://en.wikipedia.org/wiki/POSIX). Read any documentation that may be
relevant to the changes you make such as manual pages for Linux
(https://linux.die.net/man/), FreeBSD (https://www.freebsd.org/cgi/man.cgi),
NetBSD (https://man.netbsd.org/), OpenBSD (https://man.openbsd.org/) and
Solaris (https://docs.oracle.com/en/). Open Group documentation is also a good
source of information
(https://pubs.opengroup.org/onlinepubs/9699919799/idx/head.html).

## Tests
You can import tests and adjust them as needed from stock Qt4 copy if there are
no tests in place relevant to the changes you do. Adding regression tests is
optional.

## Translations
To contribute translations either use the web interface at
https://www.transifex.com/smil3y/katie or the .pot files provided as base and
submit them as pull request.

## Licensing
Unless you add new files you do not have to worry about that. Otherwise use
as liberal as possible, preferably public domain (no license) or 3-clause BSD.
The reason for that is simple - many vendors (distributions) and consumers will
have strict requirements what they distribute and/or use. Debian for an example
does not enable by default non-free software repository thus user interaction
is required before non-free software can be installed.

If you cannot contribute your changes with license that is more or equally
permissive than those already in use (3-clause BSD, FDL v1.3 and LGPL v2.1+)
than your contribution may not be acceptable.