 Thanks, everyone. This is the Chicote Africa Contributon Retrospective. It's the 7th of May, 2021. We're going to discuss and identify things that went well, things that went poorly, and what we can do in our next event like this to assist it to go better. Thanks to all of you for being part of it. Thank you for being active and participating in the Jenkins Project. I'm gonna go ahead and share my screen and we're going to look at that as a way to sort of guide what I propose. So here's my proposal. Let's move that out of the way. Whoops, there, okay. So what we've got on the right-hand side of your screen is the original task document that we created. And thank you to all of you that have made comments in its retrospective section. So this is, we see comments from Cynthia, from Sharon, from Oninye, from Angelique. I know we've got comments from Kristen in here and from others, so very, very grateful for those. I think what we should do today is take this left-hand document and my proposal is I'm gonna make this bigger so we can read it together. I think we'd like to review the results, the processes and the behaviors of the project to identify specific actions that will improve future projects. We're going to, in this session, work from the assumption that everyone was working with good intentions and that they really wanted good results. And we're going to identify things we can improve and do it in a way that we acknowledge when something didn't go as well as we wanted, but we're not gonna place blame, we're not going to, this is just about trying to find the next things we will do that will help us improve and be better. Therefore, I think what we ought to do is take a look at what some of the highlights were that were commented on, obstacles that were encountered and invite some of you to comment on those obstacles, what you encountered as challenges, what problems you had, et cetera. Then, after hearing a brief description of problems and challenges, we can talk about what actions we should take and I'll try to capture those actions into a plan for actions. Does that work okay for everybody? Yeah, that's fine. Okay, so here are some of the new contributor obstacles and here are some of the mentor obstacles and some of the what could we do better topics. So I think what we ought to do is, let's take a brief moment, would one or more of you be willing to share obstacles you encountered as a new contributor or topics that you think, let's be sure we address this in our retrospective. Oninye, maybe what we could do is have you go first and then we'll take, actually, no, how about we go in the order of text here? So Sharon will ask you to go first, then Esther and then if Lucy's with us, we'll have her do it then Oninye and then Cynthia and please be relatively brief. We want to hear your voice about which things do you think we should focus on in this retrospective to help us improve. So let's see, Sharon, I think you're here. Now I can't see my participants immediately. Yes, so Sharon, would you like to go ahead? Sharon, I'm afraid we're not, I'm not hearing you. If others are hearing you, I may have an audio problem. No, I can't hear her either. Okay, so Sharon, you may have an audio problem rather than lose time. How about Esther, would you be willing to go next and give us just your insights, your recommendations, things that you would like to highlight either from the text we have here or something that's come to you since then? Nothing new except the things that I already said before. So I had an issue with Jenkins to start. And apart from that, I've seen my mate of couple was standing in Jenkins's back. So... Okay, so it was understanding Jenkins as a product? Yes. Okay, good. And I think... I'll use it, yeah. Great, and that I think fits with this comment that you had made here, right? Familiarize yourself with the platform early. And that may also fit with weekly goals. So set timelines on goals. Might have, good. Okay, excellent. Thanks, Esther. Okay. Then next voice was, let's see, Lucy. Yes, Lucy, you're here with us. Lucy, would you like to highlight a key point that for you, you would say, well, this would have been a significant improvement or it would have been better if we'd done this? Hi, everyone. So... On my side about the obstacles that I had. Okay, definitely this was my first two-pencils project. Yeah, I was having also the things that I was doing to say. So the challenges that I had initially were mostly... I remember the first few weeks, I think the second, the first one, I had the mission installing Gen Kings and all those things that we're supposed to install for everything to run. It was really a challenge because I was using a bone tool. I don't know. But then I was helped and I was able to sort out that and to catch up with the rest of the people. Then another issue, this was quite a challenge to me by the way. It was the fact that the time difference, but yes, it's understandable. But then I had... It was really so bad on my side because some meetings I used to... They used to happen very late in the night, like quite late, yeah. So I was finding it very hard for me to join up because maybe then any... Just some things used to happen around there. And it was a challenge. Thank you. So there was a scheduling thing and in some summaries, I had not captured that one. So let me put that there are improved communications by identifying times that each participant can be mentored. So we had tried the approach of a combined meeting where everyone could be mentored. And that meant that there were times when you couldn't attend. Thanks, good insight. Okay, not just solely group mentoring. Excellent. Okay, thank you. Anything else that you wanted to share there, Lucy? Maybe a proposal. There was something about... Especially for the fact that most of us were... Okay, myself I had come across as a king at some point. But then I'm considering the fact that most of us were not familiar with almost anything to do with it too, yeah. So, plus the whole open source was a new thing. So maybe we would, okay, I understand that was already in place, but if it would be something like tutorials, sometimes in a while, that the mentees could follow up, then plus there would be something like a catch up just like after... At the end of the day, we maybe not really have a meeting, but to get to discuss whatever each mentee have been able to handle the whole day, during the whole day and even the challenges that they've gone through. Very good. So I think you're echoing the same observation that Esther made that a tutorial in the early stages would have been a real benefit. Did I capture that correctly? So I think it was, let's see, and where I had it here. Oh, yes, include self-paced training courses in the task document. So this one was, I think that's trying to capture what you were describing and what Esther was describing. So a sure, successful startup by assuring completion of the course. Because there are courses. Linux Foundation offers a course, Cloud Beach University offers a course, and they're both free. We could have used those and we did not. Very good. Thanks, Lucy. So next was, next was, Oninye. Yeah, good day, everyone. Hi, everyone. To add to what my fellow mentees have said. Okay, on my own end, I didn't really have much challenges, probably because I used iOS, yes, because it was much, pretty much straightforward. Yes, and I also used real. So everything was just straightforward, yes. The only challenge I had, which I pointed out on the document was the fact that the PR, some of the PRs I used, the maintainers were not nearby to review, so I would actually suggest if it's possible to maybe alert all, let these other maintainers, let them know, give them the awareness that there will be some PRs from social so people, so they will be aware, because I'm not sure they were aware that we were supposed to contribute to their plugins. Yeah, so if they will be informed before we start, or maybe when we start, or if that's not possible, if we can strictly work on plugins that are managed by cloud groups, that we have the maintainers available that could actually quickly help us to review, that would be better. Yeah, so that's the amount, thank you. Excellent, so I tried to capture that in, let's see here, it was increase pull request, review and merge pace by not selecting plugins unless the maintainers have agreed to a prompt review. So that was a mistake that we made. I used a prioritization exercise to prioritize the plugins with the most comments, but then failed to ask the maintainers, will you commit to review promptly? And even worse in your case, one team of maintainers has had ongoing challenges for us in general. We put you on the Artifactory plugin and we've struggled with it in the past. So we really did not give you the best chance for success by doing that, and yet you did wonderful work on it. Good, yes, thank you. Okay, anything else on Yinye? No, that's basically all from my answer. Okay, Cynthia, would you like to go next? Yeah, thanks. I actually feel like they've said everything. I was going to also mention about code reviews, but also I had challenges with some, the meeting that we're having on Friday evening, sometimes they were taking long, which were affecting the people that I stayed with because they had to sleep. So I'm not sure if it's possible to have them, actually this time works for me well, but I'm not sure with other matters, but yeah, it would have been better to just have it earlier so that in case it takes longer, then it would be fine. Yeah, that's what. Good, so my interpretation of that was, let's see, we had it here, which was not just group mentoring, the attempt to use group mentoring was an attempted efficiency that I suspect we could have achieved the same results by having one-on-one mentoring with one of the mentors and each individual without doing a large group meeting, good point. All right, so now, and Kristen, I think you've got experience in this area where in Google Summer of Code, the typical mentoring experience there is focused on an individual, right, on one person. And so maybe that's a model we want to consider in the future rather than trying group mentoring like we did here. Yeah, I think we originally thought that this would be something that we could do more, maybe collaboratively or maybe even just kind of have like sessions where we all kind of, it's more like a hackathon, then it ended up being like, because it's so hard to coordinate, to coordinate multiple time zones and more people, the harder it is to find a good time, with everyone, it's, you end up finding the average time, which means it's like only okay, it's only okay versus maybe the best time. So maybe it's, we could work on maybe doing more things asynchronously and then try to focus one on one. I, yeah, I think we had, we thought it was gonna be more hackathon-ish than it ended up being, so. Right, right. Your point is good about more async work. I wonder if what we ought to consider is, should we say we'll do one group meeting a week, because I think there are some things we need in a group meeting. The group meetings that started the week were helpful to set framework, to set expectations, to do process questions, but then the technical sessions should probably be individual focused with others welcome to attend. Anyone can attend, but we'll do focus on an individual. I mean, Mark, I love this session where you basically went through and you started like, you built Jenkins Core from scratch. I mean, that was kind of nice and that's a good thing to have in a group session as well too, because it's just everything all together and we could ask questions or we could look at stuff. I thought that was nice, but it was hard for me personally because of things on Monday, probably you too, because it was in the middle of my, like in the exact middle of my night. So it was a little bit harder for me to attend that meeting. But it is good to have, like I do like the idea of having it as like a, here's what we're doing, hey everyone, this is week one, week two. And then, like Lucy you were saying, it was hard for you to attend as like the hours. And I think, yeah, it's just, yeah, easier to have individual sessions later in the week. So what do you think of this idea? If we were to identify themes for meetings and say this meeting is a group training session, we're going to share, we'll do the recording, we're going to focus on things that we think everyone needs to know or have things that are instead an individual mentoring session where anyone is welcome to attend, but we're focusing on mentoring for this person. Would that, do you think that would resolve it? Would that help? I'm gonna assume, yes, Kristen. So that idea might be feasible, good. So now there was a comment on more async work and I think that's a theme that we might want further exploration on. It's something that I hadn't seen many comments on in the feedback, but was curious if there are ideas of ways we could have done this more asynchronously for better results in the end. Maybe what we need is a group training session on preferring async. Let me think about that. Okay, just noted. Okay, so now I wanted to look at some other topics, the obstacles encountered by mentors in here, mostly I'm looking for feedback from our participants from the mentees on if some of these were particularly important would have been particularly valuable to an others less so. So could each of you look at this list and for instance, give, choose one or two that you're ready to say, oh, yes, that could have helped. So here's one on early morning meetings. Well, so I'll let you do the reading and I'm going to give us just a minute or two of quiet while you read. And then I'm gonna rotate through each of you and see if there's one or two of these topics you would like to highlight. Oh, sorry, Mark. Can you hear me? Yes, go ahead, Oninye. I didn't get that, please, go ahead. So what I would like each of you as participants to look at this list of obstacles experienced as mentor and what could we do better to see if there are things in there that I might have missed of, oh, we should do that. So Oninye, one that you highlighted was interact with more people in the community. And that's one I think may need more discussion. How could we achieve that? That's the kind of thing that I'm looking for this phase of our discussion. So review these sections. Let me paste a link to the document into the chat so that you can each open it. So where is the chat window? Chat, chat, chat, here we go. Okay, so here's the document and what look at obstacles experienced as mentor and at what could we do better and give insight. So one that Oleg had noted here is promotional things that I had not captured. How do we assure that more people are aware of this, know about it and are ready and willing to help? So those are the kinds of things you're looking for. And then we're going to loop through each of you as participants and ask for your insights. Did that explanation come through Oninye? Okay, thank you. All right, hopefully you've had time to do that review. So let's go back to, and we're going to take a slightly different order this time. I'm going to go based on what I see in the list. So Cynthia, would you be willing to be our first voice then Esther, then Lucy, then Oninye? Anything that you detected, Cynthia? Oh, go ahead. It looks like Esther, Cynthia, anything you detected that you would recommend? Oh, let's take this thing, idea from the what could we do better and be sure it's in our summary. Okay, so from what we could do better, I think it's the same thing Oninye mentioned of interacting with other people, maybe having, I don't know, ice breakers. I feel like it helps a lot to just know the people that you're with. Also, as mentioned, maybe having like a theme for each meeting that we get to have, maybe say that oh, today we're going to learn this thing or maybe you're going to learn about code reviews. We're going to learn about some gift commands. I think we'll be good just having some mentoring session. Yeah, we'd like a topic. Yeah, that would be good. Yeah, I think that's it for me. Excellent, thank you. Esther, your comments. Going through the documents, I would say interaction between, I think Kristen's observation interaction between participants and mentors and participants and guidance on how to research topic and step. So I think I'm most, I think Cynthia I remember last what she said about when having the meeting to choose something to learn, something specific to learn, yeah, that would be great. Good, okay. Well, and I see here a comment that you had made, breaking tasks into weekly goals. I had not, I was uncomfortable doing that but I think it's a very good idea. And I had not captured that. Do you mind if I put that up in the top level of that, let's see, I'm not sure. Well, maybe it's use weekly goals. The worry for me when I did it was I wasn't sure how fast each of you would be able to adapt. And I thought some of the things might take several weeks to do and none of you took several weeks, none of you. So it was a complete misunderstanding on my part, but set weekly goals. Right, yeah, I said I wrote that because I figured that sometimes I spent too much time on one thing and that I was not really moving at the fast pace and moving forward, so to speak. So it just made me fall back in a way. So it was a way for me to know that, okay, at the end of the week what I should have achieved then that would be, that would be cool because there was no goal. So it was just basically just following it and then at your own time and pace and sometimes you might fall back, so. Very good, yes, okay. And so what the idea there is we have milestones and we say, hey, if you only did a part of the things to get here, you're still, we've reached this milestone, let's go to the next thing. Very good. Okay, all right, so next I believe was, let's see, so we had Cynthia and Esther, so Lucy, would you like to be the next voice? Yeah, it's okay. So on my side, many small repetition or whatever my colleagues have just said. So first I feel like there was very minimal interactions between the mentees and the mental, so something will be done about that. Then too about the, yeah, timeline for the task, I think we should, maybe we should have, there should have been goals, like, so that after one is not able to go beyond whatever the second goal, then they can be helped like a solution can be, can be found for that. Then I was also feeling like maybe the whole, whole program will have taken longer because within the first few weeks, most of us use the time to even familiarize themselves with whatever we were supposed to do. So maybe time will be taken much longer so that we get to, people get to settle and even work within the, okay. So just to be sure I've understood, so one of your observations is, should we consider instead of a one month, do it a longer period for six weeks or for eight weeks? Is that what you were saying there? Yeah, yeah. Okay, and that's one I had not captured. So I, for me the, okay, consider a longer, longer project duration for better engagement, better experience, good, okay. And I think we had captured your notes on the weekly goals and that way we have a clear, you should be here by end of week one. Good, all right. Let's see then, on Yenye, I think your next voice. Okay, yeah, so just like I mentioned, personally, I love meeting people, I love networking. So I feel, okay, on the Slack channel we're all added to, there's a general channel there, that's the CDF Slack channel. If we're actually introduced, because I feel we're just isolated in one group like that and nobody knows that this set of persons are existing here. So I feel if there was a little bit of introduction, oh, there's some guys here that are here to do this and they welcome us and maybe we introduce ourselves, it's a large community. So I feel it will give us a bit of sense of belonging and also we could meet people there, we never can tell. So that's for my own, and if there is a way you can consider trying to introduce us to the large community, yeah, that's it. And that one for me is a challenging one. So I wanted to take some notes there because the Jenkins developers, I would say they don't have a chat channel that is heavily used by Jenkins developers, a single chat channel. What they have is a mailing list and separate chat channels for sub-components and subsystems. And so it's an interesting challenge, right? So even on Gitter, we don't have a single chat channel that's dedicated to it, right? It's really, there's a configuration as code plug-in channel, there's a git plug-in channel, there's several others like that, the cloud native group chats on CDF chat. Kristen, go ahead. Yeah, and it's like, I don't know, Mark myself, like I don't even know of a Slack channel for Jenkins. Actually, it was ironic because like I know of IRC and it's like if you wanted to go really retro with everything, there is IRC for Jenkins, but again, it's not everyone is on there and it's gonna be, because it is IRC. And it's going to be more of like, there's the general Jenkins channel at least to me is sometimes more like user questions versus developing or like using Jenkins versus like Jenkins development. So it is a little bit harder to find everyone, but and so it is usually easier like Mark was saying to find like the individual Slack chat channels based on what you're, based on different pieces, but if you, or I guess if there was a general question, it would just be in the user's channel and someone would be able to jump in and help, but yeah, it's, I think I don't, you know, different open source projects operate in different ways and this is just kind of how Jenkins operates. So I wondered, should we have, should we have introduced the team, the project to the developer mailing list at the start? And that way we at least could have had assured that each of the participants was invited to and participate in the developer mailing list. The challenge is the developer mailing list has a relatively high expectation of deeply technical content being placed there. And my worry initially why we didn't use the developer mailing list is because first-time developers like you were for the, for much of this project would likely find that developer mailing list uncomfortable or, oh, hey, we wanna have a conversation separately outside the list like we did in Slack. So yeah, I'm not. That's true. That's a good point. Sometimes it can be very technical on that list or it's talk, yeah. But it might, it might be, maybe do like in just a general introduction thread. And just as, because even like the Google Summer of Code has its own list, which is what's difficult there, but you could just do a, hey, this is like almost like a notification that this is happening. Or just another way to get the information out to people who could potentially be reviewing. And then maybe in that thing call out some of the first pieces that we were gonna work on. And so that way there was at least a little bit of a heads up, but you're right. It is kind of, I'm not, maybe that was, it's just like good to do an introduction, but it might not have been as helpful for getting, like getting started in development. Does that make sense, Mark? I think so, yeah. So announce would feel really good. And that would have at least introduced on Yenye to, and Cynthia and Esther and Lucy and Sharon to the Jenkins community and to the developer community specifically. So that's very good. All right. Sharon, sorry that we haven't heard from you. Could you try unmuting? And let's see if we'd love to hear from you if your audio is working. Okay. Hi everyone. Sorry, I had some technical issues at the start, but I'd like to say that the entire experience was good. I appreciate what you did for us, like helping us through the process. For me, I think I'll just say like the rest. I spent a lot of time at the beginning of the tasks, not knowing that it was much easier that I could have moved forward. So if we could have the goals, it would have been much helpful. And then for my case, the way I had that technical issue, I'm not sure if in case someone has something like that, is it possible to assign something like working on docs that doesn't have to work with the technical things? Ah, so your suggestion there is, should we consider being able to redefine the project or reassign if there was some unexpected barrier for one of the participants? Yeah. Good insight. Okay. So that one is that sort of a wildcard thought. Let me see, how would we say it? So it would be something like improve startup shut down by identify technical issues for participants, assign a mentor to assist with resolving the issue. Or if the issue can't be resolved, redefine the project for that contributor, that participant. Does that capture what you were saying, Sharon? Yeah, yeah. Okay. Good, all right, interesting, thank you. Okay, all right. Anyone else have insights or things that we may have missed on this? I wanted to, before we conclude our session, go through the proposed actions and then let's see if we missed something in the proposed actions where you say, no, this is something, oh, we should have done it. And we'll then add those as well. Okay, good. Then what I put as improvement, so I've tried to frame these improvement actions as a goal and an action. So I think the goal is to improve communications and one technique is in the task list require a chat posting from every participant and every mentor at the start of the project. It may seem sort of minor, but it was really quite awkward that one of you, actually one mentor and one participant didn't get into the chat channel until several weeks late because we just didn't do this. So sorry and thank you for your patience with that mistake. Then to use, to take Cynthia's suggestions, introductions at the start of meetings, ice breakers to assure we know each other. So, and now this is one I had inserted here, have each participant briefly share results in a meeting. That's synchronous, not asynchronous. And I wonder if, would that have helped or should I just delete this? I feel that's okay. Because it's a look, it will sound like a stand up. Yeah, it's okay for me. Okay, all right. So yeah, that is sort of a mini stand up, right? It is a stand up status. Yeah, good way of describing it. Thank you, okay. And then identify times when individual participants can be mentored. I think we've heard that from several people. That's a good way to avoid having a problem with multiple people not being able, or one or more people not being able to attend a group session. I don't know what to do on the more async work here. I'm prone right now to just remove that and think about it separately because I think it's a more general topic. Okay, then increase communication between participants and mentors by identifying themes for meetings. So group training or individual mentoring. Okay, and we've got ice breakers there. Oh, right, so that's, oh, good. Okay, so actually we've already got this here. Okay, in all meetings, okay. And include topics of interest. So should we identify common topics to consider for group training? So for instance, get operations using get effectively. I think Oleg had done a good session on that or compiling Jenkins. That was one that I think I did. Jenkins core and a Jenkins plugin. With that, I think that would be helpful there. The next proposal was decrease participant startup time by including self-paced training courses in the task document. So my thought was you shouldn't need to start the self-paced training until the project begins because the project was intended to be specific time but this could have been one of your first things. Instead of us just telling you, oh, do this little tutorial, we could say take this self-paced training course accepting that you may only get through part of it. Then the next piece was increase pull request review and merge pace by only selecting plugins that we have maintainers who have agreed to promptly review and ask the, each submitter to at reference all, I shouldn't say reviewers, all mentors in each PR. That was one where Esther had submitted some pull requests and I was the only one and I dropped the ball. I failed to do what I should have done. And if we mentioned all mentors, there's a better chance someone else will be able to help. Okay, then recruit plugin maintainers, announce. Oh, go ahead, yes. Okay, so if there is a label, it can be add into the pull request, specifically for, to identify our pull request. That would help also to add labels to our PR. Yeah, I thought that pull request submitters didn't have permission to add a label in general. So I like the idea. I think it would be good to have, and maybe that's an even better idea on Yenya is create a GitHub report that shows all participant pull requests to all Jenkins repos with that. Because I don't think I don't, at least Kristen, can you help me there? I think that labeling of a GitHub pull request requires that I have right permission to the repository. Let's see if I grab one, for instance, a the workspace clean, no, let's see, which, oh, build steps plugin. So let's get the build steps plugin. I don't have pipeline build steps. So if I look here, I don't think that I can actually apply a label to a pull request. So, yeah, see, I don't have edit permission to do that. And I don't think even the original submitter can create a label, but would a GitHub report meet the same need? Sure, I mean, I think also that would have been helpful too, is that if you made a pull request to like post it into the, so I know maybe it turns to spam, but to like post it into the Slack channel. I think that was actually like Oninye, like Cynthia, you guys started doing that later and that was incredibly helpful. Because I was like, oh, okay, now I can see that there's a pull request and or it's helped me at least, at least for me it was like super helpful when that was happening, because it allowed me to be able to see, oh, there's something new right now, I can go make sure I don't miss it. Because in GitHub, you can, especially if we weren't tagged explicitly, so thank you to everyone who did like tag me, because what I can do is you can go to GitHub and then you can see specific pull requests that you've been asked to review. But for me, at least like it gets mixed in with things that I'm reviewing for work or other pieces that, you know, other open source projects. And I'm not sometimes as good about checking that, but if it was like an email, or like, you know, where I'm added and I can see it to an email or in the GitHub, or the, sorry, the Slack channel, it was very easy for me to go, oh, okay, I really, I need to make sure I can review this. I noticed like, pretty much like Angelique, Meg, Mark, you were all really, all really good about, yeah, as soon as something went in that channel, people were responding very quickly. And sometimes even when I went and was like, oh, I just saw this and I clicked, it was already reviewed, which was very helpful. So I really appreciated when y'all did that and it might have maybe helped a little bit earlier too in the project for, we can make that suggestion early, like please let us know where you are. And that way we can help you as quickly as possible. Well, and that fits with this sort of heightening improving our communication by better using the Slack channel. Good, very good, thank you. Excellent, okay. So then next goal was increase community engagement by recruiting plug-in maintainers. So that's something before we ever start the project, announce it and yeah, announce it. Then this one, project startup. So the initial project startup was kind of bumpy, one because we started on a day when we didn't generally meet together. I think we started officially on a Saturday or and so first meeting was several days later and that feels like a really healthy thing and weekly goals. Now, how would you as participants have dealt with if I had done a bad job of defining the weekly goals and said, I think the first three tasks should be completed in a week. Would that have been destructive to your feeling of accomplishment? Would that have been demotivating? I worry sometimes when I set goals that I'm just guessing. If I had done this, but done it very badly, would that have been much worse than not having goals? Yeah, I think it's kind of like a 50, 50 thing because on the other hand, if you set goals then you might kind of rush participants and then might end up not really gaining anything because all they just want to do is finish their goals and they're not really getting a feel of the platform but then on the other hand, it could help them be focused. So I don't know. I wonder, Esther, maybe what you've inspired here is goals, goals should include, what if we said goals should include communication goals and interaction goals, not just code accomplishment goals. Because one of the things that Oleg reminded me of when we started was that the bigger picture goal of this project was not to improve Jenkins Pipeline Help. The bigger picture of this goal was to have add five new people who were more comfortable contributing to open source projects. So maybe if we stated the goals in bigger terms, they would be more likely to be achieved and we acknowledge, yes, we're using this technique, build a Jenkins plugin as a way to help prepare each of you to contribute in some open source community in the future, whether Jenkins or elsewhere. That's perfect. Sorry, go ahead, Oninye, say that again. Say that's cool, that's perfect. Okay, great, all right. So remember the project goals, the Shikode Africa goals, not just the Jenkins project goals, right? Because the Shikode Africa goals are a bigger picture. Good, okay. Consider a longer project duration. So this one I'm leaving here, but I have to acknowledge that I think we chose exactly the right duration for this one because we avoided a collision with Google Summer of Code. If Google Summer of Code starts for me in I think less than a week now, it may be, no, it's 10 days. And that will take me away so I wouldn't have been able to mentor. So if this project had been declared to be two months, I would have had to say no and the project wouldn't have happened. So this one I'm leaving, but it's a compromise with need to not lose mentors because we lengthened the project. Good, okay. And last point was identify technical issues and assign a mentor. All right, any others, we've got only five minutes left. Any others before we call this retrospective done and we'll take those as planned actions? No, I don't think I have any comments. Oh, and I didn't even touch on the practices to retain. Maybe we could do that in the last few minutes. Just so, mentoring sessions, weekly session for the whole group, individual session, if we said individual session each week between a participant and a mentor, is that, would that do you think have been better than our attempt at two weekly group sessions? Yeah. Okay. So maybe that's not even a retain. That's a- I have a question. Yes, please. Was the proposed standup meeting among the mentees alone or with the mentors? I was assuming it was with the mentors. Good question. What would you recommend as a group? So I thought that this was share in each group meeting, but you're right that if you did it just as mentees, you could do it probably at much broader range of times than we could, because of my distance from you in time zone and Kristen's distance from you in time zone. That's gonna be okay too. Okay, so I mean we could, I wasn't sure if the mentees had convenient access to a way to get together. And so I, but it's a good question. Should we have a mentees standup every day or every two days? Yeah, that would be nice too. So I'm not sure if each of you were actually able to work on the project every day, because I wasn't sure that, I assumed that you were maybe putting 10 hours a week or 15 hours a week in and some days you wouldn't work on it at all. But I'm open to that. Should we discuss at the start of the project, how frequently you do, persistence or do you stand up? Sure, and it can even probably be helpful, especially if you're y'all are talking post something on the Slack channel. Very into trying to almost over communicate because I think I've put in a lot of things. Sometimes it was hard to, it felt like it was hard to track where everyone was. And so yeah, meet up, you can all talk to each other and actually that would probably be really great. Cause then if you have any questions, it might be faster to ask someone else who's working on something rather than wait until one of us is available or just if it's over the weekend, just post. But yes, just yeah, I can't emphasize enough. I know it's sometimes it could be intimidating or anything, but it's like if you, we're all here to, if you have a question, just ask or if you're blocked by something or confused, we're here to help. So yeah, the results that's asked, we didn't give you posted or just kind of this is what I'm working on today. Or oh, it's like, oh, I wasn't planning on, I have, you know, something else is happening. I wasn't planning on working today, but maybe check in tomorrow. And then that way everyone kind of know where everyone is and maybe kind of even enables a little bit more. So again, so we're also not fighting for, you know, middle of the night, trying to have a meeting together for either middle of y'all's night or like our night is just, it maybe helps a little bit more for, it doesn't hurt to over, over share, especially if you're in our channel here cause we all want to help each other. Good, very good. Okay. Excellent. We have reached our time. Thank you to all of you. Thank you, Kristen. Thank you, Cynthia and Esther and Lucy and Oninia and Sharon. It's been a privilege and a pleasure. Thank you, thank you. Any concluding comments before I end the meeting? No, I have none. Thank you more and everyone. I'm good on my side too, thanks. All right. Thanks very much. I look forward to seeing you in the future. Thank you everyone. A copy of the recording and a summary will be included in a blog or a link, no, link to the recording won't be included in the blog post. I'm preparing a blog post that will summarize the retrospective and what we learned, highlight some of your results, et cetera. I'll probably mention each of you in the blog post poll requests so that you can then review it and give comments. I hope to get that blog post done today or tomorrow. I would love to have your review before start of my day Monday because I'll probably set my goal to post the blog post to jankens.io Monday. Is that the 10th? Monday? Monday, May 10th. So I'll let you know that the blog post is out there and would love to have your feedback. Thank you, everyone. Thank you, Mark. Thank you. Thank you. Thank you. Thank you, everyone. Bye. Bye.