From 6cc78957c26ad4c65e96c57eb8ff81e1e570c3c3 Mon Sep 17 00:00:00 2001 From: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com> Date: Thu, 24 Oct 2019 12:39:55 -0600 Subject: [PATCH] Update CONTRIBUTING.md [ci skip] - Clarifies examples - Fixes grammatical inconsistencies --- CONTRIBUTING.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 618108b417a..f671beb6bc1 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -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) @@ -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. @@ -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 @@ -56,11 +56,11 @@ 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) @@ -68,7 +68,7 @@ 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