 Hi, everyone, welcome to my lightning talk, Picking up the Telescope, getting involved in the open telemetry community. So I'm Rachel Klein. I'm a software engineer at New Relic. Obviously, that picture is real old based on the length of my hair. It's way pre-pandemic. I'm new to the open telemetry community, super excited to be presenting for you today. Did I mention I'm really new? I just submitted my first couple of pull requests in the last few weeks new. Well, that is going to be my best asset today as I talk about my experiences, as a first-time contributor and what we can all learn from them. So who is this talk for? First and foremost, I'm really hoping that there are some people listening who want to get involved with open telemetry community, haven't done so yet, and they're wondering about how to get started. I'll be sharing about my own experiences. Obviously, your mileage may vary, but as a newcomer, I definitely benefited from other people talking about their entry points and how they got involved, and I would really like to pay that forward. Secondly, anyone who wants to encourage newcomers to the community to make the open telemetry project stronger is my intended audience, so hopefully everyone. Before we get into how I got involved, what are some reasons why people might not find it so easy to get involved? The first reason is that the world of open source is not always the most welcoming place. People from historically underrepresented groups in tech like myself can have complicated feelings about jumping in. I've got a couple of quotes here from Wikipedia about their entry on diversity in open source software, about some less than welcoming behavior that's been present in open source communities in the past. So just kind of that history does tend to give people pause sometimes about jumping in. However, the open telemetry community has acknowledged this, which I think is really important and shown a sincere desire to help everyone feel welcome. There are really no easy answers. You can't upfront plan how you're going to make your community a welcoming one, but just having that sincere acknowledgement of the issue and a sincere desire to address it is an essential first step. And I also wanted to say that once I took the plunge, my experiences in the community have been very positive, so I'm really grateful to everyone with whom I've interacted for being so gracious. The second reason why it might be a little bit difficult to get involved is because let's face it, open telemetry is complicated. I stole this diagram from a New Relic blog post and definitely the first time that I looked at it, I felt confused. It can be hard to know where to start and it can be easy to feel confused. I feel like that's important to acknowledge as well. However, the confusion that you feel as a first time contributor can actually be an asset to the community and we will get into that as we talk about my story. So without further ado, let's get into how I picked up the telescope, so to speak. Step zero for me was to get some good advice and this is what I hope this talk will be for some people. Many of my colleagues at New Relic have been involved with open telemetry for a while and kind of looking at their contributions, I was curious how they got started. They were very generous in sharing with me what their first steps looked like and that was very helpful to me. So here's some of the helpful tips that I heard. It's okay to start with something that feels small, like for example, a documentation PR. Asking questions in a PR review. Making grammatical and typo fixes. One of my colleagues shared with me that that's how he first got involved in spec work which was surprising to me based on the contributions that he's making now. If you're confused, probably others are too, bring it up. This goes back to the whole questions being an asset thing and that really did prove to be true for me. And the last piece of good advice I got was just start somewhere. So based on that advice, being a Rubyist myself, I took a look at the open issues in the open telemetry Ruby repo and I tried to just start somewhere. I figured I might choose a documentation PR to start because I heard that they are really appreciated by maintainers and it really helps cement my understanding of things to teach about them. And happily I saw that there were some marked good first issues in that repo so I decided to pick one and run with it. The one that I ended up going with, I don't wanna get too much into the technical weeds in this talk because it's not really the point but basically someone wanted to know there was some different kind of basic kinds of span processors as part of the tracing pipeline and they had run into an issue where they had used the wrong one for their environment and they thought that the documentation could use some more clarification on that point. So I took that as an opportunity to go learn more about span processors. Now I had already read the documentation, the specification rather, the whole tracing spec but it really helped to take this one piece and try to go really deep to learn about its place in the whole pipeline and the pieces, the other pieces of the architecture that touched it. So just looking at this smaller piece of the diagram which I stole from the specification as opposed to that whole giant diagram and trying to understand it at once. So I took a really close look at that section of the spec I read through the Ruby SDK implementation of it and I took a whole lot of notes to try to make sure that I understood every aspect of it. It wasn't long before I had a question. So the spec defines span processors as responsible for batching and conversion of spans to exportable representation and passing batches to exporters. So far so good, it looks like this diagram that appears in the spec. You've got your span processor and it passes things off to an exporter, okay. But then right after that in the spec it said each processor registered on Tracer Provider is the start of a pipeline that consists of a span processor and optional exporter. And so the question arose for me, if span processors job is to batch and transform spans for export, when would an exporter be optional? This turned out to be a good question. I went ahead and reached out to the community via Gitter just to get some initial clarification and I got some really fast responses. People were very friendly. And the first person who responded didn't actually know of any scenarios where an exporter would be optional but another person who responded in the thread did. And so both I and the original responder got to learn something. And I thought that was really neat that by bringing up my question I helped clarify things for myself and others. So armed with this knowledge I decided to go ahead and start a PR. I decided to tackle a few things that questioned about which span processors to use in which context. And I thought I would also clarify the scenarios kind of the definition of span processors and the scenarios in which they might be used without exporters. And while I was in the neighborhood I decided to make some minor grammatical fixes. And the discussion on this PR is ongoing. As of this filming, it hasn't been merged yet. It does have one official approval but it's been such an amazing way to learn even more. So a couple of fruitful aspects of the discussion so far people obviously brought up some more nuances to the things whose definitions I was trying to clarify. So I was able to make them even better with having comments from a wide variety of people throughout the community weighing in. And then also surprisingly to me those grammatical fixes that I made ended up being more useful than I thought even because since things that I didn't make substantial changes to meaning-wise but were just grammatical fixes were still part of my PR it caused people to take a second look at them it got people talking about them and we were able to make some needed changes clarifications there as well. And then finally I circled back and took what I had learned from that discussion on my specification PR and made a PR to the Ruby open telemetry implementation which did end up getting merged. So I feel really happy that I was able to help clarify things for users of Ruby open telemetry. So all of this was a relatively small investment of time and effort really not bad. I gained a better understanding of open telemetry architecture and I was also able to help other people understand it better as well and really got some good discussion started. I also gained a knowledge of processes and just how to submit things in the correct way and I made connections in the community. So the next time I wanna contribute something it will be even easier to jump in. So what are the takeaways here? Four new contributors being new actually is an advantage new eyes on the subject are really needed. Questions oftentimes they're good questions and they help clarify things that need to be clarified. Also choosing a topic and following your curiosity will take you far. It's a better approach in my opinion and trying to understand everything upfront. If you start with just one piece and see what is adjacent to it and kind of build out from there you'll learn a ton along the way. And finally I learned that the community is very welcoming to newcomers. I'm really happy to report for the community. Thank you for your acknowledgement of the fact that open source is not always a welcoming place. Please keep that up. Every interaction that you have especially with a new person is a chance to make things better in a small way for open sources as a whole. So like I said, I had a really great experience and I think that everyone should keep up the good work with being friendly and welcoming. And if you've got wisdom share about how you got involved with open telemetry please do share it with others. It really makes a difference. And over time every new person that's added to the contributor community makes the project stronger. So thank you so much for the opportunity to present today. Thank you for listening. Thanks to everyone for building a welcoming community. And I wanted to say a special thank you to these specific people who helped me as a new contributor. It provided feedback, advice and clarification. And happy open telemetry community day.