[00:00:00] Chapter 1: Introductions and Episode Focus
Kasper Borg Nissen: Hello and welcome to Code RED. I'm excited to be joining you as one of our new hosts. Now don't worry, Mirko will still be hosting as well. We're just bringing more voices into the mix to explore some new topics on Code RED. As I take the mic, I want to dive a bit deeper into the technical side and to highlight the community aspects of observability. Today, we are going to start by talking about how you can contribute to OpenTelemetry, both from a technical side but also from a community perspective. Our guest is Marylia Gutierrez, a principal software engineer at Grafana Labs and OpenTelemetry maintainer and a member of the Otel Governance committee. She's going to help us break down how to get started contributing, why contributions beyond code are so valuable, and how you can become part of this vibrant community. Marylia, thank you so much for joining us.
Marylia Gutierrez: Thank you. Thank you for the invite. Happy to be here.
[00:00:53] Chapter 2: A “Code RED” Panic Story and Lessons on Backups
Kasper Borg Nissen: Let's kick things off with our traditional question. What has been your biggest Code RED moment, whether in open source or in your engineering career in general.
Marylia Gutierrez: So I was thinking about this question because one different thing about my job is that I was always working, like a lot in observability, so I was always the one helping people with their Code RED situation. But there was one moment that I can think of, I think of this as more like a panic mode, like, oh my God, how do I do this? So at a prior job, I was basically responsible for like it was an internal project that we had information about, like our usage of how customers were using a database. But the way we were able to send information was using an API like framework. They could only send it to Postgres. So Postgres, it was not the database that I wanted to save. So I had like a script that would then pass it on to a DB2 database. That one worked like no problem. But the thing is, because we have our own lab, our own servers, I had the DB2 running on one of the servers that we had on our lab. I was like making updates on that server, and I like updating some of the scripts. And then I had to just delete one folder that had two files on it, like a easy thing and okay, delete it. And I noticed that it was taking way too long to delete like two text files. I was like, oh no, what have I done? And I did the equivalent of like delete like dots on the root folder. So that means that I deleted not like the contents of the database. I deleted the database, I deleted the backups. I deleted all the.
Kasper Borg Nissen: Everything.
Marylia Gutierrez: I deleted the machine pretty much as soon as I know. Like I try to stop. I had a couple things that did not get deleted, but at that point it was all corrupt. I was like, oh no, I just lost everything. I was like, okay, wait, I had the Postgres database still and that one I was running like some backups on that one. So I was like, okay, I'm just going to go back to that one and send everything again. So I went to get the backups. Every single one was corrupt, every single one, because we had like terabytes of data and everything. I was like, yep, that's it. I'm just gonna pack my things for everyone. And because I was like, okay, the last like, Hail Mary, I went to the, basically the tool that we were using to send like the API. And I was like, okay, I know that they were sending the data. I was like, any chance you store any of this data? And they're like, yes, we do. For a little while I was like, that vow is enough for me. So what they did was pretty much they pretended they just received the data and they sent all of the data, the data back over again. It's like a week to send all the data again because it was a lot of data, but that was my. Oh, but.
Kasper Borg Nissen: You managed to get back.
Marylia Gutierrez: Yes, but it was from a segment which is like the API framework that we were using. So. But yes.
Kasper Borg Nissen: So, so by chance you actually had a backup of your backup.
Marylia Gutierrez: Yeah.
Kasper Borg Nissen: So I guess it's always good to have additional backups in this case or additional systems where you can take a backup. Yeah. Just just for those cases where things just go everywhere.
Marylia Gutierrez: Like in just in case. Have the paper backup as well.
[00:04:33] Chapter 3: Marylia’s Role and Involvement in OpenTelemetry
Kasper Borg Nissen: Yeah. Awesome. So before we dive a little bit deeper into the topic, could you introduce yourself to our listeners, maybe tell us a little bit about your role at Grafana Labs and what OpenTelemetry is.
Marylia Gutierrez: Yeah. So my name is Marylia. So I've been working on observability for many years now at Grafana. So the team that I'm there is called the OpenTelemetry SDK. So my job is to be a developer for OpenTelemetry, which is something that is pretty cool. My day to day job is just like working upstream. Oh yeah. So it's like all upstream, all in the community. And that gives me the opportunity to work on several areas of Otel, not just SDK. It's just because I keep finding things that interest me and I keep adding to myself and like to contribute. This is why I am like a maintainer of contributor experience Portuguese localization. I am an approver of the JavaScript SDK communications database semantic conventions. And just recently also a part of the governance committee as well.
Kasper Borg Nissen: So a lot of hats. That's nice. So a few months ago, you published a blog post called How to Contribute to OpenTelemetry on the OpenTelemetry.io blog. What inspired you to write that guide, and what do you think is sort of the biggest misconception people have about contributing to a project like OpenTelemetry?
[00:06:01] Chapter 4: Why a Guide to Contributing and the Biggest Misconception
Marylia Gutierrez: Yeah. So that came to be because I was very commonly getting just messages like, I want to contribute, how do I do it? So it was a lot of just like, oh, help me, I'm here, just tell me what to do. And I would do it. As I mentioned, one of the things that I'm part is the contributor experience. So are people that wanted to be a contributor of OpenTelemetry, not a user of OpenTelemetry. And that one is okay. So we are starting to see what the challenges that people are having. So we want to improve that. So I kind of gathered the information like questions that people keep asking and also the feedback that we were getting on that SIG. I was like, let me try to do something that might help out people and have a little more concrete ideas for people. Well, yeah. The misconception, I would say it is the, the part of I think I even like, started this on the blog that a lot of people don't have experience with open source, so they would assume that, oh, I'm going to get there and people would asSIGn me things to do. People will just tell me, like, okay, I need you to do this by this date. It's like it's not a regular job that you have with your manager or your tech lead telling you like, this is your task. No, you have to be owning your own journey there.
Kasper Borg Nissen: Yeah. I think you actually mentioned this. Like, your contributors are like the architects of their own journey. I think that's what you write in the blog post, right? Yes. And I think that's a very, very good, good way of framing it compared to what you. Yeah. What many as you mentioned are usually used to is getting some tasks assigned. Then they do them in open source. That's just not the case.
Marylia Gutierrez: Yes. Because we never know how much time you have on your hands. So there are people that might be doing this in their free time or as a hobby, or there are people like me that are full time. So I know that someone like me would have the time to do all the things, but I cannot just. You come and I know exactly how much time you have. What is your experience? What do you like to do? I have no idea. So it's up to you to tell us, like, oh, I'm working on this thing or that thing.
Kasper Borg Nissen: So can you put like some, some kind of like a mindset on, on the approach you think is essential for someone that needs to or wants to contribute to open source? And especially OpenTelemetry.
[00:08:15] Chapter 5: Getting Started: Mindset, SIGs, and Finding Your Area
Marylia Gutierrez: Yeah. So I would say when you are joining you have to find the things that interest you. So that could be several different models that you have. So for example, might be like, oh, the company that I work for needs this feature or like my project is using this already, but there is a bug that I need to fix. So you must have a reason to come. Or that reason could be just I want to get more experience on this area. I want to increase my network. So you are going to go and find the areas that interest or because you already have a lot of experience or because you don't have any and you wanna learn. So you would come and I was really suggest joining the SIG. So to explain what is the SIG. So six stands for special interest group. So is almost a 1 to 1 SIG per repo. It's not exactly but it's an easy way to think about it. So each repo for each of the component languages has this special group that people are getting together to discuss the things that we're working on. So this is a way, if you have no idea, there is a calendar, official Otel calendar that you can see when all those calls are happening. So you can join and just listen in. You don't have to do anything, speak or anything. So you just listen and have an idea of like, oh, this is the type of thing that is happening here. And you're like I don't like this one. Just leave. Go to.
Kasper Borg Nissen: Another one.
Marylia Gutierrez: Yes.
Kasper Borg Nissen: I think that that's a really good message to sort of said that it's okay to just, you know, join a meeting. You don't have to like jump on on and be part of the discussion. You can just listen in and yeah, if it's not for you, find a different place to contribute. There's many places where you can provide some insights and contribute with your experience.
[00:10:04] Chapter 6: Projects, Subprojects, and Technical Committee Alignment
Marylia Gutierrez: Nobody would get offended if you just show up to one meeting and they're like a few things that a lot of people, people might not even notice. There are new people joining. There are few things that maybe like 2 or 3 people are regulars. So if you show up, they will notice and like, oh, you're here. So you might get asked like, oh, what is like an interest that you hear? But yeah, it can also vary by thing.
Kasper Borg Nissen: And it's not only SIGs right. There's also sub projects within the different SIGs as well. So can you maybe explain a little bit about that as well.
Marylia Gutierrez: Yeah. So for example if there is a project that might take a longer time because imagine like you have a SIG for example like the semantic conventions. And now we decided to work on the specific like how it happened like last year, the database semantic conventions. We're going to say, okay, let's stabilize database semantic conventions. But now if we just spend the whole SIG, just talking about the database is going to take a lot of time off that SIG just for that project, because that is a more complex project. So what can happen is then okay, for let's create a project inside this one so it can have a separate meeting just for the duration of that project. So for example, for the database one, we had a separate meeting so we could focus only talk about that topic. And then we would just bring updates to the main one saying like hey we did this. Now we have this release just like the highlights type of thing. So those are things that happen for a while. And now it became stable so that one can get shut down and just go back to the main one.
Kasper Borg Nissen: Yeah. And I guess that's also like a sub like above the six. Right. Because there's also the text within the CNCF that OpenTelemetry is also part of. Right. So is that like an even higher level of organization around the different projects? Right.
Marylia Gutierrez: I would say like, first of all, we have like the projects, you have the SIGs, sometimes you have to like cross SIGs projects going on, for example, right now, like the declarative config is happening, but this one is going to affect all the SDK. So we want to have people from several SDKs going there giving their opinion and bring it back. And then we have the group that is the technical committee. So they are the ones helping out when there is like maybe two groups are doing the same thing in a very technical different way. So we're like, okay, we need to align how we do things or if there are people doing donations or like creating new projects, somebody needs to review those things. So this is why we also have the technical committee that can help with this.
[00:12:44] Chapter 7: Governance Philosophy and Path to Graduation
Kasper Borg Nissen: An interesting question maybe is because as a maintainer and a member of the OpenTelemetry governance committee, how do you sort of see balancing governance and sort of the need for community participation? Because companies come with different angles, like maintainers come with different angles, or contributors come with different angles. Right. So how do you sort of balance that that many people have different needs. But it should come together as a community project. Do you have some insights on that?
Marylia Gutierrez: Yeah. So the way I like to think about the governance committee is that we are there to help. We are not to force any agendas. So, for example, we really like each SIG to be their owner of their own sake. So we don't want to impose. Like these are the rules that everybody has to follow because they lose their autonomy. We can provide that guidance. For example, if some of them are saying, oh, I'm having this issue and we know that another SIG is doing that, well, we can kind of like share. Or if there is any conflict happening, these are the things that we can help. Or for example, we know that a project is happening. So we want to tell the other cities, hey, this is happening. You might want to work on this. So it's a little bit more like guidance. And it's not like a top down thing. It's more like how we can help, how we can support. And then, the maintainers have the autonomy to say, like, okay, we are giving priority to those things right now. This is what we are working on. This is how we're going to do the release. But of course, things also evolve. And that is something that we are currently discussing because when Otel started, there was a lot of like the three signals, like metrics, like logs, traces. But we have a lot more things. We have like profiles, we have messaging, and not all components are up to date. So this is why we are trying to find ways to give more guidance on, say like, hey, I think this would be the thing that we should be focusing on. For example, right now we are working towards graduation from Otel and there are a few things that need to happen so we'll be able to graduate. So this is why we are giving guidance to the CXC. Like, hey, try to make everything stable, try to have this or that feature that will be required and things like that.
Kasper Borg Nissen: That's an interesting one, because that is also a thing that I've been trying to follow a little bit on in my graduation of OpenTelemetry. When do you see this happening? How much work is there in front of the different SIG to get this done?
Marylia Gutierrez: Yeah. So I think that is going to be like the focus of this year for a lot of the six. Because I think one of the challenges that people have is, for example, the meaning of what stable means so we see a lot of things that are like, oh, there are markers as developments or experimental. That does not mean that it's not ready for production. So that is different it just means like for example, we don't have a semantic convention for it. Because of the semantic convention we create, we see like everybody has the same, the same like use the same name for this metric, for example. And then we mark this as stable and people follow it. But we might not have semantic conventions for everything. So some things are implemented are good to go like you can already use in production. But we are saying like this value might change on a feature and it's not like we're going to do something that breaks. We are trying to like backward compatible or we create like a new release, like major release, and that one can break. So we are trying to also change a little the view of people, because I think that is one concern for graduation. Like, oh, it's nothing is stable. It's like, no, no, it's just we called stable a different thing.
Kasper Borg Nissen: Naming is hard.
[00:16:33] Chapter 8: The Challenge of Naming and Evolving Conventions
Marylia Gutierrez: Yes. Oh I joke with the naming that even like when we did like the database semantic conventions, you think like, oh, it's very easy. Just call this metric. I don't know the schema. I was like, oh no, not all databases have schemas. Okay. Group. No, it doesn't make sense. Okay. Collection. Okay. What? It just takes so much time to decide, like a single name. But. Yes.
Kasper Borg Nissen: Yeah. I've also noticed this within the HTTP and stuff like that, that things just change because. Yeah, that's just how it is. Naming is hard and we all have different opinions I guess.
Marylia Gutierrez: I feel that it's the equivalent when I don't know when you're doing something like a group project. And I was like, high school, you finish the whole project and you have to pick the just the first page with the title, and you have to choose the font and you spend so much time on just like word art.
[00:17:29] Chapter 9: Growth Path: From Triager to Approver to Maintainer
Marylia Gutierrez: That was like me, I finished all the project in I don't know, one hour but no, I'm gonna spend three hours on which colors gonna be the.
Kasper Borg Nissen: All right. So so many contributors might aim to move from like, like first time PRs, right? To become actual approvers or maintainers. And what does that journey typically look like in OpenTelemetry? And do you have some good advice for someone that really wants to grow in this project, like long term?
Marylia Gutierrez: Yeah. So one thing that we like to see first is consistency. So you want to always, for example, join those circles. The progression is triager approver, maintainer. So triager, we want to see somebody that is as well as the name say triaging. So issues are coming up. So you try to see what makes sense. Maybe start replying kind of helping out with questions. The all the SIGs will have a slack channel. So maybe you're also there helping with questions when people have. And then you can start like reviewing PRS from other people. With that we will notice like okay, you're really helping out with others. So then you can become an approver. And then it is also a matter of time if you do this also for a long time and there is a need for a new maintainer, then you might become a maintainer. That can vary a little of what it means depending on the sequence. For example, the ones that instrumentation is a little easier to understand, like what is a contribution? But we have a few there, a little more open, like the end user seek. That one is not like you have codes to see getting reviewed. It's more about getting surveys, getting things.
Marylia Gutierrez: So they might have slightly different requirements. But you can always talk with the maintainers of that, like, hey, I have the goal of becoming one. How can I work towards this? Like, what do you think you should be focusing on? And I know that people sometimes tend to say like, oh, for example, the there are few SIGs that have a lot of people. So you say, oh, I want to go to that one, because I know that I would get a lot of feedback on my things. I would have a lot of people to help me out, but that one is probably is going to be harder for you to get a status just because there is already a lot of people, but there are a few seats that have very few people contributing. There are a few that have like 1 or 2 people that are regulars. So they are craving for this help. So I would say don't overlook those ones, really go to those ones, because then you can have a really big impact and a lot of people want them, but we just don't have enough people to contribute. So this way you're probably gonna like go the the ladder a little faster if you're around those ones.
[00:20:18] Chapter 10: High-Value Non-Code Contributions
Kasper Borg Nissen: Okay. That's good advice. So you also mentioned, like, non-technical contributions as being crucial to the ecosystem. So what kind of non-code contributions do you think are the most critical ones for the health of OpenTelemetry? And do you sort of feel like that these kind of contributions are recognized enough compared to how code contributions are being recognized in the ecosystem?
Marylia Gutierrez: Yeah. So I think they're very important. So we have likes from different levels from the side of people that are doing instrumentation. If you go there and just like create an issue or like you vote on issue, that already helps because that helps the maintainers to know, like what the community is after, what are the things that they should focus. So now they know, like, oh, everybody's voting on that issue. So let's focus on that issue. If people don't vote, they have to select what they think is important and might not necessarily match what the community wants. But if we don't have the inputs, there is no way of knowing. So even basic things like this already help like revealing PRs. But if you say no, I don't know any code documentation is a really good one to start, because just think about it from both a contributor perspective or a user of Otel you want to use and you go there. Otel has so many components. I say that the good thing about Otel is that you can do so many thing with it. And the bad thing about Otel is that you can do so much things with it. So it's so hard to like, what do I do? It's like, what do I need a collector? What is a collector? I don't know, like collectors has so many like other packages? Do I need all of those? I don't know, it's just so much to learn than just having like the documentation for it.
Marylia Gutierrez: And we know that people don't like to write documentation. So this is why I say, like, even if you just go and like, okay, I want to play with Otel and then you're following the documentation. And if you notice that like, oh, there is a couple of steps missing here or something is not up to date because it changes how it works. You can create a PR to update this or to create a new one. This helps so much. And we also have the localization efforts. So we are having basically all the documentation translated to other languages. So we have Portuguese, Spanish, Japanese Ukraine. So it keeps increasing. So that is something that you don't necessarily need to know about the project. But you can help with localization. And we have the team that usually has our own glossary of things saying, oh, this thing we translate because there are some challenges there. For example, we translate the word trace, but we don't translate tracer because tracer is the name of the components. So for example, if we want to keep the name, because if people want to actually write the code, they're going to write tracer because that is the actual name of the component. But to say what it actually means, we translate to tell people what tracer means.
Kasper Borg Nissen: Okay.
Marylia Gutierrez: So there are a lot of things there.
Kasper Borg Nissen: Small details.
Marylia Gutierrez: Yes.
Kasper Borg Nissen: But that is also a way of contributing then like just.
Marylia Gutierrez: Oh. Yes.
Kasper Borg Nissen: Localization of whatever language you are coming from so that you can help, like the local community around where you are living with understanding what what these things are.
[00:23:47] Chapter 11: Feedback Delays, AI-Generated PRs, and How to Get Reviews
Marylia Gutierrez: Yeah, exactly. And then we see people sharing a lot of, like the translated versions, the things. So, you know, like it's really helping because you want to bring the community. So if you focus just in English, I alienate a lot of people as well.
Kasper Borg Nissen: Exactly. So I think in one of the recent contributor experience surveys, some contributors mentioned that there was some delay in feedback. And I actually also experienced this a little bit on myself on a couple of PRS. How do you see that impacting new contributors, and what can the community really do to sort of improve that? Whenever someone new comes into the ecosystem if they're getting the feedback, they can see some progress.
Marylia Gutierrez: Yeah. And I think that is something everybody goes through. I also like that my PRs are not getting reviews. Because I think, like one of the things that I mentioned, first of all, there are a few SIGs that have a lot of people. So the chances of you getting your review are higher. And and this is also about consistency, because the first time you're going to open a PR, we don't know who you are. We don't know how well you write code. And one challenge nowadays a lot of people are using AI and we see some really like bad codes that people just create and don't review at all. So that creates so much challenge for people reviewing. So you need to okay, create basically a relationship with the SIG. So the more you contribute people will know you are really there because you want to help out. You want to improve the thing. Also, if you go to the sick and say like, hey, I have this PR up, can somebody help me like review? You're going to have like a higher chance of getting feedback. So it is a little more about something. And I mentioned like some SIGs have two people and yes, having only two people to review a lot of PRs. It can take time. So this is why I do the call outs like be a contributor, because if you start contributing, you can be the one reviewing all those people's PR so you're helping other people and it just becomes a cycle. Right. And then because that person had a lot of PRs merged, they would merge like review another person and so on.
Kasper Borg Nissen: So your advice is to just go into the different SIGs channels and say hello. I'm interested in contributing or I've created this PR, can you please help me move this along. Yeah. Because I think, I think at least from someone that is working at a company that just like, found a little box somewhere and they just want to contribute that that may be an issue, I guess, because they might not have the time to go in and engage with the xl6. Right. So how do you get more like companies to contribute and help? With some time from that developers to basically help improve the ecosystem overall.
Marylia Gutierrez: It was a good example that you gave because there are also different level of contributions. We have people that come say like, hey, I'm using this and it has a bug. So I, I did the fix and I just need help to reveal. So just by sending like the message, it is a way to get attention. Sure. So you know we know that like okay, it's not like you're going to be consistent and continue on. But that is something that is really important. So we sometimes even classify issues that open as priority saying like oh no, this is like really breaking something. So we try to really review those first. So, you know, just by kind of like giving the shout out, hey, I'm doing this. Can somebody help me out? It really helps. If you're doing, like smaller things here and there, when I have, like, smokers, sometimes I just get in the mindset, they're like, okay, I might take a little while for review because it's not urgent. But if you plan to do something that is a little major, I would ask first because you imagine that you were like, oh, no, I want to completely change how this thing is done. You want to check with the maintainers because they might say, like, oh, we actually have a plan to change this already. Or like, no, this will not align with something that we are working on. So we don't want to waste your time. So if you have planning or something like a major change, make sure to check and say like I'm going to work on this. Is anyone else also working on this?
[00:28:06] Chapter 12: Mentorship, Onboarding, and Contributor Experience
Kasper Borg Nissen: Yeah, because they probably know a little bit better what impact that possible change could have. So. Exactly. Always go out and check with the maintainers. I think that's good advice as well. Yes. Are there any ways within the ecosystem to get a mentorship. And I know from the Kubernetes project we had shadowing and stuff like that. But anyways, that OpenTelemetry community is like thinking about nurturing the new, like contributors to this ecosystem by providing mentorship, etc..
Marylia Gutierrez: So there are a few mentorships that are not official from Otel, but we create like the Otel to other things like for example, outreachy we had. I was a mentor there on the previous cohort for the Linux Linux Foundation. I think there was one that is happening now. So we tried sometimes at Otel. So there is nothing official for Otel. But one thing, as I mentioned, like the SIG that I am, that is the contributor experience. We try to help out people that want to start. So we have a new channel that is OpenTelemetry new contributor. So if you are very lost and like, maybe are just looking for the right channel or send a message there that we can then guide you to like, oh, this is where you should be going, things like that. Remember, it's not that thing of like, I'm here. Just tell me what to do. Again, it's not about that. It's more like I want to work on this thing where it is. You can kind of like, point it out. And we can also join the contributor experience. If you have feedback that you think it would help the community. So for example, the outreach one that I did was because a lot of people say, like, I don't know how to run things on my computer. I have no guidelines to be a contributor for its sake. So that project we actually created, you can see now all the repos have a tab of contributing. So that one is going to show versions of things that you need, how to run tests locally and things like that. We also have someone from that SIG doing surveys right now with people that are just starting to get feedback and see how we can improve.
Kasper Borg Nissen: How we can improve. Yes. Yeah. Because the OpenTelemetry ecosystem is so wide these days. Right? I think it's over 90 different repositories and I don't know how, or how many different languages.
Marylia Gutierrez: Yes.
Kasper Borg Nissen: So there's all kinds of ways to run this and get all of this up and running so you can start contributing.
Marylia Gutierrez: Yes.
[00:30:40] Chapter 13: Looking Ahead: Easier Instrumentation
Kasper Borg Nissen: Maybe looking a little bit ahead, what do you hope to see in the future of the OpenTelemetry community? Are there any big goals or milestones maybe other than like graduation of the project itself that you are sort of particularly excited about?
Marylia Gutierrez: Yeah. So one area that we also want to focus on, because it can be hard for you to do like the hello world, let's say because the very basic hello world, it works for a lot of people, but a lot of people don't have Hello world type of applications. So it can be very hard just to initialize and knowing, okay, I want to collect, but I don't even know what I'm collecting. So we want to make the instrumentation easier for people. The ideal scenario for me would be the thing. Like I just install one thing, run at that. I don't have to think about which components I need, which languages it will like, auto detect everything for me and just send. So I think that is the future of yeah how things are hopefully getting there eventually.
[00:31:48] Chapter 14: Encouragement for New Contributors and Closing
Kasper Borg Nissen: Awesome. So finally maybe for anyone listening who's sort of on the fence about contributing because they feel they may not be experienced enough or so what would you say to sort of encourage them to start contributing and maybe give them your best free advice or something like that.
Marylia Gutierrez: Yeah. So I would say don't be afraid. The community is very welcoming. They want people to help. So we were there to guide you if you like or have doubts. You're like, I want to learn this area. We can. I sometimes have one on one with people just to teach them thing. And one thing that I also say like, don't be afraid of your first PRs. The amount of comments is because it is nothing personal. Don't worry, I have a. I even joke that on the localization because we have such nitpicky things. When I see a person opening the PR for the first time, I usually message them saying like, don't be alarmed by the amount of comments that I'm about to put it on, because it is just it.
Kasper Borg Nissen: Can be overwhelming.
Marylia Gutierrez: It can be overwhelming. I was like, it's nothing. I'm not saying your PR is bad. No, it's just you don't know the guidelines for this specific thing. So it's just a matter of learning. I have like somebody that he joined it and he even tells the story later because like, oh yeah, she told me that. And then that PR had 150 comments.
Kasper Borg Nissen: 150 comments. That's quite a lot.
Marylia Gutierrez: I was like, see, but nowadays there are PRs that I put zero comments on for him.
Kasper Borg Nissen: So you were, like, maturing and learning how to contribute?
Marylia Gutierrez: Yes, exactly. So don't be afraid. Just join. Try it out. You don't have to, like, commit right away for something like joining a SIG. If you don't like it, go to the next one. Keep an eye out for, like, things popping up sometimes. Just like looking at the slack messages and all the SIGs are recorded. So you can also watch the recording if you don't feel comfortable joining. So you can just watch and see, and have an idea of how things work as well. But yeah, just dive in.
Kasper Borg Nissen: Just dive in. Start with slack so that you like to familiarize yourself with who's who's there and and make your intentions clear. And then start. Start contributing.
Marylia Gutierrez: Yes.
Kasper Borg Nissen: Awesome. Maria, thank you so much for joining us on Code RED. I think a lot of listeners will, like, walk away with a much clearer sense of how to get started with OpenTelemetry and how to become part of this community around it. And also from the Non-code contributions as well. I think that is a great point to get across as well, that it's not only code that counts. Code does count a lot, but, but, but you can do a lot of things within the ecosystem to help it progress even further without contributing code as well. So thank you so much for joining.
Marylia Gutierrez: Thank you. Happy to be here.
Kasper Borg Nissen: For those listening, I hope today's episode showed that contributing to open source doesn't have to be intimidating. Whether you're writing code, improving documentation, joining a SIG meeting, or just asking good questions, every contribution matters. If you want to learn more in the episode description, we'll include links to blog posts, how to contribute to OpenTelemetry and the OpenTelemetry community resources. So go ahead and check them out. Thanks again for tuning in. I'm excited to continue this new chapter of Code RED with more deep dives into observability, platform engineering, open source, and the people driving these technologies forward. We'll see you in the next episode.
