Skip to content

Latest commit

 

History

History
78 lines (62 loc) · 2.66 KB

2012-07-19-contributing.md

File metadata and controls

78 lines (62 loc) · 2.66 KB
Raw
layout title prev_section next_section
docs
Contributing
manual-deployment
issues

So you’ve got an awesome idea to throw into Jekyll. Great! Please keep the following in mind:

  • Contributions will not be accepted without tests.
  • If you’re creating a small fix or patch to an existing feature, just a simple test will do. Please stay in the confines of the current test suite and use Shoulda and RR.
  • If it’s a brand new feature, make sure to create a new Cucumber feature and reuse steps where appropriate. Also, whipping up some documentation in your fork’s wiki would be appreciated, and once merged it will be transferred over to the main wiki.

Test Dependencies

To run the test suite and build the gem you’ll need the following gems installed:

$ [sudo] gem install shoulda redgreen rr rdiscount kramdown maruku RedCloth cucumber liquid

You’ll also need Pygments installed to run the features.
You’ll also need “RedCarpet”, but not the latest version (2.x), because it is not compatible\

$ [sudo] gem install redcarpet ==--==version=1.17.2

Before you start, run the tests and make sure that they pass (to confirm your environment is configured properly):

$ rake test
$ rake features

Workflow

Here’s the most direct way to get your work merged into the project:
# Fork the project
# Clone down your fork ( git clone git://github.com/<username>/jekyll.git )
# Create a topic branch to contain your change ( git checkout -b my_awesome_feature )
# Hack away, add tests. Not necessarily in that order.
# Make sure everything still passes by running rake
# If necessary, rebase your commits into logical chunks, without errors
# Push the branch up ( git push origin my_awesome_feature )
# Create an issue with a description and link to your branch

Gotchas

  • If you want to bump the gem version, please put that in a separate commit. This way, the maintainers can control when the gem gets released.
  • Try to keep your patch(es) based from the latest commit on mojombo/jekyll. The easier it is to apply your work, the less work the maintainers have to do, which is always a good thing.
  • Please don’t tag your GitHub issue with fix, feature, etc. The maintainers actively read the issues and will label it once they come across it.

Finally…

Thanks! Hacking on Jekyll should be fun, and if for some reason it’s a pain to do let us know so we can fix it.