From 299c18fd0c7d9f22619ff9b6b463715d2a1e441e Mon Sep 17 00:00:00 2001 From: Sam Richard Date: Thu, 30 Apr 2015 07:12:59 -0400 Subject: [PATCH 1/4] :memo: Add Contributing guidelines --- CONTRIBUTING.md | 71 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 71 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..076047d --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,71 @@ +# Contributing to Gulp Sass + +Gulp Sass is a very light-weight [Gulp](https://github.com/gulpjs/gulp) wrapper for [`node-sass`](https://github.com/sass/node-sass), which in turn is a Node binding for [`libsass`](https://github.com/sass/libsass), which in turn is a port of [`Sass`](https://github.com/sass/sass). + +## Submitting Issues + +* Before creating a new issue, perform a [cursory search](https://github.com/issues?utf8=%E2%9C%93&q=repo%3Adlmanning%2Fgulp-sass+repo%3Asass%2Fnode-sass+repo%3Asass%2Flibsass+repo%3Asass%2Fsass+repo%3Asass-eyeglass%2Feyeglass) in the Gulp Sass, Node Sass, Libsass, and main Sass repos to see if a similar issue has already been submitted. +* You can create an issue [here](https://github.com/dlmanning/gulp-sass/issues). Please include as many details as possible in your report. +* Issue titles should be descriptive, explaining at the high level what it is about. +* Please include the version of `gulp-sass` you are using. +* Do not open a [pull request](#pull-requests) to resolve an issue without first receiving feedback from a `collaborator` or `owner` and having them agree on a solution forward. +* Include screenshots and animated GIFs whenever possible; they are immensely helpful. +* Issues that have a number of sub-items that need to be complete should use [task lists](https://github.com/blog/1375%0A-task-lists-in-gfm-issues-pulls-comments) to track the sub-items in the main issue comment. + + +## Pull Requests + +* **DO NOT ISSUE A PULL REQUEST WITHOUT FIRST [SUBMITTING AN ISSUE](#submitting-issues)** +* Pull requests should reference their related issues. If the pull request closes an issue, [please reference its closing in your commit messages](https://help.github.com/articles/closing-issues-via-commit-messages/). Pull requests not referencing any issues will be closed. +* Pull request titles should be descriptive, explaining at the high level what it is doing, and should be written in the same style as [Git commit messages](#git-commit-messages). +* Update the `CHANGELOG` with the changes made by your pull request, making sure to use the proper [Emoji](#emoji-cheatsheet). +* Follow our JavaScript styleguides. Tests will fail if you do not. +* Ensure that you have [EditorConfig](http://editorconfig.org/) installed in your editor of choice and that it is functioning properly. +* Do not squash or rebase your commits when submitting a Pull Request. It makes it much harder to follow your work and make incremental changes. +* Update the [CHANGELOG](#maintaining-thechangelog) with your changes. +* Ensure no Emoji tags are used in the title of your Pull Request + +### Git Commit Messages + +* Use the present tense (`"Add feature"` not `"Added Feature"`) +* Use the imperative mood (`"Move cursor to…"` not `"Moves cursor to…"`) +* Limit the first line to 72 characters or less +* Include relevant Emoji from our [Emoji cheatsheet](#emoji-cheatsheet) + +### Branching Model + +* Branches must be made off of the most current `master` branch from `git@github.com:dlmanning/gulp-sass.git` +* Pull requests must be made into our [master](https://github.com/dlmanning/gulp-sass/tree/master) branch. +* The following branch prefixes should be used when creating a new branch: + * `hotfix/` - fixes a bug that got through to a live version and need to be squashed + * `feature/` - update to or new code for `gulp-sass` + * `release/` - a release of `gulp-sass` + +## Creating a New Version + +Versioning is done through [SEMVER](http://semver.org/). When creating a new version, create new release branch off of `master` with the version's name, and create a new tag with `v` prefixed with the version's name from that branch. + +For instance, if you are creating version `1.1.0`, you would start by merging `develop` into `master`, create a branch `release/1.1.0` from `master`, and create a tag `v1.1.0` from branch `release/1.1.0`. + +### Maintaining the Changelog + +The Changelog should have a list of changes made for each version. They should be organized so additions come first, changes come second, and deletions come third. Version numbers should be 2nd level headers with the `v` in front (like a tag) and the date of the version's most recent update should be underneath in italics. + +Changelog messages do not need to cover each individual commit made, but rather should have individual summaries of the changes made. Changelog messages should be written in the same style as [Git commit messages](#git-commit-messages). + +## Emoji Cheatsheet + +When creating creating commits or updating the CHANGELOG, please **start** the commit message or update with one of the following applicable Emoji. Emoji should not be used at the start of issue or pull request titles. + +* :art: `:art:` when improving the format/structure of the code +* :racehorse: `:racehorse:` when improving performance +* :memo: `:memo:` when writing long-form text (documentation, guidelines, principles, etc…) +* :bug: `:bug:` when fixing a bug +* :fire: `:fire:` when removing code or files +* :green_heart: `:green_heart:` when fixing the CI build +* :white_check_mark: `:white_check_mark:` when adding tests +* :lock: `:lock:` when dealing with security +* :arrow_up: `:arrow_up:` when upgrading dependencies +* :arrow_down: `:arrow_down:` when downgrading dependencies +* :shirt: `:shirt:` when removing linter warnings +* :shipit: `:shipit:` when creating a new release From ee07858ef462fdf5d0f746fe65dcdda0c204a980 Mon Sep 17 00:00:00 2001 From: Sam Richard Date: Thu, 30 Apr 2015 07:13:41 -0400 Subject: [PATCH 2/4] :art: Update formatting of CHANGELOG entry --- CHANGELOG.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 0fc5da4..0bbaacd 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,7 +1,8 @@ # Gulp Sass Changelog ## v2.0.0-alpha.1 -### March 26, 2015 +**March 26, 2015** + * **New** Added `renderSync` option that can be used through `sass.sync()` ### March 24, 2015 From e072993c5596a6a1a0fef29108aa1e64d0399757 Mon Sep 17 00:00:00 2001 From: Sam Richard Date: Fri, 1 May 2015 07:58:00 -0400 Subject: [PATCH 3/4] :fire: Remove Branching Model section :memo: Lighten wording on Emoji usage --- CONTRIBUTING.md | 14 +++----------- 1 file changed, 3 insertions(+), 11 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 076047d..9a448a3 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -23,23 +23,15 @@ Gulp Sass is a very light-weight [Gulp](https://github.com/gulpjs/gulp) wrapper * Ensure that you have [EditorConfig](http://editorconfig.org/) installed in your editor of choice and that it is functioning properly. * Do not squash or rebase your commits when submitting a Pull Request. It makes it much harder to follow your work and make incremental changes. * Update the [CHANGELOG](#maintaining-thechangelog) with your changes. -* Ensure no Emoji tags are used in the title of your Pull Request +* Branches should be made off of the most current `master` branch from `git@github.com:dlmanning/gulp-sass.git` +* Pull requests should be made into our [master](https://github.com/dlmanning/gulp-sass/tree/master) branch. ### Git Commit Messages * Use the present tense (`"Add feature"` not `"Added Feature"`) * Use the imperative mood (`"Move cursor to…"` not `"Moves cursor to…"`) * Limit the first line to 72 characters or less -* Include relevant Emoji from our [Emoji cheatsheet](#emoji-cheatsheet) - -### Branching Model - -* Branches must be made off of the most current `master` branch from `git@github.com:dlmanning/gulp-sass.git` -* Pull requests must be made into our [master](https://github.com/dlmanning/gulp-sass/tree/master) branch. -* The following branch prefixes should be used when creating a new branch: - * `hotfix/` - fixes a bug that got through to a live version and need to be squashed - * `feature/` - update to or new code for `gulp-sass` - * `release/` - a release of `gulp-sass` +* Consider including relevant Emoji from our [Emoji cheatsheet](#emoji-cheatsheet) ## Creating a New Version From 083e6bcb9c13ff9b56ccfd6f444a7ba7ff0f86d3 Mon Sep 17 00:00:00 2001 From: Sam Richard Date: Tue, 5 May 2015 08:56:08 -0400 Subject: [PATCH 4/4] :fire: Remove reference to branch --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 9a448a3..4ab9e5f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -37,7 +37,7 @@ Gulp Sass is a very light-weight [Gulp](https://github.com/gulpjs/gulp) wrapper Versioning is done through [SEMVER](http://semver.org/). When creating a new version, create new release branch off of `master` with the version's name, and create a new tag with `v` prefixed with the version's name from that branch. -For instance, if you are creating version `1.1.0`, you would start by merging `develop` into `master`, create a branch `release/1.1.0` from `master`, and create a tag `v1.1.0` from branch `release/1.1.0`. +For instance, if you are creating version `1.1.0`, you would create a branch `release/1.1.0` from `master` and create a tag `v1.1.0` from branch `release/1.1.0`. ### Maintaining the Changelog