I also recommend to read through other resources dedicated for students,
especially this one from Google , one from a former student 
as well as advice from Boost GSoC former student Louis Dionne .
Once you get through the general GSoC materials, it's a good idea to start
browsing Boost resources, from intro  through netiquette  to wiki .
On  and  you will find links to past and current project ideas
for Boost libraries. Browse it, read it, and learn what kind of projects
Boost community develops during GSoC. Start thinking about what interests
you, which Boost library, which project, what you'd like to develop as
Meanwhile, it's a good idea to "Make First Contact" .
Subscribe to the boost (developers) and boost-user or
library-specific mailing list at https://lists.boost.org join Boost channels on Slack at https://cppalliance.org/slack/ and start discussing your participation, project ideas, etc.
Although the student guides  use the phrase about
"communicating directly with potential mentors",
it does NOT mean exchanging private e-mails with mentors asking
"Are you interested to mentor me?". GSoC does not work this way.
In my opinion, the word "directly" means to interact directly with
the community where, obviously, potential mentors are members too.
The Boost organization and mentors will have chance to select students
and projects they wish to mentor during the selection process
- a secret, you can learn about it from GSoC guides for mentors .
Yes, the selection is a competitive process.
Next, start discussing project of your interest, start asking questions,
investigate ways to contribute to Boost, start working on competency tests
Mind you, competency test is Boost way to verify minimum necessary skills.
I personally think Boost should also ask for a bug fix  explains:
"Some organizations make it a must for you to fix a bug in their
code base before submitting a proposal but some do not.
Your chances are always high if you can fix a bug in the code."
Submitting a pull request with a small feature is also a good idea,
something to discuss with mentors/maintainers of library of your interest
Pull requests will allow you to gain hands-on experience with workflow of
peer reviews, continuous communication, addressing problems, testing your
solution, using the infrastructure, being exposed to stress of 'annoying'
requests from maintainers to fix this, tweak that... :-)
For example, it worked well for Boost.GIL (you can PRs at
"you have to go early even if you go to hell" 
GSoC IS hard work!
Make sure to start early, to take a proactive stance, to do your homework
before you start asking questions, to expect no babysitting.
Imagine the GSoC runs back in times when there is no StackOverflow,
no web archives, no web search,...
There really is no excuse for not searching the web first nowadays.
Even compilers can do that! https://arxiv.org/abs/1906.11456
"To grow in life, be willing to suffer" ~David Goggins