Want to show Padrino some love? Help out by contributing to our framework!
Log it onto github 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.
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 textile format as can be seen for the Getting Started guide on Github.
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 firstname.lastname@example.org and request access.
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.
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:
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.
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.