Drupal has a fantastic community of hard-working individuals, many of whom do not see remuneration for their efforts to keep Drupal moving forward. It can be truly rewarding to contribute to large projects like this, knowing that the work you do is improving the lives of many developers and clients the world over.
There are a couple of misconceptions that I would like to dispel before we get into the nitty gritty of what is involved with contributing. Many people see core contributors as hardcore developers or people with an extremely in-depth knowledge of the framework itself. While there are a couple people who can boast this ability, most of the people currently contributing to the project are people who have specific skills that they can bring to the table to forward areas of the project. You really don't even need to be a developer or know anything about PHP at all. There is a great article on Drupal.org on how you can use whatever skill set you have to contribute.
Setting up for contributions
There are a number of things you will need to begin contributions. If you are attending a sprint for core contributions, you can increase your efficiency at the sprint by completing (or at least considering) some of these steps ahead of time.
This first thing you need to get setup for Drupal core contributions is the command line tool, Git. Github has some nice documentation. There are also some nice GUI interfaces for Git, like Source Tree, if you would prefer that.
If you plan on doing development patches, you will also need to install a local server stack. If you use your machine for local development regularly you may already have this setup. The basic requirement is the ability to setup virtual hosts to serve your Drupal environments. You will need at least 1 host, but some people use 2 or 3 depending on what they are doing. If you are like me and your System Administration skills are a bit lacking, you may opt to use an encapsulated solution like MAMP, which works for both Mac or Windows. If you are going with the 2 virtual host setup, one will be for Drupal Development, and one will be a clean Drupal installation for testing the application of patches, so feel free to name your hosts accordingly.
You will make your life easier if you have drush (a command-line utility for Drupal) installed as well, but if you have never used it or are not comfortable using your Terminal, it may not be necessary. If you do decide to install and use it, please ensure you are using the proper version. Please note for Drupal 8 development, you will need version 8.0 of Drush as well.
Next, you will need to clone an instance of Drupal. At the time of writing this, Drupal 8 is the main target of most contributors, so I will be providing instructions based on the assumption that you will be working with this version. In a terminal window, navigate to the folder of your Development virtual host folders and type the command:
git clone --recursive --branch 8.0.x http://git.drupal.org/project/drupal.git
If this is successful (and it could take a couple minutes depending on your connection and machine), you will have a Drupal 8 instance ready for installing. Optionally, if you have a "clean" virtual host setup, you could also repeat this process for that vhost directory.
You can now install all of your codebases and you are off to the races!
The Issue Queue
As a contributor, you will get to know the Drupal.org Issue Queue very well. It is the page you will visit when you are ready to start getting your hands dirty and contributing. There is a search form at the top of the page which will help you really hone it on the area you with which you would like to contribute. If you are a new contributor, I would suggest that you first filter by tasks marked as novice. Select Novice from the Issue tags field and hit Apply. This gives you a subset of all tasks marked as suitable for novice contributors. Even if you consider yourself a senior or advanced Drupal developer, I would suggest you do one of these to get a feel for the workflow of Drupal Core.
Submitting patches
Some developers may be used to and prefer a pull request-merge workflow, but Drupal Core works strictly on a patch submission workflow. The basic workflow is you make a change, submit a patch and then get it reviewed by the community. Following that, a core committer will come across your patch and get it committed to Core. Sometimes, if too much time has passed without committing, and other breaking changes have been made, your task/issue will be flagged for reroll. In this case, it is a fairly simple fix to rebase your patch. You can get more explicit instructions on how to reroll a patch here.
Core mentoring
There a number of avenues that you can pursue to get help with your contributions or any questions you have. I am big believer in finding someone local who can meet up with in person over a coffee or beer to go over your (code-related) problems. They may even be willing to walk you through your first patch, end to end (though that might cost you TWO beers).
Some regions have periodically scheduled sprints that I highly recommend you take part in whenever possible. In my local community, we schedule designated weekends for sprints focused on Core contributions and it can be awesome to level up your skills.
Alternatively if you find yourself in an area without a Drupal community to speak of, start one! This would likely require some of your spare time to organize and facilitate, but financial resources often materialize once someone shows the initiative to begin organizing. There are grants you can apply for from the Drupal Foundation and you can often enlist local Drupal shops for sponsorship as well.
Finally, there are Office Hours, which are attended by Drupal mentors. This is usually facilitated on IRC, but other arrangements might be possible depending on your needs. You can see more information about office hours on Drupal.org. In this same vein, there are usually many people to reach out to on IRC. This is a great way to get quick answers to very specific questions or at least get pointed in the right direction.
Have fun!
That's pretty much all there is to it. I've made it a personal goal of mine to expose the reality of how easy it is to contribute to even a big project like Drupal. I am far from a Drupal expert, or even an expert on contributions in general, but I have spent enough time in the Issue Queue to learn enough to make a difference. The main thing to keep in mind is to have patience with yourself and the community. Sometimes patches take awhile to get committed into the project. This can be frustrating if you've spent a bunch of your personal time on a patch, only for it to get "ignored" by the project team members. One thing to keep in mind that many of these core committers are also spending their personal time on this, and they have a 9-5 just like you.
I have one last thought on the topic. Developers have a tendency to burn themselves out. This is driven by passion and a love of the job for the most part, but it can be quite destructive for individuals and communities, in general. Don't try to take too much on at once, but rather, spread out your contributions. A small, but frequent contributor is worth way more than someone who makes a big contribution, but they then burns out and leaves the community entirely.
Contributing to a big project like Drupal can be quite rewarding because you are contributing to a project greater than yourself, your team, or even your city. You are actually affecting global change on some level. From the smallest documentation spelling correction, to fixing a broken feature, everything makes a big difference and I invite everyone to take the plunge into core contributions, no matter how scary it may seem at first!