2016-02-23 23:16:51 +00:00
|
|
|
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
|
2016-10-10 19:01:40 +00:00
|
|
|
|
|
|
|
|
- To contribute translations, see:
|
|
|
|
|
https://obsproject.com/forum/threads/how-to-contribute-translations-for-obs.16327/
|
2016-02-23 23:16:51 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
