Browse files

add some more explanations on how to contribute

Changes should be done in specific branches on the forked repository. The
actual pull requests should go to the master or 1.0 branch depending on
whether it's a feature or bugfix change.
  • Loading branch information...
graste authored and ddelbondio committed Mar 9, 2014
1 parent 9399da8 commit 1570c15c783eaea518d32ccc3fc2213af69ddf92
Showing with 15 additions and 8 deletions.
  1. +15 −8
@@ -4,20 +4,27 @@ Input and contributions are very welcome! Please open issues with
improvements, feature requests or bug reports. To contribute source code,
add documentation or fix spelling mistakes try this:
-1. [Fork]( a current branch (like master).
-1. Clone the forked git.
-1. Make changes and additions.
+1. [Fork]( this repository.
+1. Clone the forked repository via ```git clone```.
+1. [Install composer]( and check that
+ the tests run via ```cd test && php run-tests.php```
+1. Make changes and additions in specific branches and add tests where appropriate.
1. Verify changes and make sure that the tests succeed.
1. Add, commit, squash and push the changes to the forked repository.
-1. Send a [pull request]( to Agavi
+1. Send a [pull request]( to Agavi.
+ 1. Pull requests for bugfixes should go to the `1.0` branch.
+ 1. Pull requests for features should go to the `master` branch.
Please provide a well written issue describing the change and why it is
+necessary. This is helpful for maintainers that want to integrate your changes
+into Agavi. You may add a [CHANGELOG](CHANGELOG) entry suggestion to the pull
+request ticket.
## Coding styles
Please see the [coding style hints]( before making changes
-and try to adhere to them.
+and try to adhere to them as otherwise incorporating the changes into Agavi is
+not easily possible and may prevent the pull request from being accepted at all.
## Commit messages
@@ -39,13 +46,13 @@ licenses. For a list of contributors see the [github contributors graph](https:/
## Separate changes
Different independent logical changes should be separated into separate commits
-Separate patch submissions allow each change to be considered on it's own and
+Separate patch submissions allow each change to be considered on its own and
make reviews a lot easier.
## Tests
Commits are continously integrated via [TravisCI](
and failing the PHPUnit tests will fail the builds. Usually the build status
will be shown on the pull request by Github. If something fails please try to
-fix your changes as otherwise they can't be easily integrated by maintainers.
+fix the changes as otherwise they can't be easily integrated by maintainers.

0 comments on commit 1570c15

Please sign in to comment.