From 557ee5c23b4c6b69989725266f8bc643c017633e Mon Sep 17 00:00:00 2001 From: cbracco Date: Tue, 8 Apr 2014 11:50:43 -0400 Subject: [PATCH] added CONTRIBUTING.md --- CONTRIBUTING.md | 114 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 114 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..562aded --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,114 @@ +# Contributing to this project + +*This information is heavily based on [this CONTRIBUTING.md document](https://github.com/necolas/normalize.css/edit/master/CONTRIBUTING.md).* + +Before making a contribution, please take a moment to review this document. It will make the process easier and more enjoyable for everyone involved. + +Following the guidelines in this document shows that you respect the time of the maintainers of this open-source project. In return, maintainers should show their respect for you by addressing your requests, issues, and contributions in a timely fashion. + +## Submitting issues + +GitHub’s built-in issue tracker is the preferred channel for bug reports, feature requests, and submitting pull requests. + +**Do not** use the issue tracker for personal support questions. They will probably not be addressed. +**Do not** derail or troll issues. Please try to keep things on topic and be respectful to others. + +## Bug reports + +*Demo or it didn’t happen.* + +A bug is a problem that you can demonstrate to a maintainer on this open-source project. Good bug reports are very helpful, and encouraged! + +If you are thinking about reporting a bug, please do the following: + +1. **Search for existing issues** - it could have already been reported. +2. **Check for fixes** - try to reproduce the bug using the latest release on the `master` branch in the repository. +3. **If the bug persists**, submit an issue and create a live example of the bug using a public service like [jsFiddle](http://jsfiddle.net) or [Codepen](http://codepen.io). Link to your example in the issue that you submit. + +Please be as detailed as possible. Ask yourself: What is your environment? What steps will reproduce the issue? What browser(s) and OS experience the problem? What would you expect to be the outcome? + +## Feature requests + +Feel free to request whatever you like, but please take a moment to think about whether your request is within the scope of the project. You should make a strong case for your request, otherwise the maintaining developers will probably not consider it. Provide as much detail as you can. + +## Pull requests + +Good pull requests are awesome. Bad pull requests are a headache. They should always be limited by the scope of the request, and avoid including unrelated commits. + +**Please file an issue first** before deciding to do a lot of work. Otherwise, you run the risk of wasting time working on something that might not get merged into the project. + +Follow this process if you’d like your work to be considered for inclusion in the project: + +1. [Fork](http://help.github.com/fork-a-repo/) the project, clone your fork, + and configure the remotes: + + ```bash + # Clone your fork of the repo into the current directory + git clone https://github.com//html5-test-page + # Navigate to the newly cloned directory + cd html5-test-page + # Assign the original repo to a remote called "upstream" + git remote add upstream https://github.com/cbracco/html5-test-page + ``` + +2. If you cloned a while ago, get the latest changes from upstream: + + ```bash + git checkout master + git pull upstream master + ``` + +3. **Never work directly on `master`**. Create a new topic branch (off the latest version of `master`) to contain your feature, change, or fix: + + ```bash + git checkout -b + ``` + +4. Commit your changes in logical chunks. Please adhere to these [git commit + message conventions](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) + or your code is unlikely be merged into the main project. Use Git’s + [interactive rebase](https://help.github.com/articles/interactive-rebase) + feature to tidy up your commits before making them public. + + Please add a test to the `test.html` file if appropriate, and test + your change(s) in all supported browsers. + +5. Locally rebase the upstream development branch into your topic branch: + + ```bash + git pull --rebase upstream master + ``` + +6. Push your topic branch up to your fork: + + ```bash + git push origin + ``` + +10. [Open a Pull Request](https://help.github.com/articles/using-pull-requests/) with a clear title and description. + +**IMPORTANT**: By submitting a patch, you agree to allow the project owner to +license your work under the same license as that used by the project. + +## Maintainers + +If you have commit access, please follow this process for merging patches and +cutting new releases. + +### Accepting patches + +1. Check that a patch is within the scope and philosophy of the project. +2. Check that a patch has any necessary tests and a proper, descriptive commit + message. +3. Test the patch locally. +4. Do not use GitHub’s merge button. Apply the patch to `master` locally + (either via `git am` or by checking the whole branch out). Amend minor + problems with the author’s original commit if necessary. Then push to GitHub. + +### Releasing a new version + +1. Include all new functional changes in the CHANGELOG. +2. Use a dedicated commit to increment the version. The version needs to be added to the `README.md`, `CHANGELOG.md` (inc. date), `bower.json`, `package.json`, and `css/main.css` files. +3. The commit message must be of `v0.0.0` format. +4. Create an annotated tag for the version: `git tag -m "v0.0.0" 0.0.0`. +5. Push the changes and tags to GitHub: `git push --tags origin master`