aboutsummaryrefslogtreecommitdiffstats
path: root/CONTRIBUTING.md
diff options
context:
space:
mode:
authorTristan Sloughter <[email protected]>2013-03-24 15:17:57 -0500
committerTristan Sloughter <[email protected]>2013-03-24 15:21:21 -0500
commit2ddcf7879ccb9d84f863b39e3f6d8b57eb409811 (patch)
treed141c14b99b240c23bce5801f54ff1958854baba /CONTRIBUTING.md
parent2b5b2f40f2c80e65e4e3585d477c75a357813a69 (diff)
downloadrelx-2ddcf7879ccb9d84f863b39e3f6d8b57eb409811.tar.gz
relx-2ddcf7879ccb9d84f863b39e3f6d8b57eb409811.tar.bz2
relx-2ddcf7879ccb9d84f863b39e3f6d8b57eb409811.zip
add contributing document
Diffstat (limited to 'CONTRIBUTING.md')
-rw-r--r--CONTRIBUTING.md141
1 files changed, 141 insertions, 0 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000..3689b7a
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,141 @@
+Contributing
+============
+
+Introduction
+------------
+
+This document describes the usages and rules to follow when contributing
+to this project.
+
+It uses the uppercase keywords SHOULD for optional but highly recommended
+conditions and MUST for required conditions.
+
+`git` is a distributed source code versioning system. This document refers
+to three different repositories hosting the source code of the project.
+`Your local copy` refers to the copy of the repository that you have on
+your computer. The remote repository `origin` refers to your fork of the
+project's repository that you can find in your GitHub account. The remote
+repository `upstream` refers to the official repository for this project.
+
+Following this document will ensure prompt merging of your work in the
+`next` branch of the project. The `master` branch has `next` merged to
+it when we are satisfied with stability of the branch and any new
+features. Please submit all pull requests to the `next` branch and
+base your work off the `upstream` `next` branch.
+
+Reporting bugs
+--------------
+
+Upon identifying a bug you SHOULD submit a ticket, regardless of your
+plan for fixing it. If you plan to fix the bug, you SHOULD discuss your
+plans to avoid having your work rejected.
+
+Before implementing a new feature, you SHOULD submit a ticket for discussion
+on your plans. The feature might have been rejected already, or the
+implementation might already be decided.
+
+Cloning
+-------
+
+You MUST fork the project's repository to your GitHub account by clicking
+on the `Fork` button.
+
+Then, from your fork's page, copy the `Git Read-Only` URL to your clipboard.
+You MUST perform the following commands in the folder you choose, replacing
+`$URL` by the URL you just copied, `$UPSTREAM_URL` by the `Git Read-Only`
+project of the official repository, and `$PROJECT` by the name of this project.
+
+``` bash
+$ git clone "$URL"
+$ cd $PROJECT
+$ git remote add upstream $UPSTREAM_URL
+```
+
+Branching
+---------
+
+Before starting working on the code, you MUST update to `upstream`. The
+project is always evolving, and as such you SHOULD always strive to keep
+up to date when submitting patches to make sure they can be merged without
+conflicts.
+
+To update the current branch to `upstream`, you can use the following commands.
+
+``` bash
+$ git fetch upstream
+$ git rebase upstream/next
+```
+
+It may ask you to stash your changes, in which case you stash with:
+
+``` bash
+$ git stash
+```
+
+And put your changes back in with:
+
+``` bash
+$ git stash pop
+```
+
+You SHOULD use these commands both before working on your patch and before
+submitting the pull request. If conflicts arise it is your responsability
+to deal with them.
+
+You MUST create a new branch for your work. First, ensure you are on `next`.
+You MUST update `next` to `upstream` before doing anything. Then create a
+new branch `$BRANCH` and switch to it.
+
+``` bash
+$ git checkout -b $BRANCH
+```
+
+You MUST use a an insightful branch name.
+
+If you later need to switch back to an existing branch `$BRANCH`, you can use:
+
+``` bash
+$ git checkout $BRANCH
+```
+
+Source editing
+--------------
+
+The following rules MUST be followed:
+ * Indentation uses horizontal tabs (1 tab = 4 columns)
+ * Do NOT align code; only indentation is allowed
+ * Lines MUST NOT span more than 80 columns
+
+The following rules SHOULD be followed:
+ * Write small functions whenever possible
+ * Avoid having too many clauses containing clauses containing clauses
+
+Committing
+----------
+
+You MUST ensure that all commits pass all tests and do not have extra
+Dialyzer warnings.
+
+You MUST put all the related work in a single commit. Fixing a bug is one
+commit, adding a feature is one commit, adding two features is two commits.
+
+You MUST write a proper commit title and message. The commit title MUST be
+at most 72 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, you MUST make
+all lines smaller than 80 characters. You SHOULD explain what the commit
+does, what references you used and any other information that helps
+understanding your work.
+
+Submitting the pull request
+---------------------------
+
+You MUST push your branch `$BRANCH` to GitHub, using the following command:
+
+``` bash
+$ git push origin $BRANCH
+```
+
+You MUST then submit the pull request by using the GitHub interface to
+the `next` branch. You SHOULD provide an explanatory message and refer
+to any previous ticket related to this patch.