Found a bug?

Let us know by
creating a new issue. Be
sure to include all relevant information, like the versions of Padrino and Ruby
you are using. A gist of the code that caused the
issue as well as any error messages are also very helpful.

Want to integrate a component?

Have a particular JavaScript engine you like? Know of a popular ORM or testing
framework that we have overlooked in Padrino generators? We encourage you to
contribute by creating a patch to integrate your favorite components into
Padrino! Check out the guide for
adding new components
to read a detailed walkthrough of how to do this!

Want to help with documentation?

The process for contributing to Padrino’s website or documentation is as simple
as forking the docs repository and
sending in any changes as a pull request. Once a change has been accepted, the
documentation will be updated on our website. The website guides and docs are
currently in the GitHub Flavored Markdown
format as can be seen for the
Getting Started
guide on Github.

YARD

There is also important YARD documentation within the framework code itself
which could always use improvements. An example is the
asset tag
helpers file which is marked up with YARD annotations for every object and
method.

Be sure to read over the
YARD Getting Started
and Tag Overview guides for
more details on this syntax. Every component of Padrino should be documented
with YARD annotations which will be generated periodically to our
official api
documentation page.

You can also contact us for access to modifying the pages and guides within our
site directly once you have had a patch accepted. Simply email
padrinorb@gmail.com and request access.

Code Guidelines

Padrino core contributors also have several code guidelines and conventions that
we try and keep consistent within our codebase. We try to follow the common
Ruby code guidelines
such as two space soft tab indentations, and we also like to keep a newline at
the end of every ruby file.

Another convention to keep in mind is to minimize all trailing and unnecessary
whitespace. If you are using TextMate, be sure to check out the
uberglory which will
automatically keep your code and spacing clean.

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:

Use Git and GitHub: The easiest
way to get setup is to fork the
padrino repo. Or, post a
comment, if the patch is doc related.

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.

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

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”.

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.

Looking for something to do?

If you’d like to help out but aren’t sure how, take a look at the
GitHub Issues page. If you
find something that looks interesting, leave a comment on the ticket noting that
you’re investigating (a simple “Taking…” is fine). Once you’ve worked on a few
issues, someone will add you as an assignee.