forked from obsproject/obs-studio
-
Notifications
You must be signed in to change notification settings - Fork 0
/
CONTRIBUTING
64 lines (47 loc) · 3 KB
/
CONTRIBUTING
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
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.