-
Do not open up a GitHub issue if the bug is a security vulnerability in Rails, and instead to refer to our security policy.
-
Ensure the bug was not already reported by searching on GitHub under Issues.
-
If you're unable to find an open issue addressing the problem, open a new one. Be sure to include a title and clear description, as much relevant information as possible, and a code sample or an executable test case demonstrating the expected behavior that is not occurring.
-
If possible, use the relevant bug report templates to create the issue. Simply copy the content of the appropriate template into a .rb file, make the necessary changes to demonstrate the issue, and paste the content into the issue description:
-
For more detailed information on submitting a bug report and creating an issue, visit our reporting guidelines.
-
Open a new GitHub pull request with the patch.
-
Ensure the PR description clearly describes the problem and solution. Include the relevant issue number if applicable.
-
Before submitting, please read the Contributing to Ruby on Rails guide to know more about coding conventions and benchmarks.
Changes that are cosmetic in nature and do not add anything substantial to the stability, functionality, or testability of Rails will generally not be accepted (read more about our rationales behind this decision).
-
Suggest your change in the rubyonrails-core mailing list and start writing code.
-
Do not open an issue on GitHub until you have collected positive feedback about the change. GitHub issues are primarily intended for bug reports and fixes.
- Ask any question about how to use Ruby on Rails in the rubyonrails-talk mailing list.
- Please read Contributing to the Rails Documentation.
Ruby on Rails is a volunteer effort. We encourage you to pitch in and join the team!
Thanks! ❤️ ❤️ ❤️
Rails Team