From 9cba3ef6d054e2b8118ca387fe25a0ffb11f41f0 Mon Sep 17 00:00:00 2001 From: Devin Cooper Date: Thu, 28 Apr 2016 14:30:20 -0400 Subject: [PATCH] Docs: Update `CONTRIBUTING` documentation. --- CONTRIBUTING.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0f87b9a..488b0b4 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -6,13 +6,13 @@ The first step to contributing fixes and improvements to `PostIt`, is [forking t ## Never Commit on Master -When working on a fork, always think of your master branch as a 'landing place' for upstream changes. Only make commits to topic branches. Only `PostIt` maintainers, have the authority to merge in upstream commits. +When working on a fork, always think of your master branch as a 'landing place' for upstream changes. Only make commits to topic branches. Only `PostIt` maintainers have the authority to merge in upstream commits. ## Commit Message Guidelines Commit messages are written in a simple format, which clearly describes the purpose of a change. -Commit message summaries, must follow the following format: +Commit message summaries must follow the following format: ``` Type: message (fixes|refs #number) @@ -28,29 +28,29 @@ Type: message (fixes|refs #number) * `New` - New feature. * `Upgrade` - Dependency upgrade. -The message should succinctly summarize, the change. In addition, an issue number, must be added, at the end, e.g., +The message should succinctly summarize the change. In addition, an issue number must be added at the end, e.g., ``` Build: Allow revert commits in commit messages. (refs #734) Fix: Properly parse and add response Headers to Response. (fixes #840) ``` -It is important to note, that if a commit does not completely fix a given issue, then, use `(refs #1234)` instead of `(fixes #1234)`. +It is important to note, that if a commit does not completely fix a given issue, then use `(refs #1234)` instead of `(fixes #1234)`. -The commit message format, is important, given that the `CHANGELOG` is generated based on said conventions. +The commit message format is important, given that the `CHANGELOG` is generated based on said conventions. ## Submit a Pull Request When a commit is ready to be reviewed by a `PostIt` maintainer, submit a [pull request](https://help.github.com/articles/creating-a-pull-request). Push the topic branch to your fork and then use one of the several options in `GitHub`'s interface to initiate the request. Please do not commit `docs` and/or `dist` files; `PostIt` maintainers will address such, when cutting a new release. -Unless a rather minor change, has been made, it is generally a good practice, to file an issue, explaining your idea, before writing code or submitting a pull request -- especially when introducing new features. +Unless a rather minor change has been made, it is generally a good practice to file an issue explaining your idea, before writing code or submitting a pull request -- especially when introducing new features. ## Gulp Tasks ### Testing/Linting -Run unit tests and/or linting. +Run unit tests/linting. ```bash # Lint and Unit Tests @@ -91,7 +91,7 @@ For more information on SemVer, please visit . | Safari | Latest | | Internet Explorer | 9+ * | -*= `PostIt.openWindow` does not work in IE, cross-domain, whilst using `.postMessage`; however, `iframe` support is available. +*= `PostIt.openWindow` does not work in IE (cross-domain), whilst using `.postMessage`; however, `iframe` support is available. ## Coding Guidelines