middleman--middleman/.github/CONTRIBUTING.md

# Contributing
In the spirit of [free software][free-sw], **everyone** is encouraged to help
improve this project.

[free-sw]: http://www.fsf.org/licensing/essays/free-sw.html

Here are some ways *you* can contribute:

* by using alpha, beta, and prerelease versions
* by reporting bugs
* by suggesting new features
* by writing or editing documentation
* by writing specifications
* by writing code ( **no patch is too small** : fix typos, add comments, clean up inconsistent whitespace )
* by refactoring code
* by closing [issues][]
* by reviewing patches

[issues]: https://github.com/middleman/middleman/issues

## Submitting an Issue
We use the [GitHub issue tracker][issues] to track bugs and features. Before
submitting a bug report or feature request, check to make sure it hasn't
already been submitted. When submitting a bug report, please include a [Gist][]
that includes a stack trace and any details that may be necessary to reproduce
the bug, including your gem version, Ruby version, and operating system.
Ideally, a bug report should include a pull request with failing specs.

[gist]: https://gist.github.com/

## Submitting a Pull Request

**WE DO NOT ACCEPT NEW FEATURES FOR THE V3 BRANCH ANYMORE**

1. [Fork the repository.][fork]
2. Create a topic [branch]. `git checkout -b local_topic_branch`
3. Add specs for your unimplemented feature or bug fix.
4. [Run the tests](#running-the-tests). If your specs pass, return to step 3.
5. Implement your feature or bug fix.
6. Run the tests. If your specs fail, return to step 5.
7. Add, commit, and push your changes. To push your topic branch use `git push -u origin local_topic_branch`.
8. [Submit a pull request.][pr]

[fork]: http://help.github.com/fork-a-repo/
[branch]: https://help.github.com/articles/fork-a-repo#create-branches
[pr]: http://help.github.com/send-pull-requests/

## Testing

Internally, we test Middleman using a combination of [Cucumber][cucumber] and [RSpec][rspec]. Cucumber is used for specifying behavior a high level, whereas RSpec is used for testing components in isolation.

### Running the tests

1. Checkout Repository: `git clone https://github.com/middleman/middleman.git`
2. Install Bundler: `gem install bundler`
3. Run `bundle install` inside the project root to install the gem dependencies.
4. Run test cases: `bundle exec rake test`

[cucumber]: https://cucumber.io/
[rspec]: https://rspec.info/
add CONTRIBUTING.md / LICENSE.md, rejig README.md / .gemspec 2013-05-17 08:34:15 -04:00			`# Contributing`
			`In the spirit of [free software][free-sw], everyone is encouraged to help`
			`improve this project.`

			`[free-sw]: http://www.fsf.org/licensing/essays/free-sw.html`

			`Here are some ways you can contribute:`

			`* by using alpha, beta, and prerelease versions`
			`* by reporting bugs`
			`* by suggesting new features`
			`* by writing or editing documentation`
			`* by writing specifications`
Update CONTRIBUTING.md 2013-06-10 12:20:09 -04:00			`* by writing code ( no patch is too small : fix typos, add comments, clean up inconsistent whitespace )`
add CONTRIBUTING.md / LICENSE.md, rejig README.md / .gemspec 2013-05-17 08:34:15 -04:00			`* by refactoring code`
			`* by closing [issues][]`
			`* by reviewing patches`

			`[issues]: https://github.com/middleman/middleman/issues`

			`## Submitting an Issue`
			`We use the [GitHub issue tracker][issues] to track bugs and features. Before`
			`submitting a bug report or feature request, check to make sure it hasn't`
			`already been submitted. When submitting a bug report, please include a [Gist][]`
			`that includes a stack trace and any details that may be necessary to reproduce`
			`the bug, including your gem version, Ruby version, and operating system.`
			`Ideally, a bug report should include a pull request with failing specs.`

			`[gist]: https://gist.github.com/`

			`## Submitting a Pull Request`
Add warning for master as well 2015-11-11 17:30:49 -05:00
			`WE DO NOT ACCEPT NEW FEATURES FOR THE V3 BRANCH ANYMORE`

add CONTRIBUTING.md / LICENSE.md, rejig README.md / .gemspec 2013-05-17 08:34:15 -04:00			`1. [Fork the repository.][fork]`
Doc: topic branch link fix 2013-10-15 07:16:32 -04:00			2. Create a topic [branch]. `git checkout -b local_topic_branch`
add CONTRIBUTING.md / LICENSE.md, rejig README.md / .gemspec 2013-05-17 08:34:15 -04:00			`3. Add specs for your unimplemented feature or bug fix.`
Reference contribution guidelines in README (#2336) Information is duplicated between the two. I think it is simpler to keep the README focused on a Middleman user's perspective, whereas CONTRIBUTING.md can focus on a contributor's perspective. My motivation for this is that I'd like to later add more extensive documentation about testing Middleman from a contributor's perspective, but doing this in the README seemed like it would bloat it too much. 2020-06-09 13:36:38 -04:00			`4. [Run the tests](#running-the-tests). If your specs pass, return to step 3.`
add CONTRIBUTING.md / LICENSE.md, rejig README.md / .gemspec 2013-05-17 08:34:15 -04:00			`5. Implement your feature or bug fix.`
Reference contribution guidelines in README (#2336) Information is duplicated between the two. I think it is simpler to keep the README focused on a Middleman user's perspective, whereas CONTRIBUTING.md can focus on a contributor's perspective. My motivation for this is that I'd like to later add more extensive documentation about testing Middleman from a contributor's perspective, but doing this in the README seemed like it would bloat it too much. 2020-06-09 13:36:38 -04:00			`6. Run the tests. If your specs fail, return to step 5.`
Doc: topic branch link fix 2013-10-15 07:16:32 -04:00			7. Add, commit, and push your changes. To push your topic branch use `git push -u origin local_topic_branch`.
add CONTRIBUTING.md / LICENSE.md, rejig README.md / .gemspec 2013-05-17 08:34:15 -04:00			`8. [Submit a pull request.][pr]`

			`[fork]: http://help.github.com/fork-a-repo/`
Doc: topic branch link fix 2013-10-15 07:16:32 -04:00			`[branch]: https://help.github.com/articles/fork-a-repo#create-branches`
Update CONTRIBUTING.md 2013-06-10 12:20:09 -04:00			`[pr]: http://help.github.com/send-pull-requests/`
Reference contribution guidelines in README (#2336) Information is duplicated between the two. I think it is simpler to keep the README focused on a Middleman user's perspective, whereas CONTRIBUTING.md can focus on a contributor's perspective. My motivation for this is that I'd like to later add more extensive documentation about testing Middleman from a contributor's perspective, but doing this in the README seemed like it would bloat it too much. 2020-06-09 13:36:38 -04:00
			`## Testing`

			`Internally, we test Middleman using a combination of [Cucumber][cucumber] and [RSpec][rspec]. Cucumber is used for specifying behavior a high level, whereas RSpec is used for testing components in isolation.`

			`### Running the tests`

			1. Checkout Repository: `git clone https://github.com/middleman/middleman.git`
			2. Install Bundler: `gem install bundler`
			3. Run `bundle install` inside the project root to install the gem dependencies.
			4. Run test cases: `bundle exec rake test`

			`[cucumber]: https://cucumber.io/`
			`[rspec]: https://rspec.info/`