Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update CONTRIBUTING.md [ci skip] #3402

Merged
merged 1 commit into from
Oct 25, 2019
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 11 additions & 11 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,8 +2,8 @@

When filing an issue on the Solidus project, please provide these details:

* A comprehensive list of steps to reproduce the issue.
* What you're *expecting* to happen compared with what's *actually* happening.
* A comprehensive list of steps to reproduce the issue
* What you're *expecting* to happen compared with what's *actually* happening
* Your application's complete `Gemfile`, and `Gemfile.lock` as text in a [Gist](https://gist.github.com) (*not as an image*)
* Any relevant stack traces ("Full trace" preferred)

Expand All @@ -17,12 +17,12 @@ Any issue that is open for 14 days without actionable information or activity
will be marked as "stalled" and then closed. Stalled issues can be re-opened if
the information requested is provided.

## Pull requests
## Opening pull requests

We gladly accept pull requests to add documentation, fix bugs and, in some circumstances,
add new features to Solidus.

Here's a quick guide:
Here's a quick guide to opening a PR:

1. Fork the repo.

Expand All @@ -39,8 +39,8 @@ functionality or fixing a bug, we need tests!
to the latest stable branches and master branch, you will only need to submit one
pull request.

5. If a PR does not apply cleanly to one of its targeted branches, then a separate
PR should be created that does. For instance, if a PR applied to master & 2-1-stable but not 2-0-stable, then there should be one PR for master & 2-1-stable and another, separate PR for 2-0-stable.
5. If a PR does not apply cleanly to all of its targeted branches - for example,
slighty different fixes for mulitple versions - then multiple PRs are necessary.

At this point you're waiting on us. We like to at least comment on, if not
accept, pull requests within three business days (and, typically, one business
Expand All @@ -56,19 +56,19 @@ Though in some cases the Core Team may choose not to merge a PR that meets these

### Pull Request guidelines

* The specs must pass for each individual commit.
* Each individual commit should make sense by itself as far as possible.
* Breaking up a large change into smaller (coherent) commits is encouraged.
* The specs must pass for each individual commit
* Each individual commit should make sense by itself as far as possible
* Breaking up a large change into smaller (coherent) commits is encouraged
* We do not currently have a policy about whether or not to force-push while
people are reviewing your pull request.
people are reviewing your pull request
* Good commit messages are also encouraged. Here are some resources on writing
good commit messages:
* [Notes from Linus](https://github.com/torvalds/subsurface/commit/b6590150d68df528efd40c889ba6eea476b39873)
* [Erlang's guide](https://github.com/erlang/otp/wiki/Writing-good-commit-messages)
* [An often-cited post](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)

Some things that will increase the chance that your pull request is accepted,
taken straight from the Ruby on Rails guide:
taken straight from the [Ruby on Rails guide](http://guides.rubyonrails.org/contributing_to_ruby_on_rails.html):

* Use Rails idioms and helpers
* Include tests that fail without your code, and pass with it
Expand Down