Contributing

Contributing Information:

Contributing Guidelines:

Note: this guide was made by Jim, author of OBS.
The author’s style is saved in this document.

  • 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 this doc about Coding Style for a general guideline (though not necessarily a rulebook, for example we allow the use of boolean return values instead of ints for failure). That particular coding style guideline is for more than just style, it actually helps produce a better overall code base.
  • 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 this doc 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).
  • 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.
  • 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.