mirror of
https://github.com/middleman/middleman.git
synced 2022-11-09 12:20:27 -05:00
03170316b8
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.
60 lines
2.3 KiB
Markdown
60 lines
2.3 KiB
Markdown
# 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/
|