From 17b9947d2c1bd328c3fbe414b4c1d8d4337660aa Mon Sep 17 00:00:00 2001 From: jp9000 Date: Mon, 1 Dec 2014 13:39:22 -0800 Subject: [PATCH] Include guide to good commits in CONTIRBUTING file --- CONTRIBUTING | 22 +++++++++++++++------- 1 file changed, 15 insertions(+), 7 deletions(-) diff --git a/CONTRIBUTING b/CONTRIBUTING index 5df5e44f7..be0324456 100644 --- a/CONTRIBUTING +++ b/CONTRIBUTING @@ -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.