CONTRIBUTING

   1 ## Code style
   2 The best thing you can do is follow the code style used in the files you are
   3 changing or look for files in format same as those you are adding and use that
   4 code style.
   5
   6 ## Static data
   7 In many cases using immutable static data rather than generating at runtime and
   8 caching it is more optimal. If you want to add code that uses data tables use
   9 naming such as `MIBTbl` which makes it easy to look for and Python script for
  10 generating the data tables if possible. Check out the existing scripts
  11 (https://github.com/fluxer/katie/tree/master/scripts) for examples.
  12
  13 ## Compatibility
  14 Neither source nor binary compatibility is guaranteed between releases which
  15 means hacks for binary compatibility and such are not required. If there is
  16 breaking change, the changes that need to be applied to other projects should
  17 be kept to minimum with backwards compatibility where possible and usually noted
  18 at the main wiki page (https://github.com/fluxer/katie/wiki). Note your changes
  19 there if necessary once they are accepted, ask for write access if you cannot
  20 edit pages on the wiki.
  21
  22 ## Standards
  23 All standard and extension requirements for optional feature should be checked
  24 for during build if they are newer than POSIX.1-2001
  25 (https://en.wikipedia.org/wiki/POSIX). Read any documentation that may be
  26 relevant to the changes you make such as manual pages for Linux
  27 (https://linux.die.net/man/), FreeBSD (https://www.freebsd.org/cgi/man.cgi),
  28 NetBSD (https://man.netbsd.org/), OpenBSD (https://man.openbsd.org/) and
  29 Solaris (https://docs.oracle.com/en/). Open Group documentation is also a good
  30 source of information
  31 (https://pubs.opengroup.org/onlinepubs/9699919799/idx/head.html).
  32
  33 ## Tests
  34 You can import tests and adjust them as needed from stock Qt4 copy
  35 (https://github.com/fluxer/qt) if there are no tests in place relevant to the
  36 changes you do. Adding regression tests is optional.
  37
  38 ## Translations
  39 To contribute translations either use the web interface at
  40 https://www.transifex.com/smil3y/katie or the .pot files provided as base and
  41 submit them as pull request.
  42
  43 ## Licensing
  44 Unless you add new files you do not have to worry about that. Otherwise use
  45 as liberal as possible, preferably public domain (no license) or 3-clause BSD.
  46 The reason for that is simple - many vendors (distributions) and consumers will
  47 have strict requirements what they distribute and/or use. Debian for an example
  48 does not enable by default non-free software repository thus user interaction
  49 is required before non-free software can be installed.
  50
  51 If you cannot contribute your changes with license that is more or equally
  52 permissive than those already in use (3-clause BSD, FDL v1.3 and LGPL v2.1+)
  53 than your contribution may not be acceptable.