 Well, thank you. I guess it's time to get started. All right, so what we're going to be talking about today is a little bit personal for me. It's a very meaningful thing because not too long ago, I had a totally different career. I was in accounting. And one day I decided that, hey, you know what? I want to try something new. And I started getting into programming. And it was a really long journey, kind of scary. And what I want to do is I want to give the sort of talk that I wish I had when I was first starting out. And hopefully I can help encourage other people to get more comfortable and be able to put themselves out there and be able to get involved in the open source projects that they really want to get involved in. So who am I today? No longer in accounting. I'm Jamie Danielson. I'm a telemetry engineer at Honeycomb. And I work on open telemetry JavaScript. I'm going to prove her as of a few months ago. And so what we're mostly going to be talking about is my journey and getting here and practical ways that you can get started in your own journeys and be able to get more involved in another open source project, whether that's in open telemetry or another open source project that's important to you. A lot of these steps will be applicable to all these different projects. So one of the first most important things that you'll learn with open source is it's public. It's open. When you first start writing code, a lot of it is sort of hidden away for various reasons. First, you might just have your own little practice thing that you're doing. Maybe you're writing some code, you're going through a tutorial, you're doing whatever, and not many people are really seeing what you're doing. You mess up and it's just sort of your own thing. And then when you start coding maybe as a career, even within your company, it's still pretty hidden away, right? You might have internal systems. You might have some proprietary software or maybe an older language or you're getting into something new, but a lot of that maybe your engineers on your team are seeing and maybe your manager. It's still very small. And so one day it's going to be time, whatever the catalyst might be that you decide you now want to go to be more public with whatever you're working on. So one day for me, I decided to open a GitHub account. Now this may be regulatory for some and it may just be a refresher for others, but it's important to keep in mind that nobody is born knowing how to use Git. No one is born knowing how to use GitHub or Bitbucket or any other software, right? Anything that you have to learn, you have to start somewhere and there's really no difference in any of that. And it seems obvious sometimes, but it's important to really take that to heart and know that everyone has to start somewhere. And even when you do know it, especially Git as anyone who uses Git regularly will tell you there's still a lot that you don't know and there's a lot that's still confusing. So when it comes to learning anything, a lot of it's really gonna be the same whether this is public or not, but you learn by doing. You can watch videos, you can watch tutorials, you can read books, you can listen to talks by people like me, but getting your hands dirty and really getting in the code is how you learn and how you grow. And so you wanna start with practicing small things. A lot of times people think, okay, I wrote this code, I did this once, I got this. I know it, what's next? What's the next step? But the thing is it takes a while for that to really sink in and be something that you're comfortable with. So what you wanna do is you wanna really build up that muscle memory. Repetition is key here. It's not going to feel natural to start. As we just talked about with Git before, it will still feel unnatural years later. But some things will get easier as you go. Continuing to run a lot of the same commands, doing a lot of the small little things over and over again, gets a little bit easier each time you do it. And after a while, you might realize you start memorizing some of those commands. And that's kind of a nice feeling where now you're starting to build up some confidence. You're gonna keep building this confidence over time because you're going through the same things over and over. And the things that you realize, one day you'll wake up and say, this was really foreign to me when I first started, but I kinda understand what I'm doing now. We're still small. We're still starting on a small scale and that's okay because again, we're starting somewhere and we're building up over time. So for me, I started with a private repo on GitHub. I think you have as many as you want today, but that was back when you had maybe one or two and then you had to pay and I wasn't ready for that. So I started with a private repo and said, okay, ready to go public now. I don't wanna spend any money, so let's try this public thing. And so what I did, again with starting with those small little steps is I opened this public repo, which was a blog using GitHub pages with Jekyll. Now some people may have seen this before. This is a pretty common way I think to get started with GitHub. But what I really wanted to do was I wanted to go through those steps of what I knew was gonna be necessary when I decided to do programming for a living. And so what I mean by that is what you can see is, this is a PR to my own repo. No one else is gonna approve it, but I wanted to go through the steps. So I had these commits for each and every little thing that I did. I had these commits that explained what I was doing in here and I had a PR that I could then go approve and feel really good about that. So I got into the flow. This was building up that muscle memory, building up that repetition, getting comfortable. So the next step was forking another repo to make it my own. I saw that it had done all the work for me of all these nice styles, all this build up for these blog posts. It seemed like a really great idea. So I thought that would be really cool. So I saw this PR, I forked it, I did what I had just been doing, making these changes, opening a PR, feeling really good about what I had done. And then I realized I actually opened the PR against that repo instead of my own. This was mortifying to me. In fact, even looking this up brought up all the feels and really I felt a lot of shame. Like I felt like I needed the dog cone of shame as I went through this. And I thought, this is it. My career is over. It hasn't even started yet. And I'm so embarrassed. I'll be laughed out of programming forever. Like what happened? But do you know what actually happened? Absolutely nothing. No one cared. No one commented. There's no thumbs down on there. As you can see, I just wrote open to an error there, but there was a lot of panic behind that. But now this is an archived repo. No one's ever seen it again. No one, no one cares. And the thing is, as I've realized now, people do this all the time. You don't get put on a no hire list that I'm aware of. I am currently employing. Thank you, Panico. But I got through it. And this happens to everyone all the time and so the thing to keep in mind is you're going to be wrong a lot. And that's okay. When you're working the open, you're being vulnerable. And being vulnerable is really hard. Standing up right here right now is really hard. But each time that you do it, you get just a little bit better at doing it. And when it comes to the internet, well, internet is kind of around forever. It's hard to get away from that. But the only way to get better and the only way to get from point A to point B is to keep going. And point B is to face that vulnerability and be uncomfortable and just keep moving forward. So now let's go to the point where you're ready to do something on purpose, to someone else's repo. So we're going past the shame. We're going past the whips, all of that. And now we're ready to look at a new repo. Maybe this is an open telemetry repo, another open source repo. The thing that most of these repos will have in common is that they're going to have some kind of contributing docs. And we're going to talk about each of these individual docs. What you're going to see is a readme is going to be very common, contributing docs, issue and PR templates, and then things like discussions, wikis, pinned issues, things like that. So this is a screenshot, or a couple of screenshots, I guess, from open telemetry JavaScript. And what you'll see in a lot of these, again, is a readme that's very common when you first go to a new project. And it's going to talk about how to work with the project. And in fact, from the readme, there's a link to the contributing guide itself, which has a lot more detail. How to, you know, what you need to install to get this running, how to run these tests, how to lint things, go through these to help set up your development environment so that you're more comfortable working with the repo or the project that you're looking at. And one thing to keep in mind, a tip for later on in this presentation, is that as you're going through this process, write down anything that feels a little weird, anything that isn't super clear, because the best person to actually update the contributing guide is the person who's first learning how to contribute to that guide. So write those things down and be prepared to contribute that later. A lot of repos are also going to have these things called issue templates. If you haven't seen them before, they're kind of neat, where you want to open an issue of some kind. So there's these different templates depending on what your issue is about. So you might have something like, in this case, we have a feature request here. So the idea is I've maybe used this repo before, but I have something that I'm seeing isn't actually available there, and I'd like to have this get added in. The idea of these individual questions that are on there, is both to help guide you in what kind of information might be useful to have in this issue, and it's also helpful for the maintainer of the project to understand what your use case is, what you're going for, and any alternatives in this, which is helpful because maybe you've seen this particular feature somewhere else, and maybe you have some ideas of how that can be implemented here. So in this report, the biggest thing I can say is having a reproducible example of what has gone wrong is the fastest way to get that bug fixed. The reason for that is, especially some of these repos are really huge, and so it can be hard to understand exactly what steps you took, what version you're on, how to get to that state of getting to that bug, because once you find where in that code something is wrong, it's a lot easier to narrow it down and get a fix. So if you're finding the bug, having that reproducible example and having details around it, you might even get some ideas on how to fix it, and a maintainer might even want to help you move forward in getting a PR to be able to fix that bug. A PR template is something that happens when you go to actually open that PR on a repo, and again, it's there to guide you on what's useful to include in a PR, including what issue is being resolved. This is really valuable because it's a bug report and it's a bug that you're trying to fix, or it's a feature that you're trying to implement. You've already had all the conversation on the issue, you've already gone through and discussed with other people on the project of maybe what's missing or what needs to happen. So by the time you get to the PR, this is just an implementation detail. This is just, here's how I am solving this particular issue, and here's how I've done it. Now you've already gotten over, what that particular thing is, you're just trying to get through the details of how to make that actual change. So one thing I want to point out that's really important, and a lot of people don't think about it, is that non-code contributions are incredibly valuable for open source. A big part of that is going to be public documentation. It's a very common way to get started. Think about when you first went to a new project, whether it was open source or even if it wasn't. You went to documentation. You don't know how to use this thing. And if there's no documentation, you don't know how to use it. So the software is relying on documentation for people to use it, and you being newer to the project are going to be really helpful in writing down the documentation that helped you get to the next point of using it. This is from an article that I saw that said that developers see about a 50% productivity boost when the documentation is reliable and up to date. So if you think about how good the software is or how valuable, think about that number, and think about it doesn't matter how good the software is if nobody knows how to use it. So making sure that there's documentation there for people to know how to use it is incredibly valuable. The next thing is examples. Some repos will have some examples and some will be a little sparse. Some might be a little bit older or not as maintained. But I think that's a good example. So I'm going to talk about how to use the different features of the project and it might even be used for different kinds of testing, or when we talked about bug reports, having a reproducible example can say, I used the example in your example repo when it broke. You have this very contained piece of where something has gone wrong, but it's also helping you get more familiar with the project itself and helping others who might be having problems with the project. There's a thing that people talk about where if you really want to learn how to do something, you write about it. If you really want to learn how to do something, you teach someone else about it. So if you come across something, maybe you're looking up on Google, you're trying to find in the documentation you don't know how to do something by the time that you do end up figuring it out. If you can write a blog post about it, maybe add an example about it. You're helping other people understand yourself and you're really solidifying your knowledge of that project. Opening bug reports might seem unintuitive of how am I helping here? I'm just saying that there's a problem. But the thing is, if something's not working, the maintainers might have no idea whatsoever. Because when you're working on code, you're not always looking at it as an end user, and you're kind of head down in the code, so you need someone to come in and say that something isn't working. And that's really helpful to know. And again, we have the issue template of filing a bug, how do I reproduce the bug, and again, you might get tips on how to fix that yourself. And finally, being involved in the community for a project is good. We'll talk a little bit more about how to get involved in different communities like the open telemetry community, but that's going to be helpful in just having another voice in there and making more awareness of the project that you're trying to work in. So now that you're working in this project, whether you are working on a PR it's important to keep in mind that we're all human beings and we really want to minimize situations of confusion when we can because we're all coming from different backgrounds, different levels of experience, and different expectations of different things. So I really love this graphic. I'm not sure if you can read it from out there, but it's about switching seats with 14A. And what may have seemed really clear to this attendant about saying to switch seats clearly wasn't as clear to the person as you were in moving it somewhere else. And so what ends up being really obvious to one person could be perceived completely differently by someone else. So that's just a way of saying don't make assumptions about what other people understand or whether or not what you're saying is coming out as clearly as you think. It's good to think about where other people are coming from and if there's a way that you can be as clear as possible, then you want to do it. There's this saying of make the implicit explicit, which means that, again, it might seem implied, it might seem obvious, whatever it might be, but you're better off saying it and maybe even saying it again. And it might seem like you're being repetitive, but if anyone's ever heard of Rule 7, it's usually used in, like, marketing. But the idea is that someone needs to hear a message seven times in order to act on it in order for it to really stick. So the same can still be true when it comes to different kinds of communication is you might just have to say it again and say it more clearly and just make sure that you're both understanding the same thing. And if you're ever unsure in a conversation that you're having with someone, ask the question. Not only are you unsure, there might be other people who are seeing this back and forth or maybe also involved, but they have the same question as you do. Maybe they're not speaking up or they're really thankful that you're actually asking, but there's no clarity for everyone who's involved in that conversation. The simple misunderstandings can really happen for anyone and think about even something like auto-correct. How many times you've written now when it came out as not or something like that and it completely changes the meaning of whatever it is that you're talking about. So you're better off asking to make sure it's clear. There was this really awesome back and forth that I saw. This is the open telemetry documentation repo and there was an issue open at one point and someone came in and opened a PR to make these changes. At some point, it got a little bit quiet and so the first thing you're seeing there is a maintainer saying, hey, I'm just checking in. I want to see if there's anything that you need for me in this repo and I love that. They're being proactive. They're asking, what do you need to help this get through? We want to help move it forward. And then the person who contributed this thanked them and admitted, I'm actually curious. I don't know what the next step is. And later on in the thread, they said, you know what, I'm actually new to GitHub. I don't really know how this process works and I'm unsure of how to move forward in this. And so they went back and forth and the maintainer, I don't have all the back and forth. It was a long conversation, but they were very clear about, you know, here was a suggestion that was made. You can click this button that says commit the suggestion. If you're not sure about what this person said, why don't you respond to them here in this thread? And there was this back and forth and by the time this went through, this PR was approved. They went through all the suggestions, all of that. The contributor thanked the maintainer so much for helping get them through it. And the maintainer now was able to help someone make their first contribution and they were excited. They said they can't wait to do another one. And so I want to applaud the maintainer on here and just in general point out how valuable this back and forth was for, I think, everyone involved and something to keep in mind as maintainers, if you've ever maintained an open source project, to help folks who are trying to work on your project, and both of you can move forward in a better way and help them out when they're not so sure. So now we've gotten to where we're contributing. Maybe we're ready to open those issues or ready to open those PRs. We want to be more involved. And it's really important to point out this important fact of you need to keep showing up. So when we want to be involved in a project, we need to have a lot to it and really consider consistency as being maybe one of the most important things. Some people think that if I want to get involved in this project, I need to make this big fancy new feature. I need to make a splash. I need to make a name for myself. But really what's more impactful is having those small, consistent interactions with the project, with the people, with the community that's going to make a difference. So if I want to be consistent showing up, I'll have a link in my resources is related to, for example, their special interest group meetings or SIG meetings that happen roughly weekly for different languages. And so there should be a link for a calendar where you can attend those. Those are totally open for anyone who's interested. And keep in mind that every interaction that you have with people is building trust. So what happens over time is you go from, here's a new person who's showing up and saying, oh, here's the same person I just talked to last week. Oh, I saw them comment on another issue over there. So over time, people start to know you and you start to know them and you become teammates. Even though you might be on other sides of the world, you might work at different companies. You're now teammates on this project together. So it is who you know when you're trying to get an issue resolved or you're trying to get a PR in, but it's not quite what you think. Again, the idea is that over time we're building up this credibility and you're more likely to gain traction on issues in PRs. If you're known in the community and you're known that you're going to keep showing up, you're going to keep coming to these meetings, you're going to keep working on this repo and, you know, people understand that you know where you're coming from and what you're trying to help with. Because even if a feature that you want to add seems really great or a code chain seems really useful, in reality, every bit of code that you add is going to add overhead to the project. In fact, adding more code might be such a small percentage of what goes into adding something new to a project because you have to think about how that code now interacts with the rest of the code. If you add a new feature here, we have to now keep that in mind for all the other tests or all the other features. Does something break something else? So it's important to keep that in mind. And with that, there's this saying, I don't know if anyone's ever heard it, which is free is in puppy, not free is in beer. If you give someone a beer, they can just enjoy it. Thank you. I appreciate that one-time gift. You move on. But if you give someone a puppy, there's a lot more to it. You have to feed the puppy. You have to play with the puppy. You take care of the puppy. And so when it comes down to it, the other maintainers on the project want to know that you're also committed to helping take care of that puppy because they don't know if they can take on another one. So that's why it's important to just keep showing up. And so, again, I know a lot of this is focused on open telemetry, but really it's going to be very similar with other open source communities. The contributions to repos, again, whether those are, whoa, issues and things. Special interest group meetings, SIG meetings, which again are totally open to anyone who's interested in going. Just so you know, it's kind of like you show up at this assigned time in a Zoom meeting. You don't need to turn your video on. You can just hang out, see what people are talking about. Sometimes there's an agenda with just some topics. Sometimes it's bug triage, but anyone is welcome to go to those. There's a community Slack for open telemetry. It's specifically the CNCF Slack. There's hotel channels and open telemetry channels that you can look for in social media. I guess right now it might be mostly LinkedIn, maybe a little bit of Twitter or X or Macedon, but you might find some people to talk to there as well. So just as a recap of everything we just talked about, it's really going to start with learning in public and gaining confidence each step of the way, being vulnerable, putting yourself out there, and being able to keep moving forward even if you mess up, which you will. Again, that's okay. When you do start getting involved, make sure to read the contributing docs. That's going to help you understand how you can interact with the project and it's going to help the maintainers understand what your questions are and really keep in mind that non-code contributions are really valuable. There are a lot of people who really start to understand a project through adding that documentation and over time become maintainers even of the actual code because they've become an expert in that documentation. But you can also stay in the documentation as well because again, without the documentation that project is not going to exist long term. When you're communicating with other people be as clear as possible. Avoid misunderstandings. Avoid making any assumptions and if you're unsure about any back and forth that you're having, just be sure to ask the question. And finally, just keep showing up. Consistency is key and that's how over time you do get to the point of being an approver. Like in this case that I was for the Open Telemetry JavaScript project this took a while to get here and a lot of it was just consistency and continually showing up. So by doing that, you get to a point of you're just starting out to getting more comfortable to building up that credibility and building up trust with other people in the community and then ultimately being around and having more work to do honestly but it's a journey and I would say that it's worth going through. So thank you for coming. I don't know if anyone has any questions. I think we have a few minutes. I think there's a mic right over there if you don't mind hopping on there. Hello. Hi. Thanks a lot for the talk and encouraging people to contribute. How do you reconcile that with the expectations of a manager, for example, because you say if you show up more time for more computerizing or you maintain inside an organization do you have any tips on getting the message across if you want to contribute? So you're asking, I think specifically how to get more how to get more involved from your company like how to get your company interested in having you more involved is that the question? Sort of. I mean you can obviously do it in your free time but you might as well take some of your work time to contribute to projects that the company might benefit from and can you share any other conversations you've had in that direction? I guess it's tricky but it might depend on the project itself I also look at it in a way of like depending on what the project is there are different ways of getting involved. For open telemetry specifically like one thing that Honeycomb is is it's an observability platform where people can send their telemetry to Honeycomb so it's obviously very much in our interest to make sure that open telemetry is successful and it's really important and so I understand that that's a condition that I get to be in but there are of these other ways of talking with other people are finding a way that it's specific it can specifically benefit your company so if you're doing observability in any way sometimes it's a matter of pointing out issues that maybe would help your company get something working better I also think again depending on the specific thing I almost think of like with volunteering like some people are able to volunteer time and some people are able to volunteer money and so there are some open source projects that are run by just individuals who are doing this maybe in their free time or maybe that's a big thing for them and sometimes they'll have things for sponsors and things like that but I don't know if I have specific feedback on a company involvement in open source projects I just wanted to ask you in regards to the special interest groups I think as far as I know I think with open source projects in general if you have any recommendations for how to choose a special interest group in general but also for open talent perhaps Sure, yeah so what's interesting is I think the first special interest group meeting or SIG meeting that I went to was for the collector and that was really interesting because I was kind of first dipping my toes into the community and understanding how these things worked and I went to those meetings I don't know every week for maybe a few months and then at the time I realized well I'm working a little bit more on the programming languages themselves so I'm going to try JavaScript in this particular case I chose JavaScript because that was a language I was more familiar with and more comfortable with and I spent more time in there but I've also spent time going to the Python SIG meetings or going to the Go SIG meetings I think it's sort of like asking what language should you start out with when you're first learning to code which is to say that there's not a perfect answer one size fits all it's a combination of what's interesting to you and what kind of what clicks for you kind of finding your spot in the community and going to the different meetings and just get a feel for how those things go again it's very open you have a calendar there's an open telemetry public calendar and you can go to any of those meetings and just kind of say hey is this the kind of stuff that I enjoy working on or am I maybe interested in looking at another language the one thing I can say too being here is there's a lot of people that I've met in person here that I've interacted with on other open telemetry projects so I think it's just a matter of seeing what kind of speaks to you when you go in that room thank you we're all set thank you again everyone I appreciate it thanks thanks thanks thanks thanks thanks thanks