|
|
@@ -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.
|
jp9000