CONTRIBUTING

## 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
(https://github.com/fluxer/katie/tree/master/scripts) 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 and usually noted
at the main wiki page (https://github.com/fluxer/katie/wiki). Note your changes
there if necessary once they are accepted, ask for write access if you cannot
edit pages on the wiki.

## 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
(https://github.com/fluxer/qt) 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.