|
| 1 | +Drush is built by people like you! Please [join us](https://github.com/drush-ops/drush). |
| 2 | + |
| 3 | +## Git and Pull requests |
| 4 | +* Contributions are submitted, reviewed, and accepted using Github pull requests. [Read this article](https://help.github.com/articles/using-pull-requests) for some details. We use the _Fork and Pull_ model, as described there. |
| 5 | +* Optionally, to help keep track of [your assigned issues](https://github.com/dashboard/issues/assigned), simply ask to be added to the contributor team. A maintainer can now assign any issue to you at your request. |
| 6 | +* The latest changes are in the `master` branch. |
| 7 | +* Make a new branch for every feature you're working on. |
| 8 | +* Try to make clean commits that are easy readable (including descriptive commit messages!) |
| 9 | +* Test before you push. Get familiar with Unish, our test suite. See the test-specific [README.md](tests/README.md) |
| 10 | +* Make small pull requests that are easy to review but make sure they do add value by themselves. |
| 11 | +* We maintain branches named 6.x, 5.x, etc. These are release branches. From these branches, we make new tags for patch and minor versions. |
| 12 | + |
| 13 | +## Coding style |
| 14 | +* Do write comments. You don't have to comment every line, but if you come up with something thats a bit complex/weird, just leave a comment. Bear in mind that you will probably leave the project at some point and that other people will read your code. Undocumented huge amounts of code are nearly worthless! |
| 15 | +* We use [Drupal's coding standards](https://drupal.org/coding-standards). |
| 16 | +* Don't overengineer. Don't try to solve any possible problem in one step, but try to solve problems as easy as possible and improve the solution over time! |
| 17 | +* Do generalize sooner or later! (if an old solution, quickly hacked together, poses more problems than it solves today, refactor it!) |
| 18 | +* Keep it compatible. Do not introduce changes to the public API, or configurations too lightly. Don't make incompatible changes without good reasons! |
| 19 | + |
| 20 | +## Documentation |
| 21 | +* The docs are in the [docs](docs) and [examples](examples) folders in the git repository, so people can easily find the suitable docs for the current git revision. You can read these from within Drush, with the `drush topic` command. |
| 22 | +* Documentation should be kept up-to-date. This means, whenever you add a new API method, add a new hook or change the database model, pack the relevant changes to the docs in the same pull request. |
| 23 | +* You can build the docs e.g. produce html, using `drush help --html`. This page also resides at http://www.drush.org. You might enjoy prettier and more comprehensive version at [Drush Commands](http://www.drushcommands.com) |
0 commit comments