Skip to content

Latest commit

 

History

History
100 lines (77 loc) · 4.72 KB

CONTRIBUTING.md

File metadata and controls

100 lines (77 loc) · 4.72 KB

Contribute

Want to show Sinatra some love? Help out by contributing!

Found a bug?

Log it in our issue tracker or send a note to the mailing list. Be sure to include all relevant information, like the versions of Sinatra and Ruby you're using. A gist of the code that caused the issue as well as any error messages are also very helpful.

Need help?

The Sinatra mailing list has over 900 subscribers, many of which are happy to help out newbies or talk about potential feature additions. You can also drop by the #sinatra channel on irc.freenode.net.

Have a patch?

Bugs and feature requests that include patches are much more likely to get attention. Here are some guidelines that will help ensure your patch can be applied as quickly as possible:

  1. Use Git and GitHub: The easiest way to get setup is to fork the sinatra/sinatra repo. Or, the sinatra.github.com repo, if the patch is doc related.

  2. Write unit tests: If you add or modify functionality, it must include unit tests. If you don't write tests, we have to, and this can hold up acceptance of the patch.

  3. Mind the README: If the patch adds or modifies a major feature, modify the README.md file to reflect that. Again, if you don't update the README, we have to, and this holds up acceptance.

  4. Update the change log (CHANGELOG.md): The change log helps give an overview of the changes that go into each release, and gives credit where credit is due. We make sure that the change log is up to date before each release, and we always appreciate it when people make it easier to get the release out the door.

  5. Push it: Once you're ready, push your changes to a topic branch and add a note to the ticket with the URL to your branch. Or, say something like, "you can find the patch on johndoe/foobranch". We also gladly accept GitHub pull requests.

NOTE: We will take whatever we can get. If you prefer to attach diffs in emails to the mailing list, that's fine; but do know that someone will need to take the diff through the process described above and this can hold things up considerably.

Want to write docs?

The process for contributing to Sinatra's website, documentation or the book is the same as contributing code. We use Git for versions control and GitHub to track patch requests.

Looking for something to do?

If you'd like to help out but aren't sure how, pick something that looks interesting from the issues list and hack on. Make sure to leave a comment on the ticket noting that you're investigating (a simple "Taking…" is fine).