That talk specifically aims to show how doing bug triaging can be the best way to learn a specific OpenStack project and to get social interactions for free. Most of the time, people wanting to contribute to a specific OpenStack project come by the fact they want to implement a specific feature (if they're lucky and have that in mind) or just try to figure out which pieces to contribute. This is a very frustrating experience (mainly in big projects where the tech debt can be high).
On the other side, doing bug triage is not super fancy. But, when you do that, you have to dig into code to check whether it can be reproducable, you have to reach other people to give you more details on the specific involved codebase, and you have to test the bug by yourself.
All those steps make the perfect experience for someone who wants to embark on a project. After a couple of weeks, you gain visibility (because weekly meetings always focus on bugs), recognition (in particular if you decrease the backlog) et technical expertise (because you played so hard that you know all the quirks).
That happened to me on a big project (Nova) and I see that pattern often. I surely think it's nice to prove that to the community so we can somehow give more credits to the people who do the dirty work.
On the plus side, my talk is showing bits of Nova code for the purpose of that talk, which can be interesting for people wanting to know more on nova (in particular the services and some major features).