Imported Upstream version 0.13.2+dsfg1

CONTRIBUTING

@@ -0,0 +1,61 @@
+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
+
+
+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.