@@ -1,132 +0,0 @@
1−# Contributing Guidelines
2−
3−
4−The Idris Community welcomes pull requests, bug reporting, and bug squashing!
5−However, we cannot do it all ourself, and want to make it as easy as possible to contribute changes to get things working.
6−Here are a few guidelines that we would like contributors to follow so that we can have a chance of keeping on top of things.
7−
8−## Getting Started
9−
10−1. Make sure you are familiar with [Git](http://git-scm.com/book).
11−1. Make sure you have a [GitHub account](https://github.com/signup/free).
12−1. Make sure you are familiar with: [Sphinx](http://www.sphinx-doc.org).
13−
14−## Issue Reporting
15−
16−Before you report an issue, or wish to add more content please try and check to see if there are existing [issues](https://github.com/jfdm/idris-manual/issues) and [pull requests](https://github.com/jfdm/idris-manual/pulls).
17−We do not want you wasting your time, duplicating somebody's work!
18−
19−Of note: developers should be prepared to wait until their PR has been discussed and authorized prior to the PRs inclusion.
20−
21−## The Campsite Rule
22−
23−A basic rule when contributing to this project is the **campsite rule**: leave the project in better condition than you found it.
24−Please clean up any messes that you find, and don't leave behind new messes for the next contributor.
25−
26−## Making Changes
27−
28−Idris developers and hackers try to adhere to something similar to the [successful git branching model](http://nvie.com/posts/a-successful-git-branching-model/).
29−The steps are straightforward.
30−
31−Please consult STYLE-GUIDE.md for information on writing styles.
32−
33−### New contributors
34−
35−For those new to the project:
36−
37−1. Fork our [main development repository](https://github.com/jfdm/idris-manual) `idris-manual` on github e.g.
38−2. Clone your fork to your local machine:
39−
40−```
41−$ git clone git@github.com/<your github user name>/idris-manual.git
42−```
43−
44−3. Add `jfdm/idris-manual` as a remote upstream
45−
46−```
47−$ git remote add upstream git@github.com:jfdm/idris-manual.git
48−```
49−
50−### Existing Contributors
51−
52−For those already contributing to the project:
53−
54−1. Ensure your existing clone is up-to-date with current `HEAD` e.g.
55−
56−```
57−$ git fetch upstream
58−$ git merge upstream/master
59−```
60−
61−### Remaining Steps
62−
63−The remaining steps are the same for both new and existing contributors:
64−
65−1. Create, and checkout onto, a topic branch on which to base you work.
66−* This is typically the master branch.
67−* For your own sanity, please avoid working on the `master` branch.
68−
69−```
70−$ git branch fix/master/my_contrib master
71−$ git checkout fix/master/my_contrib
72−```
73−
74−1. Make commits of logical units.
75−1. Check for unnecessary whitespace with
76−
77−```
78−$ git diff --check
79−```
80−
81−1. Make sure your commit messages are along the lines of:
82−
83−Short (50 chars or less) summary of changes
84−
85−More detailed explanatory text, if necessary. Wrap it to about 72
86−characters or so. In some contexts, the first line is treated as the
87−subject of an email and the rest of the text as the body. The blank
88−line separating the summary from the body is critical (unless you omit
89−the body entirely); tools like rebase can get confused if you run the
90−two together.
91−
92−Further paragraphs come after blank lines.
93−
94−- Bullet points are okay, too
95−
96−- Typically a hyphen or asterisk is used for the bullet, preceded by a
97−single space, with blank lines in between, but conventions vary here
98−
99−1. Make sure you have added any necessary tests for your changes.
100−1. Run all the tests to assure nothing else was accidentally broken.
101−
102−```
103−$ make test
104−```
105−
106−1. Push your changes to a topic branch in your fork of the repository.
107−
108−```
109−$ git push origin fix/master/my_contrib
110−```
111−
112−1. Go to GitHub and submit a pull request to `idris-manual`
113−
114−From there you will have to wait on one of the `idris-manual` committers to respond to the request.
115−This response might be an accept or some changes/improvements/alternatives will be suggest.
116−We do not guarantee that all requests will be accepted.
117−
118−## Increases chances of acceptance.
119−
120−To help increase the chance of your pull request being accepted:
121−
122−1. Spell and Grammar check your work.
123−1. Ensure that the documentation will compile for all outputs used.
124−1. Use appropriate formatting for reST.
125−
126−## Additional Resources
127−
128−* [Using Pull Requests](https://help.github.com/articles/using-pull-requests)
129−* [General GitHub Documentation](https://help.github.com/).
130−
131−
132−Adapted from the most excellent contributing files from the [Puppet project](https://github.com/puppetlabs/puppet) and [Factroy Girl Rails](https://github.com/thoughtbot/factory_girl_rails/blob/master/CONTRIBUTING.md)