obs-studio/CONTRIBUTING

Contributing Information:

 - Our bug tracker is located at (currently linked to forum accounts):
       https://obsproject.com/mantis/

 - Development forums are currently located at:
       https://obsproject.com/forum/list/general-development.21/

 - Development IRC channel is primarily #obs-dev on QuakeNet
 
 - To contribute translations, see:
       https://obsproject.com/forum/threads/how-to-contribute-translations-for-obs.16327/


Contributing Guidelines:

 - Code and commits will be reviewed.  Reviews will be blunt and honest, and
   your change probably won't go through the first time, or may be outright
   rejected.  It may require many revisions before changes are finally
   accepted.

 - If you want to avoid doing a lot of work only to have it rejected, discuss
   what you want to change it in the main channels/forums/mailing lists before
   actually working on it.  Open source requires thick skin.  Please don't be
   discouraged if your changes don't go through, learn from it and get better.

 - Coding style is Linux-style KNF (kernel normal form).  This means K&R, 80
   columns max, preferable maximum function length of approximately 42 lines, 8
   character width tabs, lower_case_names, etc.  I chose this for the sake of
   the project.  Don't argue about it, just do it.  It takes no time to do.

   See https://www.kernel.org/doc/Documentation/CodingStyle for a general
   guideline (though not necessarily a rulebook, for example we allow the use
   of boolean return values instead of ints for failure).

   NOTE: C++ is an exception to the lower_case_only rule, CamelCase is
   encouraged (though not required) to distinguish it from C code.  Just a
   personal and subjective stylistic thing on my part.

 - Commits are not just changes to code; they should also be treated as
   annotation to code.  For that reason, do not put unrelated changes in a
   single commit.  Separate out different changes in to different commits, and
   make separate pull requests for unrelated changes.  Commits should be
   formatted with the 50/72 standard, and should be descriptive and concise.
   See http://chris.beams.io/posts/git-commit/ for a summary of how to make
   good commit messages.

 - Core code is C only (unless there's an operating system specific thing that
   absolutely requires another language).

 - Modules and UI may use C, C++, or Objective-C (for apple), though please try
   to use C unless an API you're using requires C++ or Objective-C (such as
   windows COM classes, or apple Objective-C APIs).

 - If you don't quite know what to work on and just want to help, the bug
   tracker has a list of things that need to be worked on.

 - Try to respect the wishes of the author(s)/maintainer(s).  A good maintainer
   will always listen, and will often ask others on the project for their
   opinions, but don't expect things to be completely democratic.

 - Do not use dependencies for the sake of convenience.  There's enough
   dependencies as it is.  Use them only if you absolutely have to depend on
   them.