 Hello. Today is April 26th. We are recording the meeting of the Shekut Africa contributor. So we have several contributors on the call and we will just go through the updates, talk about the close down of the event and then just agree on whatever you want to discuss. So, yeah, I'll probably create a meeting notes just in the bottom of our running doc, if everyone is fine. I have no permission to edit this doc, but it should be okay. So yeah, just close down the event, empty a corny, maybe a quick progress updates. Okay, so let's start from updates by students. Is it fine with everyone? The sound was very bad, I don't know who torque I didn't get. Yeah, me neither. Lucy is away from the keyboard. Anyone else? Okay. I think what we can do, let's, you can just type some notes synchronously. And yeah, let's talk about the close down of the event. So, April 30 is the last day. And it's just a few days left before that. So I wanted to quickly talk what is the best to do during the last days. And actually the best thing to focus on is finishing your work because all of you have multiple open pull requests. So it would be better if you focus on channelizing them. So instead of creating new pull requests, etc. Let's focus on delivering what has already started because it's better to complete less but to deliver that to Jenkins users. So my recommendation would be to do that. Yeah. Yeah, so I'm always making a lot of typos and I just woke up. I think we have seen from my video. Yeah, and the second thing I suggest. Yes. So regarding that, I'm actually currently working on HTTP request plugin, and I should push the tests at noon. So are you saying I shouldn't push again? No, you can push whatever you want. So again, it's a focus on something. So for example, if you have five open pull requests and the ball is on your side, for example, you need to make updates. So I recommend to focus on that. If there are open pull requests, which are missing pull, which are missing reviews. Again, consider focusing on getting reviews, ask help from the community from mentors if needed, so that we could get this pull request over the line. If you want, you can totally submit new pull requests. What I'm just saying that it shouldn't be the top priority in this stage. Okay. Another thing which makes sense to consider that again, we have several days left, what we usually do after such programs, we do have a blog post with a report from the event. So for example, in this case, it would be a blog post on Chicago to Africa. So many of you have seen the Jenkins blog, and basically we would need some content for that. For example, yeah, if you want to share some experiences and provide some quotes. It's what you can do. So maybe in a synchronously just by suggesting in this Google Doc. So for example, I will create a section in the bottom. Let's say, for example, anyone or mentors and students are invited to just put their notes there, for example, suggest my change, you can just put your feedback like that. And actually, we can have two items. So for example, let's finish with this part. Have you wrote, have you written short testimonials before? Okay. I can provide some examples. We have similar feedback for GSOC. So there is a Google Doc called GSOC User Elementor Testimonials. We started just several weeks ago. You can find some examples of feedback we collected from participants. So you can see that this feedback was collected in video form or in text. You basically can do the same or whatever you prefer. And so why we collected this feedback is because it's really helpful and it helps us to improve. So just if you could create a short quote, it would be useful. So I will put examples here. Again, you shouldn't take much of your time. So it's just when you have some time. Talk about your experiences and maybe more important part which you will need to do. Again, not now, but gradually is retrospective. So if you work in agile environments, you may have seen that teams joined together sometimes to discuss what went well, what could be done better. And it's a very good practice because it allows the team to iterate and improve how they collaborate with each other and to improve their processes. For each program we run in Jenkins, we recommend to do a public retrospective. And we basically invite everyone to submit their experiences for three items. So what went well, what we do better, and the action items. So how it works, everyone is welcome to just get really short quotes. For example, I want to say what went well and what could we do better. For example, we had something like that. And yeah, this is rather good experiences. So usually they don't require too much discussion, but for example, there are things we could do better. And this is also something we can add. So for example, I can say that it's better engagement with wider Jenkins community. And just example of a feedback. And for example, we can start discussing it synchronously so everyone can propose a change. So for example, you can just clarify it a bit. It will be definitely part of my final feedback. So I think we can just discuss it. Yeah, what we say, yeah. So for example, yeah, I put just one of my ideas. What clarifications. So for example, if you disagree, and it's perfectly fine to disagree, you can just put a comment there, or maybe you make your suggestion. If you see other things we could do better, you can just, again, make a suggestion added to the list. And then we will be discussing what went well and what could we do better and we will be defining action items for the future. So for example, I can propose, let's say, Okay, so for example, we'll contribute on the directions. So for example, we can discuss the section I this feedback and agree on a next item for the next year so that we make the program better. So this is a quick example of how we do retrospectives. And again, no need to do it right now. But yeah, this is going to be discussed in Friday. Yeah, so better to feel it better before Friday, I mean, it's better to do it synchronously because meetings happen quite rarely. And the time is not convenient for participants. So if you do it synchronously, you can just chat with the entire community. Please feel free to put any ideas here. On Friday we will discuss them. I'm not sure I will be able to join. It's super late in my time zone. Okay, so does do this follow ups make sense to you. Sorry, I didn't understand. Okay, so, yeah, here, I'm just making note. Okay. Any questions about the closed on days. So the retrospective will be done on Friday night, I was supposed to to write them down. Yeah, so anything you have in mind, just put it here. So it doesn't have to be prioritized or whatever it doesn't need to be friendsly written because again we can discuss everything. So just put notes, etc. Usually when big teams do retrospectives, they vote on the ideas on the discussion so that we can get more feedback. I don't think we will be doing that for she called Africa because we have only a few participants so we can adjust to discuss them. The things on the call. But yeah, it's still essential to put your notes and your experiences are there so that we can improve. And I'm pretty sure that she could Africa organizers will be all asking for your feedback in some form after the event. So you can basically start preparing that. So just to clarify, they should all write this up before the Friday meeting and then it will be discussed more in the Friday. So that makes sense to everybody. So maybe for this particular session. We could add additional item to the retrospectives is obstacles experienced. If you are a newcomer contributors and the Jenkins community, you may have seen some issues with developer tools documentation this processes. So, if you see something like that. Yeah, please put them there because it would be a really valuable feedback to us as a community. We don't always see issues because we work on this project for years, or for decades like me and Mark. Yeah. I think it would be important to get your feedback so that we can again create action items and improve it regularly. And yeah, if you want to share your experiences and in your format, for example, write your own blog post, etc. All of it is much appreciated. So whatever you want to do. Just do that. Yeah. And be honest if there's anything that you're concerned about that you're uncomfortable writing for everybody. I would feel free to send a slack message just to mark, or to any one of us actually, but I want you to feel what you can be honest and we don't want to make you uncomfortable but we just want to as Oleg says we want to make it so that next year's people have a better experience so we're always trying to improve things. Yes, so again, if you see that something went bad, no repercussions at all. We are looking for feedback. So it's not something like it really means anything and actually any negative feedback is also appreciated as long as it's justified and actionable. Okay. So, for example, there are ways, there are multiple ways to share that. For example, if you want to share feedback with organizers, so it's chicote Africa. Or, for example, you can share feedback with mark weight for internal stuff. And you can also share feedback with the Jenkins governance board if something went wrong. Well, hopefully not. But as things happen in the community, fortunately, not often at all. But for example, we have code of conduct. I'm not sure whether Mark referenced that in the beginning. All contributors expected to follow this code of conduct and if something goes wrong, for example, if you get, let's say a toxic response in your pull request or whatever, you can report that so that Jenkins governance board cannot follow up. There's no need to postpone that because again, we are trying to improve the community and again, there will be no repercussions or whatever because yeah, that's how the Jenkins community works. Okay. Does it make sense. And yeah, I'm a Jenkins governance board member. So if you have some feedback, I'm not sure please feel free to reach out to me privately. All right. Okay. Everybody doing well with the work you're doing. Lucy, what happened I looked at the end of Friday session. You had a problem mark was going to rerun did that clear up your problem. This is on the message that she's a key. So I'm not sure where she's back. Okay, there is a question from Esther, could we still contribute after this program. Of course, yes. So you're welcome to contribute to the Jenkins project at any time, as well as pretty much every details. So, yeah, if you want to keep contributing please do so, whether it's related to chicota Africa or not. We also consider participating in more rich programs. So for example, you might be eligible for some of them. So as we discussed before chicota Africa contribute on participants might be technically eligible for Google Summer of Code, but the application deadline is closed. At the same time, there are other events. So for example, yeah, there will be October 1st in October, they will be out for each year in winter. So the application phase for summer is also closed. Hopefully next year we will be accepted to Google Season of Dogs this year we were not accepted. And there is also community bridge, also known as LFX mentorship. So Jenkins project can run its own outreach programs on demand, and we can run our mentorship programs on demand. So you can try one of these programs if you're interested, and you can just reach out to the community. So there is documentation seek. And you can contact it. So that if you need help at any moment, you can use this channel to get feedback and probably get some mentorship. For example, we can, we are meeting sometimes so you can use this meeting for the discussion and any question. There is also a channel called newcomer contributors. You can use it because, again, for skin any kind of questions. We'll be happy to help and to point you to right channels if needed. Okay. I hope it answers your question. We would love to have you stay in the community. Yeah, of course. So, yeah, the main objective for us for she could Africa contribute on for the events, firstly to provide a great experience to participants to let them learn. It's the first part, second part is to introduce them to open source communities and to get them on board it to the Jenkins community, if possible, or maybe to other open source community because it's also equally available. Our priority is actually to deliver something. So, yeah, personally, when I was going to say mostly focus on experiences and encourage you to do so as well. Okay. Okay, so we have a few minutes left. Are there any questions help needed to explore requests that say. Yeah. Yeah, I made it to the test yesterday. And then I don't know how it happened, but then it looks like it includes also. Another branch. So, I don't know how to. The audio is a bit too low for me. I'm not sure whether I captured the question correctly. Yeah, I'm having trouble hearing to. Okay, so you prefer to write it. Sorry, because I really didn't follow so I guess helping with the poor request but you didn't understand which one. Sorry about that. Do you post the question or like we are seeing all your computer I don't know if it's. Yeah, that's fine. Usually turn off the slug but in this case I'm just sending a message to the channel. I made a pull request to code examples to work for basic steps plugin. When I push commits I found out that it includes other commits from another branch. How can I remove them. So, in this case you would need to rebase the branch. And for that, there are tools in Jenkins. Sorry, I cannot show you a few examples. Just a second. Okay, so for that actually there are two common tools. One is git rebase. Another one is cherry pick. And actually for the most common cases I recommend the latter one. So how it works. You have a tree and from this tree you can take a particular commit. So, for example, I can show you an example in the web in the UI, because it's easy, but you can do the same in the common line interface. So, for example, I have Jenkins remote, so I won't commit it anyway. And you can see that there is just a master branch which includes a few pull requests. Let's imagine I want to port something to the previous release. So, here for example, I will create a branch. For example, 641. Yeah, and here for example I want to take a commit. So, you can see that if I just match the tree, I will get all the history of commits. So, it's probably the case you've got, because most likely you just started building a new branch on the top of the range. And here what I can do. For example, if I want to take a specific commit like this one, I can call it cherry pick command. And what it does, it basically takes the same commit contents and applies them to your current branch. So, I got it here, and now you can see that I have a new branch, a remote for 641. And then includes just one commit I cherry picked. Then I can push this branch to my fork and submit a pull request to just this content. It's one of the ways. Another way would be to do repairs. But to be honest, I recommend cherry pick in this case because it's much more simple. Does it answer your question. In the case of cherry pick you would need to recreate the pull request or to force push the branch, which is also possible because you can take the original name. This branch and then do a force push and overwrite to your pull request. Does it answer the question. Okay. Okay. Anything else for today. Then, if no other questions, thanks everyone, and talk to you on Friday. I will try to join the final meeting if not jelly. Thank you so much for your work and Mark will be able to handle that. And thanks again for all your contributions. So let's say it's been a real joy. Yeah. I'm happy to come from that. So let's focus on finishing the program. And yes, the break that once we are done. Thank you. See you on slide. Bye bye. Bye.