Easiest way to contribute is to be responsible for a production app running the latest rails version and work on it every day. You will eventually end up adding to your app something that does not exist in Rails, but might be useful so you can try to upstream it.
Another way is to run Rails Edge (point you gemfile to github: "rails/rails", branch: "main") have a good test suite and update often. You will eventually come across a change that breaks something in your app (but didn’t break in the other contributor’s app or rails CI), which will allow you to fix it.
At least, that’s how all my contributions happened.
If you’re just starting, why not focus on reviewing existing PRs for now? The focused change will give you a targeted space to investigate, and you can try cloning & running the tests yourself. Once you’re comfortable with the ecosystem you could then start looking for smaller tickets to tackle yourself.
Got it. I was doing that only will try to understand the changes.
Sometimes it’s hard to understand the changes done by the user so in that case is it okay to ask doubts in comment sections or else we follow any other practice?
Join the Rails community on GitHub and other communication channels (e.g., mailing lists, forums, or chat rooms). Introduce yourself and express your interest in contributing.
Every article is broken into actionable items. Taking action everyday is key. Currently there are 10 items. My first PR for docs was merged yesterday. Two PRs were rejected. Rejection is part of the process.