- First attempt to use and compile the project
- Figure out where the entry points are for the app. Generally this would be a 'main' function and any sort of event handlers. Frameworks complicate this a bit because they're responsible for calling code and do it in any number of arbitrary ways.
- Get a feel for the organization of modules/packages etc. Try to find the naming structure/patterns and how everything is laid out conceptually.
- Focus on a few features (just a random sampling) and grok how those work. Hopefully at this point there's some semblance or order in the project, so that if you understand how a few parts work, you can start to build a model in your mind how everything works, without trying to study everything in the codebase. And an architecture diagram from the project owners would help too, if an up-to-date one exists (doubtful).
- Make a very simple/trivial change, compile it and try to observe the result (that your change successfully compiled).
- Choose a bug or very small feature to work on.
- Success?
Edit: I just read the comment by 'fundamental' which I happened to basically restate with bullets. Anyhow, good luck. It took me about 2 years of full-time programming before I got comfortable reading large codebases.
For the larger codebases, generally you would want to get a vague idea of the architecture and then blind yourself to most of the complexity. Let's say that you wanted to work on a network based data serialization library and the issue marked out as 'contributor friendly' was adding unsigned integer support building off existing signed integer support. For that target, there's a large portion of the code that you shouldn't need to understand too deeply and there's a section that is going to be relevant to making the modification. Try to find the code that is relevant and trace the execution just by reading the code.
As long as you limit the scope of your work and the codebase is somewhat compartmentalized, you can shrink the time it takes to go through large projects by a fairly large amount.
Read the source code, and see if you can find any small wins such as optimizations or better api.