 Thank you. So yeah, so I before I got involved in computers, I majored in French history taught at Berwick College for like seven years. So I took a bit of a historical perspective today. Looking back at kind of my first year of contributing to Knative, I'm a relative newcomer. I started in actually this is I think my first commit was May of 2021. I joined the Knative community and pretty much about a year later, almost exactly, I became an approver on serving. And so what I wanted to look at today is kind of some things that I found helpful in that first year getting started in Knative. And as Ana said, I'm also a member of the TOC and a working group lead on serving. So but we'll cover that part, I think in Amsterdam if we have a Knative con there. All right, so a phrase is a top 10 list, 10 things that I found helpful getting started in Knative and an open source. Number one, find a mentor. This isn't to be a Knative mentor, but someone who will help encourage you kind of as you get started in open source, someone that knows the value of it can kind of help keep you moving forward. For me, I've been trying to work in open source for a long time. I had a lot of fits and starts, but my mentor is a Martin Hickey from IBM who kind of really helped encourage me to contribute and keep going and kind of saw the value in it. So it was something that I personally found helpful was having somebody to kind of encourage me along the way. Number two, actually use the project. You know, we all kind of want to get our hands dirty in the code kind of very, very early on, but being able to use the project, know how the things work, build things, I think also was very, very helpful. I read the docs. They used to look like this a long time ago. Back when I joined, they don't look like that now, but you know, read the docs. Jacques Chester wrote a really great book called Knative in Action, which I think VMware still offers for free, but it's a really, really great kind of overview of kind of all the components, how they work together and a lot of other things. And then I build things. This is a little repo I have. It's just any time I read about something in Knative, want to learn how it works. I build a service, put it out there, apply it, getting your hands dirty, seeing how they work I think is a really, really good thing to do. Number three, clone the repos, build from source. If you're going to be contributing to something, you're going to do quite a lot. So it's good to kind of learn how to do that early. Fun fact, I found a bug in Apache Spark a couple of years ago, was trying to push the PR out. Couldn't get it to build locally, lost out on the commit because I didn't know how to do these kinds of things. So it's good to kind of do that kind of thing early. Here's me cloning the repos. I've got, there's a little script I've got that kind of I can one line, boom, deploy from source, just getting that kind of workflow up and early is a very, very useful tool to have. Documentation, number four, Knative can be a little complex. There's these duck types, there's throttlers and breakers, there's all these kinds of strong components in there that can be kind of difficult to figure out. What I've found, particularly when I'm getting my feet wet on a new project, working on documentation can be a nice kind of easy way into the project. It's a little bit, you know, lower stakes technically, but still has meaningful contributions, still is a worthwhile thing and still has people that want to help. And particularly kind of as a new user, you're learning things, you'll have a fresh perspective, which can be helpful here. It can be fixing links, it can be rewriting things, it can be noticing as something's out of date. All those are kind of wonderful ways to get contributions in, but again, it's kind of a little bit of a lower technical bar. Number five, attending working group meetings meet the leads. You know, we're a good community, there's a lot of nice people here. If you're want to start working on it, it's good for these people to know who you are so they can help you out, kind of encourage you along and help direct work your way as well. I had a link down here at the bottom, so when I joined the user with the kind of the leads, Carlos and Omer were the documentator, the Ducks documentation user experience working group. Very, very nice friendly people helped me, you know, get involved, kind of encouraged me, and were helpful to see new contributors. Same thing at the tops, the serving working group leads Dave, Jules and Marcus. Again, all good people, but going to the weekly meetings was helpful for them to get to know who I was, to help, you know, when there's work, you know, Paul might like to work on this, Paul's interested in working on this here, you know, here's something Paul, you could work on. So again, attending those meetings, I think, is a helpful thing. Volunteering, number six, you know, if there's something you want to work on, volunteer for it. When I first got started, my local development, I built on mini cube. And so I was setting up, you know, K native on mini cube, look to the documentation, hey, there's not an option to set up on mini cube in here. So I pushed a PR out, here's how you set up on mini cube. And it came back, actually, we don't want to include that in the documentation, because we don't want to keep at, you know, every single, you know, install option up there documented and supported. But one thing we're looking at doing is building a quick start plugin so that, you know, people can come in, hit a one liner and have an up and functioning local K native environment. And so kind of by volunteering a PR on mini cube, it turned into a stream of work, building this plugin that we still support. And I think like something like 50,000 people have downloaded over the course of however long it's been out there. So volunteering leads to good things. Review PRs. And I've got review and quotes here because as a new contributor, no one's expecting you to go out there and, you know, review every PR that comes in. But one thing that is nice about quote unquote reviewing PRs, what I mean by that is really just kind of look at them is that you'll see where the code is being changed, what impacts something else. You'll see the comments that reviewers are leaving on it. It helps get you involved in the code base in a way that's kind of low stakes. So here's an example, this is one where Marcus and Jules were kind of going back and forth on something, where they were changing readiness behavior. But kind of when I came in, you know, I would read every PR that came in, I would look at it, see what's being changed. It was a very, very helpful way to get up to date on the code base without having to do a lot of technical work myself. Something that I found super helpful. Certainly triage issues. And again, this is in air quotes, no one's asking you to become a project manager for Knative. But reviewing the PRs that come in seeing, Hey, if it's a bug, can I reproduce it? It's an issue. Can I reproduce it? Can I fix it? Do I know how this works if someone's having a problem with something? It's another kind of low stakes, kind of less technical way to help get involved in the project, but still show meaningful contribution. I think these are all things that kind of count along in terms like our reviewer and approver and such criteria as well. This is one Evan had found a bug in, I think in terms of our progress deadline, you know, you deploy a failing revision, it wasn't failing immediately. I'm back here, so I could reproduce it. Here's some things that I found and it led to a back and forth in there. So again, kind of helpful ways to get involved without necessarily having to write a thousand line PR. Number nine, pay attention to the bigger stack. Knative runs on top of Kubernetes, which runs on tops of container runtime. There's a lot of things that are happening. This is a very fast moving space. Kubernetes releases every four months. There's new things that come in. There's deprecations, paying attention. There's something you'd like to see in Knative, maybe opening it as an issue. For example, user namespaces is one that just came out in Kubernetes 125, which provides a nice, kind of a bit of a more of a secure sandbox around containers. It would be great if we could use that in Knative. So let's open an issue about that and see what we can do about that, or deprecations. Horizontal pod autoscaler was supposed to be deprecated in 125. I don't think they actually deprecated it yet, but again, another way that you can show involvement and engagement with the project without initially having to write a ton of technical code to get started with. The last one, have fun. It's open source. You get to contribute in the open. You get to build eminence. There's a lot of great things you get to do. I've had a great time doing it, and hopefully you'll come and have some fun with us as well. That's it. I think I'm a couple minutes early.