From 96de78a15398326e4e4e0a53eebab5e0dcb8b02f Mon Sep 17 00:00:00 2001 From: Ryan Arneson Date: Fri, 9 Nov 2018 11:41:19 -0600 Subject: [PATCH] Grammar and typo updates. External links included where necessary. --- CONTRIBUTING.md | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 5be3a99d625..d544f183f31 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -48,11 +48,11 @@ You can get the dev branch checked out using `git checkout dev`. ## Style Guide -Some simple rules, that will make it easier to maintain our codebase: +Some simple rules that will make it easier to maintain our codebase: -* All indenting should use 2 space where possible (js, css, html, etc) -* A space before function parameters, such as: `function boom (name, callback) { }`, this makes searching for calls easier -* Name your callback functions, such as `boom('the name', function afterBoom ( result ) { }` +* All indenting should use 2 space where possible (js, css, html, etc). +* Include a space before function parameters, such as: `function boom (name, callback) { }`, this makes searching for function calls easier. +* Name your callback functions, such as `boom('the name', function afterBoom ( result ) { }`. * Don't include author names in the header of your files, if you need to give credit to someone else do it in the commit comment. * Use single quotes. * Use the comma first style, for example: @@ -70,7 +70,7 @@ Some simple rules, that will make it easier to maintain our codebase: Fork cgm-remote-monitor and create a branch. You can create a branch using `git checkout -b wip/add-my-widget`. This creates a new branch called `wip/add-my-widget`. The `wip` -stands for work in progress and is a common prefix so that when know +stands for work in progress and is a common prefix so that we know what to expect when reviewing many branches. ## Submit a pull request @@ -80,8 +80,8 @@ post on popular channels such as Facebook. We encourage contributors to submit their code for review, debate, and release before announcing features on social media. -This can be done by checking your code `git commit -avm 'my -improvements are here'`, the branch you created back to your own +This can be done by committing your code `git commit -avm 'my +improvements are here'`, and pushing it to the branch you created on your own fork. This will probably look something like `git push -u origin wip/add-my-widget`. @@ -99,24 +99,24 @@ appropriate. Most cgm-remote-monitor hackers use github's ticketing system, along with Facebook cgm-in-the-cloud, and gitter. -We use git-flow, with `master` as our production, stable branch, and -`dev` is used to queue up for upcoming releases. Everything else is +We use [git-flow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow), with `master` as our production, stable branch, and +`dev` is used to queue changes for upcoming releases. Everything else is done on branches, hopefully with names that indicate what to expect. Once `dev` has been reviewed and people feel it's time to release, we follow the git-flow release process, which creates a new tag and bumps -the version correctly. See sem-ver for versioning strategy. +the version correctly. See [sem-ver](https://semver.org/) for versioning strategy. -Every commit is tested by travis. We encourage adding tests to +Every commit is tested by Travis CI. We encourage adding tests to validate your design. We encourage discussing your use cases to help everyone get a better understanding of your design. ## Other Dev Tips * Join the [Gitter chat][gitter-url] -* Get a local dev environment setup if you haven't already -* Try breaking up big features/improvements into small parts. It's much easier to accept small PR's -* Create tests for your new code, and for the old code too. We are aiming for a full test coverage. -* If your going to be working in old code that needs lots of reformatting consider doing the clean as a separate PR. -* If you can find others to help test your PR is will help get them merged in sooner. +* Get a local dev environment setup if you haven't already. +* Try breaking up big features/improvements into small parts. It's much easier to accept small PR's. +* Create tests for your new code as well as the old code. We are aiming for a full test coverage. +* If you're going to be working in old code that needs lots of reformatting, consider doing it as a separate PR. +* If you can find others to help test your PR, it will help get them merged in sooner.