 So, two years ago, I joined a platform attack, and this is the most recent picture of our team, and if you zoom in a little bit, you're going to see me right there. Don't ask me why I look so satisfied in this picture, because I had no idea. Anyway, this is how you can find me on the Internet, and by looking on the previous slide, you can guess that I post a lot of silly stuff on Twitter. So if you want to follow me there, do it at your own risk. But also, if you want to give feedback on this talk, that would be really appreciated. Anyway, you might have heard of us due to our open source work, but the form attack is known for some ruby gems like device and simple form. And also, the possibility to work on those gems is one of the reasons that made me want to join the company in the first place. But when I got there, most people that maintained those projects had either left or created a new language. The truth is, we get paid by clients to deliver projects. So most people that did open source did it in their spare time, which means that once those people left, the projects became inactive. So issues and poor requests would sit there for weeks without any response. And I wanted to help, but I didn't know where to start. It was only then at RubyConf Brazil 2017, where Rafael França gave a keynote about the future of the Ruby community. And he talked about how Ruby is not a cool new thing anymore. Everyone just want to talk about Go and Elixir or Rust or something. So the question was, what's our future then? Well, he said that the future of the Ruby community is brilliant, but it depends on us. And basically, he was saying that everyone can help. We can do open source. We can write blog posts about cool things we learn. We can organize and attend to local meetups. Or you can just talk to your colleague and share something cool you've done at work. Those are always to keep the language interesting for new developers and to give it back to the community. So after that, I decided to do it. I decided to maintain the device gem. Just so you have an idea, this is how things look like at that time. We had about 150 issues and 51 poor requests. And this is how things look like now, which I believe is way better. Thank you. So the reason I'm here today is to share my journey with you, the things I struggled with and the mistakes that I made and the lessons I learned from them. And to tell you that if you ever wanted to contribute to open source but thought you're not good enough, hopefully my story can convince you otherwise. And hopefully I can convince you to go ahead and try it. And based on that, the first thing that I can tell to you is that you are good enough. I really think that everyone can do open source. But I do know it's hard to start, right? And part of that, I believe, is because we think we have to call to help. We got to understand like the whole code base before we can do anything. But I think the quickest way to start is to do issue triage. What does that mean? So triage is the process of examining problems in order to decide which ones are the most serious and must be dealt with first. And for open source, this means ensure that the issues follow the recommendations from the project's contributing guide. So some projects have a file like this one. This contains guidelines on how to contribute and report issues to that project. So for example, on Rails, they ask you to send feature requests to a mailing list. But we do accept feature requests on device, so those things will be different depending on the project. That's why I recommend you to read that file before you do anything else. And if the project doesn't have one of those, like you can create an issue and ask for it, that would be a great way to start contributing. So here is what the device asks for contributors when reporting issues. Include a title and a clear description as much relevant information as possible and either a test case or a sample Rails app that replace the issue. And you say that because it's hard to fix bugs without information, right? It's kind of like when someone says our site's not working. And like one of the first things we ask is, which browser are you using? In device, we also ask for a failing test case because we want people to try to reproduce the issue in isolation. This means without any other gems, just device and Rails. And we say that because the most common case is expecting to be working since we have tests for it, right? Or at least we hope so. So unless a lot of people are experiencing the same issue, chances are it's been caused by a combination of things that is very particular of their application. Now, not saying it's not a bug in the library, it might be it. But by doing this, people can find out what's wrong. The combination of things that's causing that issue. And this will give us a better direction of where to look at it. So that's the first thing I did. I just looked at four issues that were missing information and would ask the actor to send it. And then I would just add this needs more information label. And I just want to give a side note here. You can probably see that I've replaced this person's handle with the GitHub Ghosts user profile. If you want to, you can probably just find out who they are. But I ask you not to because I don't want to expose anyone in this talk. It's just easy for me to talk about things that really happen and to show you the lessons that I learned. But I do want to talk about situations here and not individuals. Okay, so two weeks after I asked for that information, I will look for issues with the needs more info label that didn't have any response and just close them. I know two weeks is an arbitrary value, but it seems like a good time spent for people to come back at us. And if they haven't yet, maybe the issue is not their priority right now or they couldn't reproduce in isolation. And another thing the device contributing guide says is, avoid opening new issues to ask questions. Please go through the project's week. Documentation answers could first or try to ask your question as tech over flow. And about this one, I want to say that it's really important to ask questions. But the issues tracker may not be the best place for it. And I say that because the only people that receive notifications in there are the maintainers and the watchers. The watchers are usually there just to know about new versions or the issues. So they're probably not going to answer any questions, which leaves us with the maintainers that are usually not much people, you know, few people. So if you ask a question on the device and wait just for me to answer, it's gonna take a while. So that's why we say that's better to ask on public forums like Stack Over Flow. But again, this is going to depend on the project. I know that some projects accepted will help pay requests on GitHub and works well for them. Other projects also use mailing lists or forums just for this. So yeah, it's going to depend on the project. So that's the other thing I did on issue triage. I would just look for issues that were help requests and close them. And I do a lot of this in the beginning. But this is something I've been trying to do differently lately because when I realized the person might be a beginner, I tried to give them a better answer. It's easier after some user experience to forget how it was like when we started, right? But I do remember I was afraid to ask questions at work. I was afraid to sound stupid. So I think it takes a lot of courage to ask a question, especially in a public forum like GitHub. And I don't want the first experience to be this bad. So when I can, I give them a better answer. Like, one time someone opened an issue saying that they were not seeing the flash messages in the device. And I know that Rails doesn't show those flash messages by default. You have to do it in your application. So I answer explaining this to them. And I wish I could do this more often, but sometimes we just can't, because there's not enough time. And some help requests are we're more complex than this one. So what I'm saying here is that issue triage is a great way to start. I could, like, this made me feel productive very fast. And it doesn't require any previous knowledge of the code base. And after doing it for a while, I gained a lot of context of the project and the current problems it was facing. And if you do that, you'll get to know how the maintainers work and the common questions they ask on issues input requests, which will probably help you in the future when you start sending patches for them. I highly recommend you to read Steve Klebinick's blog post. He explains how he started doing issue triaging Rails. And one interesting thing that he says in this article is that he used it to do it 15 minutes per day. And he was to do it before leaving the office or after lunch. I actually do it a lot while waiting for a CI. So now you know how you can start and also how to do it without spending a lot of time. But now you might be saying, but I'm not a maintainer. And I gotta tell you, the only thing you can do is click on the merge button. So seriously, you don't have push access to the repository, but you can still do issue triage the same way that I do. And as a matter of fact, some people are already doing this in device, like this person who asked it for a sample application. And this other one who asked a couple of questions to try to clarify what the issue was. And this is just an example of how we can start contributing. There are so many other ways to start help, like review pull requests. So you can look for possible issues and pull requests. Ask first test because honestly, if I see a pull request that doesn't have tests, that's basically the first thing I would do anyway. And you can also test the solution. This one is very important because if you're experiencing an issue and like found a pull request for it, just test it, test your application with that code to see if it works and comment back in the pull request what you have find. Like this will help the maintainers a lot, just to have a confirmation that the issue is actually happening by a second person. You can reproduce an issue. Share what you have found in the issue page. Or share your solution. This can be writing blog posts or asking questions and start over flow. Or just on the GitHub issue tracker. If you know the answer, like this person did, just share with the community. And lastly, you can write documentation. Cause when I started, I struggled a lot with the vice test suite. I spent some time discovering how to run tests on specific arrays and Ruby versions. So after I managed to get it working, I wrote a piece of documentation on a readme. And I hope this will help others that wish to contribute to that project in the future. So those are all examples of how you can contribute without having to write code. Because for me, open source is about helping people. And there are a lot of ways to do it that don't involve writing any code. That's great, but now you might be wondering, we're just asking for information, reproduction steps and stuff. What happens when they do send us the required information? So it's time to reproduce the issue. And this can be run a failing test case or just follow the reproduction steps. And once we confirm that an issue is happening, it's time to understand why. Because what we're going to do next depends on the issue. Cause if it is a regression, which means it uses to work on a previous version, we can use the git bisect comments to find out which comments introduced that regression. Now, I'm not going into the details of bisect here, but I do recommend you to read Jason Draper's article. He explains very well how to use it. But sometimes we are after unknown issues and things that never worked before. And for me, this is kind of like when you join a company and they give you a ticket to work on without any kind of onboarding. And you just spend a lot of time, diving to the code, messing around to see what's happening. And so for me, one thing that's being very helpful is the pry gen. Probably a lot of you already know it, but I wanted to share a couple of articles with you because before having to dive into the vizes code, that was mostly a push the booger. And so maybe those articles can help you get along with pry too, if you want. The first one is the bugging rails with pry. And the second one is git labs, pry the bugging guide. Another thing that I really recommend you to read is reading your framework search by Orish Akid. He explained some techniques that helped to understand an unknown code base, like looking at unit tests, for example, because they can serve as documentation, telling us how the code behaves in different situations. Okay, great. So now this is all to find out the code that's causing the issue. But what happens when we do find that code? And I think it's always hard to understand the piece of code that we're not used to. My colleague, Hongi, wrote something that I think summarizes this feeling very well. Also read a piece of code for the very first time we are immersed in a long learning curve. And a continuous cycle of questions, doubts, and insights. Basically this means we start thinking. What are they thinking? This makes no sense. They could just have done X instead. But the truth is we have no context of the code, right? The only information we have is the date he was committed and the person who did it. We don't know the intentions behind it or the moment the company is won. Like there's one situation I'd like to share with you based on that. Someone reported an issue saying that it was possible to create records on the database during sign up, even though the validations have failed. You probably know the feature where the device keeps some stats about the user like the number of times they have signed in or something. It turns out that when we do that, we ignore the validations. And so someone sent us a pull request which was literally one line change. So this looked like an obvious change. We considered a bug fix and merged it and released it in a minor version. What we didn't predict was that since this has been in the code base forever, a lot of applications were reliant on this behavior. So once we changed it, things started to break. We got one, two, three, four issues. You got the idea. The point is that since we started validating the user upon signing in valid users, we're not being able to log in anymore. And this made me realize how we have a limited vision of the word. We make assumptions based on our past experiences, right? Because in all the Rails applications that I worked at before, and trust me, there were a lot of them, we would strive to have valid modules, right? So I thought that having valid users in the database was a very uncommon thing. But by the number of issues we got, it seemed like it's not that uncommon after all. So this made, I was already considering holding back the change when we got the following issue. So basically this person was calling an external service inside a validation callback. And this server charged them pre-request. So since we started validating the model in a place we were not before, they got a big bill out of it. So this made me feel awful, right? And actually reconsider what I was doing. Because clearly I didn't have like enough experience to handle this. And because of that, someone just spent a lot of money. And I wanna tell you, in those situations, it's easy to feel overwhelming. So the best thing we can do is to talk to someone else and ask for advice. So I talked with some colleagues and other open source maintainers. And they all agreed that it was better to roll back that change. Because although we couldn't predict that a lot of applications were reliant on this behavior, this kind of change should be done in a major version, right? So I solved the original issue with another solution and removed the validations. But I also advised that person to keep those kind of external requests in a place you can control out of validation callbacks. Because they can be called in places we don't know of. Like inside the Rails console when we are debugging a production issue or in a rake task when we are updating and importing data in batches. Or just when someone new joins the team and they might introduce code that runs those validations without noting about the side effects. And code review and test may not always prevent those things. So this brings us to my next lesson which it's okay to make mistakes. It's okay because we can learn a lot from them. And when we do make mistakes, I believe we should focus on the future instead of the past. So this means changing the question, what should I have done to what can I do from now? Because after this, I was way more careful with change that could break backwards compatibility. Now I think in ways that the code could break existing applications that I wouldn't before. So this mistake made me grow both as a developer and as an open source maintainer. Another thing that I wanna tell is that after that incident, I decided to look for the commit message that first introduced that validate false code to understand why I was there in the first place. So this was not much helpful. But it made me realize how old this code was. This code was nine years when we accepted the pull request. And this brings us to the next lesson I learned which is document your decisions because we cannot trust our memories. It would be great to ask the others every time we have a question about their code. But if we can do, we can ask them. They may not remember. I mean, would you remember the reasoning behind the code you wrote 10 years ago? I certainly wouldn't. So that's why it's important to document the decisions like why we did something and the other options we tried because the code itself is not enough to show us the big picture. And I think one of the best ways to document the decisions is inside git commit messages. So if you haven't yet, I recommend you to read Caleb Thompson's article. He gives some great tips on how to write good commit messages like which questions the measures should answer. For example, why was this changed necessary and how does it solve the issue? Another article that I like a lot is how to write a git commit message by Chris Beans. This one folks more understood of the message and proposed some guidelines to write commit messages which is also very interesting. So for me, what a good commit message looks like is this. We have a brief summary that explains what was changed and the details give us context of why this was necessary. And it also gives a hint that this can be removed once we drop support for reuse four. Now, another thing that I learned from that validation issues and also others that we had is that code is expensive. So that one line pull request seem innocent but causes a lot of trouble. And for open source libraries, once we add the public API, we can only remove it in a major version. And even in a major version, we don't wanna make a nightmare for people to upgrade so we have to be careful with which code we introduced to the library. So basically now I only merge for requests when this happens. And if you have fail say it's okay, it's okay. But really when I review feature requests now I started to ask some questions like is it reusable for other applications? Is it an edge case? Because if it is, maybe it's not worth it added to the library. Is it flexible or is it too complex? All those questions help me to understand whether the cost of that code is worth it or not. And the next thing I wanna tell you is that if you're going to do open source, be nice. Because a lot of people had bad experiences in open source, I know that some people are rude, disrespectful and mean. So it's important to have a code of conduct in the repository to ensure that everyone has a harassment free experience. And as a maintainer, make sure to act in cases where this code of conduct is disrespected. I also highly recommend you to read this book. Nonviolent Communication by Marshall Rosenberg. His strategies for communicating with others and transform potential conflicts into peaceful dialogues are just amazing. But in summary, what I try to do is respect other opinions. Don't make fun of people just because I disagree with them. And to ask questions, try to get as much information as I can before jumping into any conclusions. And to have empathy because I don't know that person what they're going through. For example, some things that can be causing someone to communicate aggressively are deadlines and production outages. Those situations cause a lot of pressure and the pressure can be easily passed along. So for example, one time someone commented the following in an issue. It is a bug but seems like that unless the bug affects many people, no one cares. And all I could see in this comment was the no one cares part was like really? Do you know how much time I spend on this? Like my spare time? So that may be very upset and a little bit angry. So when this happens, what I try to do is follow Jason Fried's tip, which is give it a five minutes. Now he's actually talking about waiting five minutes before we disagree with someone on an idea. But I found this works very well for situations when I'm angry too. Because it's easy to be rude when we just heard something that made us feel bad. But if we wait for a while before we speak, those emotions might be gone. And actually for me, what's been working better is just to give it a day because then I have time to fill my mind with other stuff. Things that I like to do like practicing sports or dancing or just spending time with my family and friends. And the good thing about this is that it also gives me time to understand the situation better. So in the case I mentioned earlier, that person felt like no one cares because they posted a comment in an issue and no one responded, which is terrible, right? But the problem is that issue was closed and I usually can't keep track of those. So I just answered then explaining why this happens. It's hard for me to keep track of all the notifications. So it just works better if you open a new one. You are definitely going to have my attention. Okay, so another thing that I wanna say to you is if you're going to do this, take care of yourself. And what I mean by this is there is always going to be another issue to work on or another pull request to review. So don't feel guilty if you can't solve everything and rely on automated tools to help you to do the job. Like issue templates can give people a better direction of what the project aspects of them regarding information and everything. So we probably don't have to do much issue triage with this. And another thing that I use a lot is GitHub Save the Replies. Because we're applying to a bunch of issues can get boring and this helps us to do issue triage faster. Another thing that's very useful is a stay-about. It will automatically close issues after they went stay here for a while. And the cool thing about this one is that if someone comments on a closed issue it will actually open up for you. So that's nice. And finally ask for help because it's easy to feel like we should know everything. Since you are the maintainer of the gen you gotta know everything but we shouldn't and most importantly we can't. So ask other open source maintainers for help. Ask your colleagues for help and finally ask the community for help. This is something that it took me a while for do to do it but you know I have an example for you. Like when a user found a security issue in device and I created a patch for it with we merge it and move it on but then someone asked whether a CVE was created for this. Now I have seen CVs around before but I didn't know exactly what they are and I obviously had no idea of how to create one but I was insecure about saying this and the issue. So I searched a lot on the internet and only answered a month later when I was able to request one. But it turns out the person who asked it is Reed Lawden which works at Hacker One and was able to help us to get the CVE. So if I had been honest in the first place we would have got that way earlier. So don't be afraid to ask for help. It's okay. Also thank you Reed for helping us with this. Another important thing that I wanna tell you is that show your company why this is important because it's hard to do it in our spare time and we don't wanna do it this forever. So some things you can tell them is that while doing open source we learn a lot of stuff, right? This gives us the opportunity to write blog posts and give talks and those things help with the company branding. It can get them more clients and also more developers to their team. Open source also helps with motivation. So we know that working on the same thing over and over again can get boring. So if they let people do open source part-time this can help with their motivation and can also decrease their turnover ratio. While you're doing this we also learn a lot of stuff like Rails internals, how to write commit messages all those kind of things and this will help with our professional development. Because of all those benefits some companies are already doing things like OSS Fridays which is a way to let people work on open source without having to do it in their spare time. And at our company we are able to get paid hours. So we still gotta do it after work but at least we'll get paid for it which is better. So this is basically my story. If that's not much interesting to you what I want you to take out of this talk is you don't need to call to help like there are other planning, other ways to do it. If when you do it document your decisions because other contributors and also you fit yourself will be grateful for it. Be nice, be respectful and finally ask for help. Don't try to solve everything alone. The community is there to help you too. And also if you wanna start doing this and need to help feel free to ask me too because I know I had a lot of it, right? I had help from Jose who helped me to start by showing how to do issue triage. And I helped from Rafael who revealed a bunch of pull requests and was there to answer difficult questions like things about semantic versioning and never get the one right. And lastly, Les Banolis from my former colleague, Felipe who has been my partner in this journey helped maintaining the simple form gem. He's actually the one that convinced me to start maintaining the device and also to give the stock. So probably have not have done any of this without him. So I just wanna say thank you to all these people and to everyone to contribute to the device and also to you who came here to watch the stock. So thanks, that's it. Thank you.