@@ -36,7 +36,7 @@ We welcome pull requests with fixes and improvements to GitLab code, tests, and/
...
@@ -36,7 +36,7 @@ We welcome pull requests with fixes and improvements to GitLab code, tests, and/
### Pull request guidelines
### Pull request guidelines
If you can, please submit a pull request with the fix or improvements including tests. If you don't know how to fix the issue but can write a test that exposes the issue we will accept that as well. The workflow to make a pull request is as follows:
If you can, please submit a pull request with the fix or improvements including tests. If you don't know how to fix the issue but can write a test that exposes the issue we will accept that as well. In general bug fixes that include a regression test are merged quickly while new features without proper tests are least likely to receive timely feedback. The workflow to make a pull request is as follows:
1. Fork the project on GitHub
1. Fork the project on GitHub
1. Create a feature branch
1. Create a feature branch
...
@@ -51,10 +51,11 @@ We will accept pull requests if:
...
@@ -51,10 +51,11 @@ We will accept pull requests if:
* The code has proper tests and all tests pass (or it is a test exposing a failure in existing code)
* The code has proper tests and all tests pass (or it is a test exposing a failure in existing code)
* It can be merged without problems (if not please use: `git rebase master`)
* It can be merged without problems (if not please use: `git rebase master`)
* It doesn't break any existing functionality
* It doesn't break any existing functionality
* It's quality code that conforms to the [Rails style guide](https://github.com/bbatsov/rails-style-guide) and best practices
* It's quality code that conforms to the [Ruby](https://github.com/bbatsov/ruby-style-guide) and [Rails](https://github.com/bbatsov/rails-style-guide) style guides and best practices
* The description includes a motive for your change and the method you used to achieve it
* The description includes a motive for your change and the method you used to achieve it
* It keeps the GitLab code base clean and well structured
* It keeps the GitLab code base clean and well structured
* We think other users will benefit from the same functionality
* We think other users will benefit from the same functionality
* If it makes changes to the UI the pull request should include screenshots
* If it makes changes to the UI the pull request should include screenshots
* It is a single commit (please use git rebase -i to squash commits)
For examples of feedback on pull requests please look at already [closed pull requests](https://github.com/gitlabhq/gitlabhq/pulls?direction=desc&page=1&sort=created&state=closed).
For examples of feedback on pull requests please look at already [closed pull requests](https://github.com/gitlabhq/gitlabhq/pulls?direction=desc&page=1&sort=created&state=closed).
*[![Dependency Status](https://gemnasium.com/gitlabhq/gitlabhq.png)](https://gemnasium.com/gitlabhq/gitlabhq) this button can be yellow (small updates are available) but must not be red (a security fix or an important update is available)
*[![Dependency Status](https://gemnasium.com/gitlabhq/gitlabhq.png)](https://gemnasium.com/gitlabhq/gitlabhq) this button can be yellow (small updates are available) but must not be red (a security fix or an important update is available), gems are updated in major releases of GitLab.