In the spirit of free software, everyone is encouraged to help improve this project. This guide suggests ways to get involved and covers the workflow the development team uses for submitting and managing contributions.
Thanks for stopping by! Now’s your chance to get involved. Here are some ways you can contribute:
-
Use alpha, beta, and prerelease versions
-
We love testers!
-
-
Report bugs
-
Don’t be shy. Let us know when things aren’t working. Don’t suffer in silence.
-
-
Suggest new features
-
Innovation FTW!
-
-
Write, edit or review documentation
-
Others want to know how it works too. Once you figure it out, please share!
-
-
Add specifications (i.e., cucumber tests)
-
Write code
-
No patch is too small! (e.g., fix typos, add comments, clean up inconsistent whitespace)
-
-
Refactor code
-
Resolve issues
-
Review open pull requests
This section covers the workflow the development team uses when making contributions. If you follow these recommendations, you’ll maximize the chance of your contribution being accepted in a timely manner.
We use the GitHub issue tracker to track bugs and features. Before submitting a bug report or feature request, check to make sure an issue hasn’t already been submitted for it.
When submitting a bug report, please include any details that may be necessary to reproduce the bug, including the version of the gem, the version of Ruby you are using and your operating system. Ideally, a bug report should include a pull request with a failing cucumber test.
-
$ git clone https://github.com/middleman/middleman-asciidoc
-
Create a branch to manage your changes.
$ git checkout -b issue-n -t origin/master
Please name the branch
issue-n
(where "n" is the issue number). -
Implement your change and add a cucumber test to verify it.
-
Run the tests.
$ bundle exec rake cucumber
If your tests don’t pass, return to step 3.
-
Add, commit, and push your changes.
-
Your commit message should start with
resolves #n
(where "n" is the issue number) -
When your change is merged, the issue will be automatically closed.
-
If you’re a project maintainer, please follow the GitHub Flow instead of pushing directly to master, especially when resolving an issue. And please make sure to push the branch to your own fork when creating a pull request, not the upstream repository.
You can merge your own pull request, but please allow a period of time for commit (24 hours is the general rule of thumb). This timeout period provides an opportunity for code review and encourages participation.