mirror/obs-studio
0
0
Fork 0
mirror of https://github.com/obsproject/obs-studio.git synced 2024-09-20 13:08:50 +02:00
Code

Include guide to good commits in CONTIRBUTING file

Browse Source
This commit is contained in:
jp9000 2014-12-01 13:39:22 -08:00
parent 15fb91ed63
commit 17b9947d2c
1 changed files with 15 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
CONTRIBUTING
View File

@ -14,13 +14,6 @@ Contributing:
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.
- 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.
- 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
@ -34,6 +27,14 @@ Contributing:
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).
@ -41,6 +42,13 @@ Contributing:
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.