Browse files

Adopt CONTRIBUTING from rebar.

  • Loading branch information...
1 parent 716b489 commit d0e782fe3f7a86444f632af2d1d52dbf4121bb0f @kaos kaos committed Jan 16, 2014
Showing with 94 additions and 0 deletions.
  1. +94 −0 CONTRIBUTING.md
View
94 CONTRIBUTING.md
@@ -0,0 +1,94 @@
+Contributing to erlydtl
+-----------------------
+
+Before implementing a new feature, please submit a ticket to discuss
+your plans. The feature might have been rejected already, or the
+implementation might already be decided.
+
+
+Code style
+----------
+
+The following rules must be followed:
+ * Do not introduce trailing whitespace
+ * Do not mix spaces and tabs
+ * Do not introduce lines longer than 120 characters
+
+The following rules should be followed:
+ * Write small functions whenever possible
+ * Avoid having too many clauses containing clauses containing
+ clauses. Basically, avoid deeply nested functions.
+
+[erlang-mode (emacs)](http://www.erlang.org/doc/man/erlang.el.html)
+indentation is preferred. This will keep the code base consistent. vi
+users are encouraged to give
+[Vim emulation](http://emacswiki.org/emacs/Evil)
+([more info](https://gitorious.org/evil/pages/Home)) a try.
+
+
+Pull requests and branching
+---------------------------
+
+Issue pull requests for master. If it is a bug fix that also applies
+for the latest release, it can be back ported to the stable branch
+after merge.
+
+Use one topic branch per pull request. If you do that, you can add
+extra commits or fix up buggy commits via `git rebase -i`, and update
+the branch. The updated branch will be visible in the same pull
+request. Therefore, you should not open a new pull request when you
+have to fix your changes.
+
+Do not commit to master in your fork (for your own good).
+
+Provide a clean branch without merge commits.
+
+
+Committing your changes
+-----------------------
+
+Please ensure that all commits pass all tests, and do not have extra Dialyzer warnings.
+To do that run `make check`.
+
+#### Structuring your commits
+
+Fixing a bug is one commit.
+Adding a feature is one commit.
+Adding two features is two commits.
+Two unrelated changes is two commits.
+
+If you fix a (buggy) commit, squash (`git rebase -i`) the changes as a fixup commit into
+the original commit.
+
+#### Writing Commit Messages
+
+It's important to write a proper commit title and description. The commit title must be
+at most 50 characters; it is the first line of the commit text. The second line of the
+commit text must be left blank. The third line and beyond is the commit message. You
+should write a commit message. If you do, wrap all lines at 72 characters. You should
+explain what the commit does, what references you used, and any other information
+that helps understanding your changes.
+
+Basically, structure your commit message like this:
+
+<pre>
+One line summary (at most 50 characters)
+
+Longer description (wrap at 72 characters)
+</pre>
+
+##### Commit title/summary
+
+* At most 50 characters
+* What was changed
+* Imperative present tense (Fix, Add, Change)
+ * `Fix bug 123`
+ * `Add 'foobar' command`
+ * `Change default timeout to 123`
+* No period
+
+##### Commit description
+
+* Wrap at 72 characters
+* Why, explain intention and implementation approach
+* Present tense

0 comments on commit d0e782f

Please sign in to comment.