Your First Open Source Contribution in Python: From Fork to Pull Request

Speaker 1 [00:00]

Good afternoon everyone. We welcome you to this workshop. So to remember, recall to give us your questions at talks.python.da. Yeah, look for this room and for this workshop talk. and then I will moderate, I will be very happy to moderate the questions, I'll do my best but it's important to do it through that because we wanted we want to have a good sound and everybody to know what is the question about so here is Camila Maya she will introduce herself so just let's welcome her, thank you Thank you.

Speaker 2 [01:01]

I'll share with hmm I shared the presentation link human and it's in in Portuguese, isn't it?

Speaker 1 [02:10]

Thank you.

Speaker 2 [02:11]

I think I can help you now.

Speaker 1 [03:30]

Thank you. We're having some technical problems here. So meanwhile They are solved. I Forgot to tell you about the questions We're gonna have couple breaks. So As the question comes I am I'll try to do my best in in organize them and then during the breaks We can we can do the the questions. Yeah, so They're not gonna be all the way until the end end but they're also not gonna be like in real time so for you to know yeah thank you

Speaker 2 [04:47]

So many fingers here. the internet is not working no, it's almost the internet is not working that much but it's thinking it will at some point here it is already connected this Yes. Oh, you're not seeing there. Okay, then it's weird. I don't know why it's . Okay. Do we have another Wi-Fi? I can go with my phone, too. Let me see if the memory is good. No, but it's not good in here. Let me check if the internet is coming. you Finally! Yes! Hello! I hope you are good and I hope you could have at least a bit more time to digest the lunch. Let's start. So, this is just to check if you are in the right room. So, this is the tutorial. Wow, this is amazing. Really huge screen here. So, it's It's the story about your first contribution with open source, and we will start with a Python project for sure. So this is the QR code or the website where you can access this presentation. So then you have all the other links, and then you can check it out. So there. So first of all, hello. I'm Camila Maia. I'm from Brazil, more specifically from the south of Brazil, and more specifically in Florianópolis. I'm from Florianópolis, and I came all the way here for the PyCon conference, so I'm quite happy to be here. I identify myself as a woman, lesbian, and I'm also a person with disabilities, so if If you have any questions and you try to do this, I will not see. So you need to clap, scream, or come here and ask something. And yes, I'm glad to be like a diverse person, being part of also the speakers team. So thank you for the invite. I'm a developer experience specialist. I've been working with IT since 2010 or so. I already worked with so many different things, but in the end, like in the last four years or so, I have been working especially with developer experience, which is like working with DevTools and trying to make the life of the developers a bit more happier, let's say. Not only with the tooling, but also with the whole development experience. I'm also a co-founder of Cumbucadev, that is this organization that I'm wearing the T-shirt with the logo of. We are an organization that we help underrepresented groups to enter and to ascend in the career, and we use open source. So basically, we have, when you talk about Cumbucadev, we talk about education, about underrepresented groups, about technology, and open source. We want to use open source as this tool to help us to understand and get more into the IT world, especially for the beginners. So let's go for the agenda of this workshop. The first is talking a bit about open source. And then in there, we are going to have like a small tutorial that you will be able to practice creating your first contribution with open source. And then, afterwards, wow. I was not expecting this effect. Look. Fancy. Okay. And then we are going to talk about scan API, that is the open source project that I created. And then afterwards, is also maintaining it, me and many other people. So I'm going to talk a bit about this project. And also, afterwards, we will contribute to this project in specific. And then some closing thoughts, and yes. So let's start with open source. Okay. So what is open source, basically? Just for me to have an idea, I was going to ask you to raise the hand, but then I will not be able to raise the hand, to see. So I'm going to ask, and then you, I don't know, clap, if you know what open source is. . Thank you. Thank you. Okay. So it's nothing that much new for a lot of you, but also it's good, because if you join here, it's because you want to contribute, right? So if you want to contribute with open source, you already know it. But it's basically like it's a public code. So people can see what is there. So it's not a code that only some people have access to it. But also, people can modify it. And one thing important to say in viewing is not that it's only like possible to read, but also that it's like in a program language that other people know. It's not open source if you create your own program language, and then that is private, and then you go and create a source using it, because then people cannot understand. So it needs to be public there, but also to be understandable by other people. And then people can also modify the source code that is there, and people can distribute it. you ask, okay, but how? You can go crazy and start sharing the code and modifying it? Yes, you can, but if you follow a license, so each OpenStars project, it has a license that says exactly what can be done and what can't be done in this project, like using this project, and also if you can do something, but you have some obligation with it. So, for example, You can share it or you can modify it, but you have to give the credit to the person who created it, to the organization that created it, and so on. So this is a really, really summary about what is open source, but it's just for us to have some basic knowledge, so then we can work on top of it. So why open source matters, why we are talking, I mean, like, during the whole conference, I think you're going to listen a lot about AI, but open source too, and why this? Just to give some context, about 90% of applications in the whole world, they use some code that is open source, like in their whole structure. So it's massive, open source is everywhere. Also it's like because of this way of contributing, a lot of people can collaborate at the same time from different parts of the world and with a huge scale. So it's really massive. And they are, I mean, of course, if they are in 97% of the code of the whole world, the application of the whole world, you can imagine that in a lot of critical systems and a lot of critical parts of the systems, open source is there, too. So, open source is everywhere. It has a lot of impact. So, yes. But why it's important for you? Because maybe it's nice, cool, there are other people working with it, and thank you very much, but I don't want. is the case, but I want to just give my pitch here. So, basically, because you can have real-world experiences, so let's say that you still didn't have the opportunity to work for a company, work with IT or data or whatever, and you want to join this industry, like, open source is really good, because you can start having, like, a real-world experience, like with projects that other companies are using with real flow of production, and you don't need to be hired for that. You can start doing it for free, for free, but at least you have the opportunity. You can have, also you can use it as portfolio and visibility. So let's say that you're working in a nice project and then you put that on your LinkedIn or you put that on your GitHub, and then, wow, okay, the hiring manager, The recruiter will start seeing it and then we'll see the impact of this project seeing that it's like real life thing You know, it's not that you just create some code That is I don't know After a tutorial and that you just know to replicate things But no, you know how to work with real life scenarios and then this goes to your portfolio and shows visibility Gives visibility Also, this is super nice, like, when I created this kind of API, that is the project that we are talking about today, it was in 2019, and from there, like, I had contact with so many people from so many different parts of the world. Like, for example, there is one guy that is still with us, working since then, that he is from India, and we started talking, and then we have a lot of exchanges about the both cultures, and it's so nice, And it will definitely not be possible if I was not working with open source or with CanAPI in this sense. So it opens a lot of opportunities. It connects a lot of people. And you go a bit more abroad than what you would do if you were only working in a company, like in a private codes. And also it helps you to give, like, because you have to do everything. like depending of the open source projects if you created one from scratch for sure but you need to you have like some management tasks you have some collaboration tests that you need to engage a lot communication and because of that you start like getting more real life experience and then this gives you like confidence and helps you also to get this sense of ownership responsibility of the things that you are creating because these things are out there in the world so people can see it. And another thing that maybe if it's still not a thing for you, maybe you can think about giving it back to the community since we are using open source projects all over the place and a lot of them we are not even paying for it. There is open source code, I mean, software that they are paid, but a lot of them not. So, it's a really nice way to give back to the community, like working in different features or projects that afterwards other people will use too. So, talking a bit more about CumbucaDev, because this has everything to do with it, that we created like CumbucaDev just I mean, initially because of this, because there were a lot of people that were coming And saying like, hey, I want to have a job. I want to have like an opportunity, but I don't have experience. And since I don't have experience, I cannot have a job. So I don't have the opportunity. So then we have like this cycle that we are there and we cannot break it. So the idea here is that with open source, we can break it in. So we start bringing this person to have real life opportunities, working with production code, and then also having network, knowing more people, having more contacts. And then afterwards, it starts getting more and more experience. And then afterwards, you can get your job. So this is what we try to do. This project started with me and my cousin. My cousin was doing the transition of the career. and she wants to get into the area, the IT area. And then I started using open source as a tool. We saw that this was working and said, okay, we can do this with other people. Because usually when you're starting, what happens is that you apply for a lot of opportunities and sometimes you don't even receive an answer. And here, when we did this methodology, it was like the other way around. People, like hiring managers, were starting reaching out to her because she was already contributing. So she was not even needing to apply for the opportunities she was already receiving, like on her personal email or so. So, yes, this is like, it was the first real motivation for creating the CumbucaDev organization. Okay, contributing to open source. Let me just see if I have some water. I hope it's going to mute now, otherwise you're going to listen to me drinking it. Refreshing. What are the chances of this bottom being right? Well, let's pray for the best. Okay. So, contributing to open source. Let's say that you listen here, all these things that I was saying, then you pay attention, and then you decide, okay, sounds nice, I want to join, I want to contribute, show me the world. So here is our first tutorial. It was a small one. That is, we created this repository specifically for training. So it's called Git Cows, because the idea is for you to create cows. So you don't need to be, like, afraid of breaking anything. The idea is just for you to get the practice and understanding how to do your first open source contribution. Okay. Now, it's time that people, if you want to do the tutorials with me, now is the moment that you are going to scan this code, and we are going to do together this first contribution. Does someone have any questions so far, all good? Okay. Okay, so let's go to this one.

Speaker 1 [22:05]

No questions here.

Speaker 2 [22:07]

Nice Okay So here is the repository So what we usually do when we are going to work in an open source project that is from someone else Because usually this is what happens, right? You don't start like creating an open source project from scratch. Maybe if it's the case It would be an exception. So I will go with the most standard way Anyway, so here is like the readme file, right? So here is where the source code is stored, and we have like the readme file that will give usually the instructions about this project. A lot of times these instructions are about how to use the project and not how to contribute, so that's why we have like one specific file for how to contribute. But in this sense, let's start with the readme, because this repository is specifically for teaching, so it will already contain some information for us. So the first thing, you arrive in an open repository that you want to contribute, you read the readme. I mean, the name is quite gives an idea, right? So here, if you are afterwards at home and want to read it quietfully, calm and peacefully, okay, I will just going to explain you so then we can go on. So what is open source? I already just talked about it. So there are some patterns that we follow when we create open source projects that this This helps people to know how to contribute and to know what are the things expected. So the first thing is this, that we have the readme file that contains usually the instructions about how to use the project. The second one is the contributing. So the contributing one is the one responsible for giving the instructions of how people can contribute with code. So, how people can add commits and add changes there. So, this is contributing.md. Afterwards, we have also the file called license that defines exactly like what are the things that are mandatory to follow if you want to share this code or modify it, and also all the commitments that you have with this code. Besides, you have code of conduct. I mean, it's not that all open source projects, they will have all these documents, and also sometimes they have more. But this is like the most standard, but license, yes, I think that's like a really needed thing. So code of conduct is more to talk about how are the things, what can be done there and what can't, what is the best way to act there, to behave there. Because also you need to think that you're talking with people from different parts of the world with different cultures. So when you're creating an open source project, you need to be aware that there will be different interactions. So you need to be kind of safe in a place that you say, like, okay, this I'm not going to tolerate in this community, and these are nice things to do. So the code of conduct is similar to what we have here in the conference, but this is like for open source project. And okay. So then the question is from where do I start? What should I do? I already read the README. Sounds amazing. So now you need to go to the Contributing. The Contribute file will tell you how to contribute. So here you go. And if you go here, you click on Contribute. Yeah, you can see here that there were the other files, so Code of Conduct, Contributing, Readme. Let's go to Contributing. So yes, we already made the first part that is like finding the Contributing file. That was hard. And now we need to follow these steps. So we have first, so before you start, here is like if you don't have any clue about Git and GitHub, here are some resources that are nice for you, that you can use, that you can read more deeply before going to this step. But yes. Also, what is version control? I mean, these are like basic concepts that we will need here that if you don't have it, maybe you need to go a step before and then come back here to be able to contribute to open source. OK, what is GitHub? So I'm assuming that we have all this. And let's go to the task one. So this one is like practicing on your own. We are going to have only one task of this tutorial, because then afterwards we go to contribute with ScanAPI directly. This is more just to have some idea. So first you, wow, a lot of steps. Okay, first you create your GitHub account if you don't have it. And then you need to install Git, okay? And then you need to fork the project. So here is like when you start something that is different usually from the other projects. When you are working in a company, usually what happens is that you enter in the organization and they invite you your username, like your user account from GitHub to join this organization on GitHub. And there they give you like the access to do whatever you want with whatever they decide that you can do with the code so that you have like right access and some subset of repositories that you have read access to all the repositories, so on and so forth. But you need to think about it that like if you are working with an open source, anyone in the world can contribute with your project right so then how you would like know if you could trust in a person to say like yes you can write in my project go for it if if the person not even try to contribute before so the fork uh functionality was created exactly for this for making it possible to people that are not yet part of the organization to also contribute. So, what happens here is that you have, like, the main project here. So, it's the one, there's the official, everything, like, all the features go there. But then you want to contribute with this repository, but you don't have access. So, what happens is that you make a fork. So, you make a complete copy of this project in your account. So, It will be not anymore here, for example, it's like github.com slash kumbukadev slash gitkaos. So then you're going to create, when you click to create your fork, it will be github.com slash your username, in my case, kamilamaya slash gitkaos. So you create a complete copy here. Then you make your changes. You do whatever you need to do. And then you say, like, hey, now I want to send this change to the main repository. And in this point, we open a pull request that is like a request to pull these things here. And then I mean pull the main things through here. And then you can start contributing. So you don't need to have access of read and write in the main repository before even starting contributing. can do the contribution up front. OK, so let's go. I think I will open here my Firefox. Because here I'm with another user. I'm with the user that is from Kumbuka Dev. So now I will create a fork. So for creating the fork, what I need to do is just come in here. This is the main repository. So it says, com.bucadev.gitcals. And now we are going to click here on fork. And then we have here which account, because sometimes you want to create your fork in another account if you have more than one. Here we have only one. So we are going to create here. So it will be a copy of it. And you see that already the description is the same as the original. It comes by default. And then you can also choose like if you want to contribute if you want to copy only the main branch or everything so here let's go with only the main branch so now github goes and work for us creating this new repository that is completely it's a complete copy okay so look here that now we are not in the main repository anymore we are in this new one, and now this was like a really new change, I don't know, last month maybe, that they put finally like a sign here to an icon here to show that this is a fork. So there is like a fork icon. So this shows that this is not the main one, and if you want to access the main one, you go here and you go and you see that this is your repo or repository it's public but it was forked from the Kumbuka one so if you click here you go back to the original one but we don't want that we want to go with our fork I mean just okay have here so we already learned what is a fork why use fork and how do OK. Now we need to clone the fork. So far, any questions?

Speaker 1 [32:33]

I say no from here.

Speaker 2 [32:37]

I don't know if this is good or bad, but...

Speaker 1 [32:39]

anybody Yeah, yes Okay, um, thank you for going down it was hurt

Speaker 2 [33:12]

So that's it

Speaker 1 [33:13]

That's it, I don't know. So give us a minute. OK. Perfect. What is the difference between a fork and a feature branch?

Speaker 2 [33:48]

Okay, good, good.

Speaker 1 [33:48]

Thank you.

Speaker 2 [33:50]

So for you to create a feature branch and being able to send this to the main repository again, you need permission of write. So even if it's not in the main branch, if you are writing something in the same, the original repository, this is going to be like something that you need to write, like you need the access of write. What you could ask also is like, okay, but maybe you could invite people to your organization and just letting them create features or creating or editing the code in a branch, in a separate branch, right? So then you would resolve, like solve the problem because you don't need to do a fork, but then people can create new branches. But the thing is that that's from security is still not like the best option because that could, I don't know. If someone changed something and then gives the wrong permission to the person, and then the person can merge to the main or change main. And also it would be kind of chaotic to think, I don't know, let's think in a project that has a lot of contributors, like, I don't know, Firefox, for example. Imagine that you have like any person can go there to the main repository and start creating branches. so that would be like a bit chaotic for managing these branches and also to managing the permissions to ensure to be sure that all these people are not having the wrong access so far in this sense is more like it's the standard practice because of this so I hope it answered a question let me know if not

Speaker 1 [35:40]

We have another question.

Speaker 2 [35:42]

Okay.

Speaker 1 [35:42]

Okay. Immediately after forking, an email was sent. Create task number, sorry, create task one.

Speaker 2 [35:52]

Yes, thank you.

Speaker 1 [35:52]

Yes.

Speaker 2 [35:53]

Thank you.

Speaker 1 [35:53]

All jobs have failed. What does it mean?

Speaker 2 [35:56]

If all jobs have failed, it doesn't sound good. But I will show you afterwards. This is because there is an automation. It's part of the tutorial. So I will show you now this. So it was a spoiler. Nice. So we have, like, here one automation that is done via GitHub Actions. And mainly what you need to know is the moment that you click on fork, we are creating under the hoods one issue for you. So one ticket. So you see all these tickets here, they were, wow, a lot of people look, woohoo. A lot of people seems they're checking the tutorial and trying to fork too. So in this moment, what happened is that we created automatically one task for you. Why we are doing this automatically? Because usually what happens is that you go in an open source project, you try to find an issue to work, because you need to be sure that the thing that you want to implement is in the needed, right? You cannot go and, ah, we will propose this, and that's it, already coding. No, you have the tasks of the repository and then if there is any task there that is not assigned to anyone, you can get it and implement it. But then imagine that for this tutorial, it would be hard for me to create the issues for each one. So then we created this only for didactic reasons that once you click and fork, already creates the first task for you. So let me see here. So for example, I'm with the Kumbuka here user. You see? This is like what you do all the time. I was in the wrong repo because I was in the repository, my repository. And the real one is the other. So this. So then I'm going to see that an issue was created here. And then there are a lot of here other people. So I will find the one that is with my username. You could also try to find here, like you put your username. So it seems that I don't know my username. Jesus Cumbuca, Jesus Christ, I think it should be there, right here. this go to issues here and then you find your task so let's go back to what we were doing before then it was saying that all the workflows were failing I don't know what this because for me is creating the task I'm talking about the question that was made but let me know if the issue was not created for your user. If you click and fork, and it was not created. Okay. So, then let's keep going with our task. Go to task. So, we already did these parts of, like, creating a new, finding, no, no, no, no, clone or fork. Okay, so now it's the time to get the information, like getting this repository copy into your computer, right? Because you're going to make the change in your local environment. You could do that directly on GitHub too. I'm just showing you like the hardest scenario, like where you need to run things in your machine, but it could be also possible to do it via GitHub. So what do we need to do now? It's clone. so we have there the copy repository that is on github and you want to bring this to your computer so like hey i want this code and all these things here in my computer so for that you go and you use git clone your username and git cause because this is like your new um your new repository your new repository so then and then you go and click here oh so let's see and then i here i change for the one that is my you can also go and put like this let's go to the fork one So to go to your fork, you need to go to your repositories, and then you go here, and then you find your copy. So see here that there is git calls, but it's also saying that it's a forked from. Okay and then here, okay, you can use this to clone. you can copy here. Yes, this probably will not work exactly because of the permissions I have, but I will just show you up front. Okay. So I put git clone and the link that was showing me there that is basically with this username and then you clone so then you when you clone you're copying the whole project to our machine so this means that it will create a new folder with the name of the repository with all the files so if we check it here it's here so this is a copy of the fork okay so if you do git status you're going to see that you are in the main branch and it it's pointing to the fork okay so let's keep going with the tutorial with the tasks now we need to find an issue to work on so this is what i was talking about um you need to understand what the project is needing maybe if you have an idea of like a new feature or something or you saw like there is a bug The most common thing, the best practice, is not to go and implement it directly. You go and you open an issue. Then people from the maintainer team will check if this makes sense or not, if it makes sense with the roadmap they have. And then once they say... And then you say, like, you can create the issue and say, like, hey, I want to work with this. So you ask for the assign. And once they give you the assign, then you can start working on the task. Because otherwise, a lot of times you can create all the feature, like create the whole feature and send the pre-request, but then they will say like, oh, hey, no, we are not needing this. So you are going to do, you did that for like nothing or at least not for the main repository. So for this work, as I told you, like it is creating like a, created a task for you. And then we go to the task to see what we need to do. So here is the issue. Let me refresh here, okay. So this is the issue, and I need to follow what is asking here. So the first thing that is asking is to create a file. So you're going to create a file in this folder, call it calls, and you're going to do it inside the other folder, call it task one. So for this, let's open the code editor. So if you see here, let me close Copilot. Here I hope you can see. So this is where we should create our file, okay? So it's inside the folder cows, inside the folder task. We found where it should do it. And then we need to first, we need to create a branch. So we have this task here. This is also something that happens a lot in an open source, is that usually we use the number. I mean, there are different patterns, but this is one of common ones, is that you use the name of the branch with the name of the number of the feature, the number of the issue. So for example here, the issue that was created for me, is the number 20. You can also see here in the URL. So what happens is that, okay, when I'm going to create the branch, instead of saying like feature, blah, blah, blah, fix this, blah, blah, choose make like a pattern, you use the number of the issue. So you would do like git, and then you have the command here, git checkout, or it could be git switch also, so it's like to create a new branch, and then a branch, and then you put the number, no, what is the number, 20. So now we create a new branch in our fork, so it's still in our fork, with this, that we will implement the change, okay? So now we can keep going. So here it says, like, okay, make your change. Change the things that you need. In this case, we are going to create this file that is being explained here. So you need to create a file and add some content. It could be like saying hello and goodbye or whatever. So we go here, we create a new file, and we'll be with the username, wow, we'll be with the the username, so here. So then we create the new file. And then we can write like a content here, right? So, we put, like, I don't know... Whatever. So, this is, like, what you need to change. So, look, that is not something about code. It's just about knowing how the whole process should contribute. It's just for practicing this. Okay. And then, afterwards, We are going to add this, we added some comments, we are going to save the file. So here, I'm pressing command S, or I can go here also and put an archival, like file, and put save. But we save the file, and afterwards, this is like the ticket itself is done. So usually this is what happens, like the issue will only ask you for doing the change, like it will only give you the instructions to do the change. But all the whole process, you need already to know or you need to read in the contributing to know what exactly you need to do. So like forking and then cloning the fork and then open a new branch and all these things. So okay, we did exactly what the issue was asking, but now we need to send to the repository, the first repository so then we can open the um we can open the the pull request okay so now it's time to save on inside the git right so then we have this information in our version control local so we can so if you do git status it's saying that we have this new file i will add it so git status again we have this new file i will probably and then the next step is to commit so telling what we are doing and here's another thing that is i'm not special for our open source but uh but it's always good to remember is that when you are starting to work in a repository that is from other people, you need to more or less act like, for example, when you are starting, like when you go to someone's house, someone else's house. You need to understand more or less how are the rules, you need to check, and then you need to try to follow them. Especially because if you're not following it, they will not accept your changes. So, for example, for a commit message, you might have like a, I don't know, a better, a way that you prefer the message, I don't know, I like to start with capital K, I like to use this pattern, but what you usually do, like an open source, this is for commit or for any other thing, is that you check what people are doing already. So you check, you see the commits, and then you'll see if there is not an explicit instruction in the contributing, you try to follow the patterns that we have there. So here, I'm going to use this one, that is git commit message, add, and then the name of the file here okay so now I saved this change in my local version control and then I need to push my change that this will not work here now exactly because I think I don't have the permissions for this one but it would be like now you do this git push origin and And then you put the number of your branch. Now it's 20. And then you send it. Okay. I will not show this because I'm not here with the right user. I can show you afterwards if we have time. But then it's like why pushing? Basically it's because you want something to be also available in the remote place. You need to have this code in GitHub. So then, again, you have like the original repository. We made the copy of it, so it's the fork. We changed this fork in our local machine, and now we want to send this change to the fork again in the GitHub, so then we can ask, hey, we want this change to be added here. So this is the process. So then you create, and let me see if I will have the, if I have configured or not. Let me see if I can get one really quick here. I already know what I'm going to do, maybe. Going to create with this one that I already have the rights just to, but I will create with another name. you create a new fork for the user that I had already okay no can I cannot do two forks maybe I can do delete my fork wait we'll come here just because for for the tutorial already have created a fork so then it's saying like hey you already have a fork stop creating forks and going crazy so i will just for now delete this yes i want to delete because i want to create it again mm-hmm okay it's good because then I will need to do the process again it's good to reinforce the idea okay so repository I go here to get cows and then I will fork now it's gonna work I'm gonna click here I'm gonna delete this this old one just so then we can do it we can do with the right one okay so I have my fork now probably then I have already a new issue created for me yes there is this one so then let's go I will come here I will clone first right so let me go back to my fork I will clone it we'll go copy git clone and then I put the thing now I will have all the permissions so now I have the folder here I will enter okay and now I can do my task that was to add the Camila Maya file the thing that I'm going to do different here is that okay here so then I can come here dogs cows there is already a Camila Maya file I will create another one just for so I would come in on my file hi again okay so I created this new file and then now we're gonna do exactly what I was doing before that is like adding this difference and then And I'm going to commit, I think I have it already here, it was add, so it's saying which file I'm adding, perfect, now this, and now I'm going to push, okay, git push, yes, okay, So just git push works. And then if I go back here in my account, and I click on git cows, it will go to my fork here. Let me see. Here I go to the fork, and then I have like one commit ahead. So which means that now we are like talking only about things that are already in the GitHub server. And what it's saying, like, in the message, it's saying, like, hey, you have a new change that is in your fork, but is not in the original one. So let's create, let's, if you want, let's create a pull request to ask for this change to be adopted in the main one. So okay, we can go, we can go here, for example, I didn't create the branch. No, I didn't create a branch. Okay, anyway. So here, now I can click contribute. It's okay if I didn't create a branch. The branch is like only usually to give more organization. But since the branch is created in my fork, like for the main project, it doesn't even matter, right? For the main project, what matters is that it's coming in one change that is from an outside project. I'm not a collaborator. So you create here, open pull requests. So here is where I'm gonna tell the people, share about my change with the people, right? So then it says like, add Camila Maya to text, and then if we go here, let me get my ticket again. So, Ah, no, it was in the tutorial, sorry, where is the tutorial? Okay, so we were in commit your change, push. So then let's create the pull request, so it says that we should add the title of the request with this so let's put it so it's task one and then on the name of the file so this is the title of your proposal change and then then you need to add a description so this is a nice thing from github that if you mention here that you are closing a specific issue, like, for example, ours is 5-1, was it? Yes. So it will automatically close the issue, mark it as done, if you merge this PR, which means that if your changes were accepted, then once these changes are adopted by the original one, then that issue will automatically be closed because it was already solved. so for that we use this word closes and here we describe the change in this case just this is okay just putting the right name so this is like for people that will review your change imagine that you are in the role of the maintainer so someone else someone from outside is proposing a change and for that you need to understand what the person wants right so it needs to understand which issue this person is trying to close, how is the strategy they are using. I mean, you're going to see the files, you're going to see the code, but this, if you have a good description, helps you a lot to make it clear what you want, and then the chances of the maintainers who accepted it at least a bit quicker or they will at least accept it at some point are higher. So then you put here, you don't need to fill anything else, then you click here to create the pull request. So if you want to see, these are the changes, this is the commit, and this is the new file. So you click here, and that's it. So now you created a pull request. So if you see here, there are a lot of other pull requests here, but if you, I didn't change the name, no. Where is mine? I didn't know, what was the name? I can filter by mine. OK, so here. So here is the pull request. And then, what do you need to do next? Like, usually you wouldn't have the permission to merge these or to accept this new change in the original because you didn't have even the permission to write in the code, right? So this is like, once you did it, like you open the pre-request, you wait. You wait until people interact with you or they accept your changes. So there are some times that I will say, like, hey, it's good, but you need to change the name of this file from this to the other, or you need to... And then you're going to talk with the maintainers to understand exactly what you need to change and how you need to change. And this part of the communications is extremely important because you need to think that you are inside the other's house, let's say. So you need to be nice. and maintainers also need to be nice in a way that if these communications goes well the collaborations probably will help will happen more often and in more soft tools so um so basically this so for example let's see here that we have one per request let's say this one i'm not so it's It's then, now I'm in the role of a reviewer, okay? So a maintainer. So I'm checking here. It says what it is. I can see which one is the issue. Yes, it's the right one. And then here I can go and say like, hey, I accept this change. So I'm the maintainer now. I approve. So that's okay. Everything is passing. Everything is green. and then I will accept this change in the original project. So now if you go to the original project and you check the new files, for example, you are going to see that this one that we just merged is there. So this was the whole process. So you go, you enter, you clone the fork that you made, you do the change, you send this change to the fork, and then you open the pull request. When you open the pre-request, the ball is on their court, so they need to interact with you, ask for change, accept it, or merge it directly. Okay, so it was hello and goodbye, hello. Okay, so this basically is like you just did it, your first open source contribution. So once it's merged, it's merged. and yes and it's nice because then afterwards people will see that you contribute to this project of course this one is specifically is a educational one but the idea is that now we will be able to also start contributing with scan API. Questions so far?

Speaker 1 [63:40]

Yes, I have four questions, most of them related with branches and forks, so yeah. But using the main repo instead of forked, sorry, but using the main repo instead of forked repo inside companies is fine, right? Because in a company there are not that many contributors in competition with an open source repos, right? Plus, the company's repos are private.

Speaker 2 [64:14]

yes so yes it's completely fine like i mean if you are in the in a company and you have already the access to write usually you would expect that people would just interact directly with the original one uh the upstream but if you can i mean if you want you can like create your own fork and i mean if you're going to create a fork it will be also private it will not be public so this is something to be aware and then you can create your fork and then create the changes and then send into the to the main repo it's I mean it's not needed but if you want if you already used to the process and you're happy with it you can also do it

Speaker 1 [65:04]

Thank you.

Speaker 2 [65:05]

Morris.

Speaker 1 [65:06]

Next question. What is the difference between private and public project? If I can't create a public project, does it mean that another user can modify my code or my branch?

Speaker 2 [65:24]

So public repositories are basically the codes that they are available for everyone to see. So you have this URL of your repository, and if you share with anyone, the people will be able to see it. So this means that it's public in a sense of people can read. But it's not because people can read that this means that people can change it. it. So for someone to change it, you have two options here. If you want someone to change your repository, the first option is you invite this person to also collaborate in your repository or organization, so you go there in the GitHub user interface, and you add the user name of the person, saying, like, hey, I want this person also to be able to edit the code, or person opens a pull request exactly this way that i said that i should so there is no way that someone will change your code if it's not in this way if it's not with one of these ways i mean the person can also like make a fork and not sending this this new change to your fork like can like keep going with their own fork this is also completely okay but again you need to see if this follows the license rules, right? Because sometimes there are projects that it will say, like, hey, no, you cannot modify it if it's not to bring it back to the main branch, I don't know, to the main repo. Or if you do that, you need to say, you need to tag the person that created it. So, yes, I hope it answered.

Speaker 1 [67:17]

Since we forked the original repository, do we really need to create a separated branch to address the issue, or do we create it to have an extended explanation of the process in this tutorial? But it isn't necessary, right?

Speaker 2 [67:43]

Yeah, so it's not like in the second time that I did. I forgot and then I just sent it. So it's not necessary. It's a good practice. Because then you have like your own copy also using the best practice. And then you don't mix things. Because at some point you can start like putting in the main. I mean, nothing that you are going to do there in your fork will destroy the thing from the original repository. So this is like one thing that you need to keep in mind. because it's a good thing, right? Especially if you are not that confident or so. It doesn't matter. Let's say that you want to start contributing to Firefox and then you go there, find an issue, and then you create your fork and then you go and, I don't know, you add a bug there, then nothing's working. This doesn't change anything like in the original one. It will only change if you request these new changes to be added to the main and someone inside the organization accepted it. So then there is a lot of responsibility also in the people that are reviewing the codes and the maintainers that are checking for new codes. So this was separate. What was the question? Did I answer?

Speaker 1 [69:03]

Yeah, give me a second. I can read it. Sorry. I think you did. Okay. Since we found the original repository, I am repeating the question, no? Since we found the original repository, do we really need to create a separating branch?

Speaker 2 [69:21]

Okay.

Speaker 1 [69:22]

Yeah, to address the issue.

Speaker 2 [69:22]

Yeah.

Speaker 1 [69:24]

No. Or do we create it to have an extended explanation of the process in this tutorial? Yes.

Speaker 2 [69:32]

no one else hey cool

Speaker 1 [69:37]

Okay, give me a second. Yes. Yeah, next question would be, should you always open pull requests to merge from main of your fork to the main of the original repo? Or is it also fine if I try to merge from feature branch of my fork to the main of the original repo. I can repeat it if you want.

Speaker 2 [70:09]

No, no, I got it. So the thing is, like, the people are, like, the maintainers, they are not caring about what you do with your fork, like, in terms of branches. Because for them, it's like, it doesn't matter. It's like, you organize your things the way you want. The important thing is that these changes will go to which branch of the original one. So if you want to create a lot of branches, naming it all wrong, going crazy, that's okay. The thing is that usually, like, you try to follow the rules, so then they accept it, so then they will, like, these rules, like, for example, of using the number of the issue, this helps people to see and connect things easier. So then they will probably take shorter to review your PRs, and then probably they will accept it. But no, you can create it with any name, any branch, even in main, or with feature blah, or with the number of the issue, and then you request for it. And then also, if you want, you can request a fork to be, like the change to be sent to another branch of the original repository but then it's like a more complex workflow and i don't know if this would be necessary but it's not because it's not always to the main you can you can choose from the both sides

Speaker 1 [71:39]

Another one on this matter, can I fork any public repository, or are there also public repositories which are not forkable? Because I don't know, maintaining, for example, don't have time for reviewing potential por recuestas, etc.

Speaker 2 [72:06]

Yeah, so I think that in GitHub, at least, how is it configured now? Because, again, fork is a feature from GitHub, not from Git, right? So I think the way that it's configured now is that all public repositories are possible to fork. But this doesn't mean that all public repositories receive pull requests. So there is, like, one option, I think, there that you can say, like, hey, I don't accept. I don't know. I don't want issues. I don't want pull requests. So then these tabs will not appear. But the person can have the fork and, I don't know, be happy with the code. But also, if there is a license, even though the person needs to follow. But as far as I know, I don't know if there is an option to not allow fork. But I think it's always there.

Speaker 1 [73:03]

Thank you.

Speaker 2 [73:07]

Next question. OK.

Speaker 1 [73:10]

forking from github to gitlab the same as forking from github to github what are the differences and specifically how do github actions workflows translated to gitlab cicd pipelines

Speaker 2 [73:30]

Then this is another complete separate subject that I think I'm not going deep in this one. As far as I know, I don't know about GitLab, but I think you can only fork there inside GitHub. I didn't know that there is this feature, if there is. Even less how the pipelines are important. I don't know. Here we are talking about only forking inside GitHub. So GitHub fork creates a repository in GitHub. But yes, I don't know if in the GitLab there is this possibility. Maybe there are more things to do, so maybe should I keep going?

Speaker 1 [74:19]

One last question, so for now? Yes. Oh, sorry, I just lost it. Here. If I would like getting involved in a project, do you have any tips on how to find a suitable project on GitHub to start with?

Speaker 2 [74:40]

Yeah, so this is, like, one question that I always receive. So there is one specific project that we are working in Kumbuka that is, like, to try to map, like, the repositories, open source repositories, and then you can log in and make a filter saying, like, hey, I don't know, I want the Python repositories that they, I don't know, are written in Portuguese and blah, I don't know, with these things. You could ask why you're not using GitHub. My opinion is that the GitHub search is not good for this. It's really hard for the discovery part. So since this project is not working yet and GitHub is not the best solution, I would go to things that you like to do, like things that you use already. So a library that you're already using or a project that you want to know a bit more of the stack. or it's a subject that you are interested to. So I would go more with these things that you already have in contact with them. And then just starting seeing like, okay, maybe this Python package that I use, they are with open issues. So let's check there. So I would go more with more this direction. Thank you. Thank you. So let's go because we didn't start even talking about scan API. So, ScanAPI, it's basically, I created it when it was, like, 2019, and it, and the idea was created, the idea happened when I was working in a startup, and I was having a lot of problems at the same time. Let me see if this is presenting. It is presenting. Here. So I was the person in that week responsible to solve all the operation problems and also all the bugs that were being reported. So I had this role in the team for that week. And I was having a lot of problems, and I figured out that they had some kind of patterns. So the first one that there were a lot of integration errors, that could be coming from the client or coming from the front end. So let's say that I'm consuming an API that was, for example, I was working in a logistic company. We have like a tracking API that was giving the information about the trucks, where they were, like the geolocation, if they were on, and the engine was on, and so on and so forth. So we are consuming this API. So we were receiving some errors because the API changed or something changed in the documentation, and they didn't update us, so our system was breaking. or even problems that were integration errors, too, but related with the front-end. So we, from the back-end, were changing the API, maybe, and not telling the front-end, or our documentation was outdated. So, yes, this was another thing. Outdated documentation from APIs, so sometimes missing endpoints, sometimes missing fields, and sometimes having misinformation, like saying one field is one type and it's not. So, we were facing these problems for both the APIs that we were building, but also for the APIs that we were consuming. So, and also another problem is that I was working for this logistics company, and we have really hard, really complex scenarios. Because let's imagine here this example that is for an airline that you want to book a seat, okay, like in a system. So let's say that there is this endpoint that is it is slash book slash the number of the seat Okay, so let's say that someone for operation calls me and say like hey This button is not working and the button calls this endpoint. So then I'm like, okay Let's try to reproduce this error But in a development environment, right because I cannot report I cannot get the same thing to investigate like in production because I can break things so I need to reproduce it in a developing environment so I can test things okay so then I need to call this endpoint but for calling this endpoint probably I need to pass like as in the body of the post I need to pass for example which flight it is right or for example which airplane because an airplane could have many different flights and during the day and let's say that okay it's booking a seat but for whom so I need to pass the passenger ID and is this airplane available or not so to recreate these scenarios like in the database was quite hard because this was always like a chain of requests that were being made like so the first request you do you create the passenger so then this is saving and then you So afterwards, you create the airplane or before. So these things are like a chain of requests that made this database in a complex scenario and really specific. And with this specific scenario, when you try to book the seat, it doesn't work. So how can I recreate this for testing? So then I was like, this week was terrible. I was fixing a lot of bugs. And then I started like, no, no, no. I need to create something to solve this. and I was with open source in my mind. I was trying a lot of different tools on open source, and then I said, okay, let's create an open source tool. And for that, I created the ScanAPI. That is this one. It's basically an open source framework, testing framework, where you use it via command line, so you write commands in the terminal to interact with ScanAPI. And then it's written in Python. And what is it for? basically does two important things the first one is you can implement integration tests so you can validate that the api is doing exactly what it should do and the second is that as consequence of it it generates a report that say how that says how healthy your api is basically saying, hey, this endpoint, all these endpoints are running, these were the expected results, the status code was expecting to be 200, it is, and so on and so forth. So you have, like, a clean image of your current state of your API. So, basically, for a scan API, you have to write some specification to say that, okay, my API is like this, so this is the base URL, These are the endpoints. And then ScanAPI goes, and then you tell ScanAPI, ScanAPI run. So ScanAPI goes, run, and for each endpoint, it go, hit the endpoint, calls it. So that's why it needs to be done not in production, because otherwise it will change the database. And afterwards, ScanAPI run the test. So it checks that what the response received was in what you were expecting. And then afterwards generates this report in HTML. Okay. So let's go with an example. Let me just check my time here. Have almost nothing. So probably you're going to have a lot of homework. So this is the, for example, we are going to use the Poke API, okay? So it's this API, if you want to check one response, for example, one endpoint is like you can go and poke API, API v2 slash Pokemon, then it will list all the, I don't know how many Pokemons that we have now. But yes, let's see this example here. It's let me see if I have the laser thing. Do I have the laser? Okay. So yeah. OK, I do HTTP in the terminal, calling the library request, and then it gives me all the information. And this is the body, the response of that request if I do it with HTTP. This is like the Pokemon list in order of, I don't know, like first is Bulbasaur and the real order of Pokemons. OK, so for installing ScanAPI, you just And that's it. It's a Python package. And how to use. So first you create this API specification. And here is like an example for testing this first endpoint. So we have the first. You define the name of the API. Where is it? Okay. So you have the name. And then you say the base path of the API. And then afterwards, you start listing the endpoints. So in this case, its first endpoint would be Pokemon. And then afterwards, you say, like, which requests you want to make in this endpoint. So it's like the final path. So for example, here, what scan API would understand that, okay, I need to hit this This path that is like, let me put this here. This path that is like pokeapi v2 slash pokemon slash. There is one more. And then here is the name. So the name is a concatenation of the first node and then the second node and the third node. So it's like pokeapi slash pokemon slash listall. And this is like the same one we're doing here but for the path. So it gets the first thing, and then it concatenates with the next nodes that come inside. So with this, ScanAPI calls this request and checks if it worked only. Now here, there is no test. So if you run this in the terminal, so ScanAPI run, it will check, and it will say, like, This request was made, and this is your report, so this is the results. So if you open it in your browser, because it's an HTML file, you're going to have like this, like a report saying this was the request that you did, it was 200, it passed it because there is no test so far, so we didn't have anything to fail, and there is like a summary in the beginning, saying what passed and what didn't pass. So then you can open this request in the HTML report and see more details. You can see all the headers. You can copy and make a curl with it to recreate exactly the same call in your terminal. And you're going to also have the response here, that if you open the response, you're You're going to have exactly the same thing that you had in the terminal with the list of the Pokemons starting with Bulbasaur. And there were no tests here because we didn't implement, but if you want to implement, here, for example, is that let's say that for that request list all, that is like listing all Pokemons, we want to start testing, so first we need to add this new key that is test, And then you're going to add each test with two keys. The first is name for people to understand what is going to be test. And then here you put a Python code between this notation to say that what you want to assert, right? So then you put here all the tests. I mean, I will not go in deep this here because we have two minutes for sure. It will not be enough time. just passing, so then it will generate the report, it will show which test passed, and also you can chain requests, so for example if you want to get an endpoint, to hit the endpoint that is slash Bulbasaur, but you don't want to hard-code this name, you can get from the first request the list of the Pokemon, then you get the first one, and then you get the name of this first one, one, and then you create the second request with this name. But, anyway, I will show you a tutorial for learning more about Scan API anyway. But here, just want to talk a bit about the impact of Scan API. We already received sponsorship from Red Hat, New Relic, Lambda the test that now is called Test Moo. And last year, the previous year, we were in GitHub open source secure found. We were one of the 71 projects that were selected. And we had like three weeks with specialists in security from Microsoft and GitHub giving like classes. So we were learning and applying everything to the API. Here's a podcast that we recorded in the GitHub universe about how was the project, how was to be part of this fund. So, okay, here is also, like, open source initiative. Yeah, last year, they invited me to talk about, like, my journey in open source. That includes a lot of stories about Scan API and Cumbuca. So then they create a book with the 50 maintainers that they selected. So if you want to know all the story behind about it. And also if you really want to learn about Scan API, you can go in scanapi.dev and there is a tutorial. So then you can first understand how to use Scan API. Here is the code of the... And then here was contributing to Scan API. I mean, that would be the second part of the tutorial. Then we won't have time. But here, then you will follow the same idea that we did for the Git calls, but here with a real project. So you're going to start following the contributing rules. I need to finish now. Okay. In two minutes. And then here, so here you're going to learn how to contribute and open your first pull request. There are already some issues there. There are market with label PyCon that you can get. And then here, every first Friday of the month, we have official office hours from Scan API. So if you want to contribute and if you want to collaborate, just join us. It's a Google Meet. We talk about what we are doing, what is next. There is no closing. Give a star for us, github.com, scanapi. It helps a lot for people to see our project and increasing the visibility. How to support Scan API. So if you want, share, share, contribute, give money, so that's it. Here is about Combucadev, the same. So it's a Brazilian project. If you are interested, the idea is to help a lot of people from the whole world, underrepresented people in general. So QR code if you want to talk about it, same like let's talk about Cumbuca, and we have some sweets and some stickers for people that want to get. We have plenty of them, probably for one of each, for each, that is like with stickers and some sweets from Brazil. So afterwards, if you want to go here in the first row, we can share. And thank you very much. It was a bit quick, but thank you very much.

Speaker 1 [91:26]

Thank you, Camila. So you guys, don't you forget to go to the booth, subscribe for the lightning talks. Yeah, and thank you. Thank you for coming. Thank you, Camila. Thank you.