Cloud Native Computing Foundation OpenTelemetry Community Day North America 2020, 4 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: Picking Up the Telescope: Getting Involved in the OpenTelemetry Community

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Lightning Talk: Picking Up the Telescope: Getting Involved in the OpenTelemetry Community

Interested in contributing to the OpenTelemetry open source community, but don't know where to start? In this talk, Rachel will share what she learned on her journey to engaging with the OpenTelemetry community, from learning about the project to submitting PRs, as well as general tips for getting involved. Once you've taken your first step, your momentum will pick up quickly!"

A

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's real old based on the length of my hair, it's way pre-pandemic, um I'm new to the open, telemetry community super excited to be presenting for you today did I mention I'm like really new, like I just submitted my first couple of pull requests in the last few weeks new.

A

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.

A

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.

A

Obviously your mileage may vary, but, as a newcomer, I definitely benefited from other people talking about their entry point 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.

A

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 uh their their entry on diversity and open source software about some less than welcoming behavior.

A

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.

A

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's really no easy answers.

A

You know you can't up front plan how you're going to make your community a welcoming one, but just having that sincere acknowledgement and of the 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.

A

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 um 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.

A

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.

A

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 um 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.

A

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 um 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.

A

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.

A

So, based on that advice, now 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.

A

um I figured I might choose a documentation vr 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 want to get too much into the technical weeds in this talk, because it's not really the point, but basically someone wanted to know.

A

There are some 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 spam processors.

A

Now I had already read the documentation: the 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 uh 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 um 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 this stack.

A

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.

A

It wasn't long before I had a question, um 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 know, 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.

A

If spam processor's job is to batch and transform spans for export. When would an exporter be optional?

A

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.

A

So, armed with this knowledge, I decided to go ahead and start a pr. um I decided to tackle a few things. You know that that question about whether which span processors to use in which context- and I thought it 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.

A

Yet it does have one official approval, but it's been such an amazing way to learn even more so a couple, 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 um 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, um since things that I didn't make, you know, substantial changes to meaning wise um but were just grammatical fixes were still part of my pr.

A

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.

A

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.

A

So this all this was a relatively small investment of time and effort really not bad. um 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. You know just how to submit things in the correct way and I made connections in the community so the next time I want to contribute something it will be even easier to jump in.

A

So what are the takeaways here for 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.

A

Also, choosing a topic and, following your curiosity, will take you far. It's it's a better approach. In my opinion than trying to understand everything up front, 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. uh Thank you for your acknowledgment of the fact that open source is not always a welcome welcoming place. Please keep that up.

A

um Every interaction that you have, especially with a new person, is a chance to make things better in a small way for open source as a whole.

A

So, uh 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, to 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.

A

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 the specific people who helped me as a new contributor provided feedback advice and clarification and happy open, telemetry community day.