 This is documentation office hours. It's the 10th of January, 2022. I'm in the North America time zone and it's the 11th of January, 2022 in India. So thanks, great to have everybody here. Topics on the agenda. News, outstanding PRs, Google Summer of Code documentation projects, Sheikot Africa Contributon. See, am I on the wrong day? No, I got the right day. Okay, good. No, you're in 110. You're in 110. Yeah, and that's the right day. So, and then we could talk about the adopt a plugin. No, no, let's call it what it is now. Improving a plugin, post and site. And Jesse Glick has given some feedback on it. So that's encouraging. It was quite brief, but so if we get to it, that's great. If we don't, there's still lots of work going on. Any other topics you'd like to put on the agenda? But I don't know that the order is right. I did not need to put those outstanding PRs up at the top. Actually, I think we should put them at the top because I think they're a good thing for us to look at. The others are, I'd call them more general topics than the specifics of that. So outstanding PRs sounds really great to me. Okay, so make sure we don't take too long and eat the whole meeting up. Okay. Now, one of the things we don't have today and I'm intentionally omitting it is intentionally omitted. Oh, let's put it in the news. That way I can explain why. Weekly 2.329 is a security release. And LTS 2.Tomorrow and LTS 2.319.2 is a security release tomorrow as well. No, no, sorry, Wednesday. Long day. Security release Wednesday. Well, it's Tuesday in India, so. Yeah, exactly. So using the word tomorrow doesn't help anybody, right? It's okay, so that will be January 12th, 2022. And what that means is there is no change log for the 2.329 release. Or no, and that's because there are no changes in 2.329 compared to 2.328 except the security fixes. That's an intentional thing so that someone who's on the weekly doesn't have to worry about receiving a security release that has some other thing that regressed in it. In addition to the security fix, so it's intentionally done that way. 319.2 is different. It has a few minor changes, minor back ports from. And then it has security fixes. Any questions on either of those? Hi, Kristen. Thanks for joining, Kristen. How's it going? Great. Yeah. Okay, so those two now, I've got a really quite a cool story to tell on preview environments. So on thanks to Gavin Mogan, we've got the ability to see pull requests live. So for instance, here's the improve a plugin tutorial and blog post. And if I scroll down towards the bottom of this thing, there will be a view deployment button right there. When I click view deployment button, it's going to say, did you mean this? And the answer is yes, I do mean it. And there it is. This is a deployed copy of that pull request. So when I click blog here and no, no blog, wrong one. Documentation, developer guide, improve a plugin. The tutorial is right there. Ah. And there it is. So no more requiring that reviewers must go run their own copy in order to see how the thing looks. This is available special thanks to Netlify, who is providing the hosting for these and special extra special thanks to Gavin Mogan for his work creating this thing. It makes it much, much better because now I don't have to be a site developer in order to do a good job of code reviews. Ah. So if we take your pull request for plugin developers, right, we should see the same thing here that view deployment is, oh, maybe not. Maybe this one hasn't been rebuilt recently. Is there something you have to rebuild it? Well, it has to have a recent change. Oh, go to the one that's in the list then the... Oh, good. Yes, yes. That's a great excuse. This one. I've rebuilt that a few times in the last couple of hours. Right. So let's go look at this one and see if it's got a view deployment button. Deployment. Oh, it says this branch has not been deployed. Okay. I don't understand that one. I don't know why that wasn't deployed. We may have to ask separately. Oh, maybe some checks were not successful. Yeah, but I don't think that that would stop. Oh, okay. This one would, no, that shouldn't be blocking it because this one was successful, right? This build was just fine. So I don't, oh, December 29th, that's why. It's probably old enough that it hasn't been rebuilt. Uh-huh. That's a little surprising that it hasn't because I think you had said you'd made recent changes to it, right? Wait a minute, which one are we in? No, I didn't make changes to that one. Good. I made suggestions. Go to the 4612. Oh, okay, good. Let's see it then. And now, if we jump down here. And... Nope, it also says not been deployed. Not sure. I'll have to explore further with Gavin why this one's not deployed. But the way it works, at least the one that I was dealing with, it worked really quite well and meant I didn't have to deploy it any longer. So I can fix my home website to not have that copy anymore. Ah, lovely. So special thanks to Gavin Mogan for his work on it. So ideally, this deployment option will be available for all the PR-submitted to Jenkins, right? Exactly, right. With no extra work on it. That's what, I glanced at it. I didn't see it until this afternoon. As I said, I tuned out and then I thought I was, I didn't feel like digging back to see if I had to do something to make it work, but it should just work. It's really great. Yeah, it is. I am thrilled. That's all that I had on the news front. Oh, you should know, you should be aware. Google Summer of Code. We'll talk about it more later if time allows. We've started, planning has started. We're looking for mentors. We're looking for people willing to help, et cetera. See the blog posts. From Alyssa Tong and Jean-Marc Mieson. All right, next topic then, outstanding PRs. So Meg, you were saying this was, this one has some phrasing improvements. Right, just tiny ones. But other than that, it's approved by Daniel and I was thinking it might be something that should be out there because it's kind of an important change. Okay, so yeah, that makes, let's see, how many more suggestions are there? Okay, so we're just gonna hang on. I'm gonna batch up your suggestions because I think this is a good excuse for us to go through and yeah, I agree. That's a good change. Yeah, we're getting extra space in there. Ah, okay. Oh, and a misspelling. Goodness. Okay. Can we fix this? Oh, admin, oh, sure, absolutely. There we go, edit. We have the power. You're saying that are there admin? And before in Jenkins, there's two spaces when there should be one. Ah, okay, all right. Too bad I didn't notice that earlier. Okay. Administrators, okay. All right, got it. Okay, so let's add that to the batch. Add that. This one was more major, but much more concise. Okay, yep. Not yet. Okay, good. So those changes look good. I'm gonna go ahead and commit those changes. It'll then need some time to run through, okay? And now this one, I'm not sure what, okay. It was approved by Tim already 12 days ago. Seems like it's perfectly reasonable to merge it as soon as it passes CI. That was what I was thinking that Daniel Beck wrote it. So it shouldn't be controversial. We'll come back to it in five or 10 minutes after the CI job has finished its validation and be able to merge it then. Great, thanks, Meg. Thank you for catching that. Now you said that it may have merge conflicts with this one. Yeah, that's that big one that's been sitting there. Right, and that's an okay one to have conflicts with. We know when we have a restructuring thing like this, they're going to have conflicts. So if it gets conflicts, I'm happy to help resolve those conflicts. The real concern is, what would it take to get this thing merged? I know Daniel is just buried and no reason to expect him to get unburied. Yeah, although I think he's been into this already before, at least once or twice, right? Twice, right, right. So it may be that we just say, hey, I liked Oleg's approach. Recently, Oleg used the approach of saying, hey, this is an improvement. Let's go ahead and merge it. It's not, it may somehow be imperfect, but it's still better than what we've already got. Well, that's what I'm thinking. And most of what I added is stuff that I got from old notes from Daniel. So the possibility that something could have changed over time is there, et cetera. Right, and so, but. Yeah, so I think, I think let's take this one as declare that we would like to, I think 4789 is more immediate. Let's get it in. And then if there are no conflicts, we'll consider merging this, merging 4612 later during the meeting if time allows. Okay, and then, because then I got a bunch of little ones that can only be pulled out, pulled out after 4612 goes. Right. It'd be nice. That's what I was just, I mean, there's stuff out there that's two years old and it's kind of absurd. Yes, yes, I've still got the embarrassment metric. There is one pull request from three years ago. So yeah, there's lots of embarrassment on those. Well, no, but there's, well, what I saw, I don't know, I mean, I know it's open source, but there are requests where changes have been requested months ago and the writer never went back and responded to those. Oh, okay. So they're holding. And I don't know what the, you know, part, there's the ruthless bitch in me that would say, you have a couple of months to respond to this and if you don't, somebody else is going to go in and rule on these and... Oh yeah. And we are welcome to do that. We are certainly welcome to bring, to take somebody else's initial and bring it forward, do some additional changes. Absolutely. I do get the feeling that a lot of people think I wrote it once. Any further work is not my job. Right. Yep. It's the liberty of open source. I can leave at any time. Right, right. Okay. Okay. Anything else on outstanding PRs, Meg? Oh, there are a couple more. I think you deleted them deliberately. I'm going to assume we'll just move on. Oh, no, I don't know. Did I? Okay. So you inserted more aged PRs into the... Yeah, just a couple more. I just started looking, but I forget, but it doesn't. Well, let's do any of these cause you to think, oh, hey, let's look at that one. There was one where we got down to a conflict between Daniel and Martin DA about the crumbs. Look for crumbs. And I think it's on the first page. Oh, right, right. I know this one. And this one is one where Martin is suggesting it, is proposing it, but Daniel's saying, uh-uh, I don't think we should be describing this because it's, yeah, here it is. Yeah. Helping somebody do something that we strongly discourage elsewhere. Now scroll down. I made a suggestion and Kirsten gave me a thumbs up. Here, it was in September, but... Yeah, it was like some of these things are pretty old. Sometimes when I go back and review, I'm just kind of like, I don't really know if I should even look at this stuff again, but yeah. September's looking new in some of this stuff. Oh, man. But I mean, I think, I don't think they're that far away. What Martin is saying is this is a special case. When you have to do this, you have no choice. And I think Daniel needs to, Daniel or Wada, because somebody needs to approve, but I think this wording is it, that it's been booted with Daesh D. Jenkins. Yeah, since Daniel assigned it to himself, I'm hesitant to merge this one without resolving it. I like Martin a lot, but Daniel, for me, in these kind of conversations wins. I want to be sure that I understand what his... I have to say. It's like, I almost want to say like once a month, we'll have a meeting where we summon, like where there's this, Martin and Daniel must both attend. And let's figure it out. Let's see if we, I agree if they can't come to an agreement, I would go with Daniel too, on almost anything. Now Daniel and Oleg, they got into, I don't know, in any event, but I think this would solve it. I think Martin is saying that there is a legitimate reason to do this. And Daniel is right that we need to make sure that people understand that you should, this is not for the faint of heart. And I think a warning, I think a warning would do that. But... I think you've got a good point. Right, yeah, that's kind of why I agree with you too, because it's like someone might need it and it would help them. But yeah, we don't want to encourage. I think that if you put warning, it's not encouraging. Or at least like to me, if I saw something with a warning and all this stuff, I'd be like, oh, let's not do this. So yeah, so, but if you absolutely had to in order to unblock yourself. Right, it would, if you have to do it, it's better to do it correctly. Right. Than to fidget around and try to figure that on your own. Right. Okay, so, am I seeing the entire diff here? No, there's more than that. Yeah, that's just the change stuff. If you right-click on files change, I think you see it all. Interesting. Okay. That's weird that I'm not seeing more changes. No, on this page, you wouldn't right-click on files changed. Okay. I will. I can look at, I can go satisfy my curiosity about what GitHub's showing me later. We don't need it. Okay, so this, this looks like it's, yeah, so I really got to see that. What changed? Go to the tab where, oh no, that didn't, which I thought it said- Yeah, so I'm, I think this is, yeah. There's much more text in the, what I really had to- Yeah, you're right, exactly. Okay, so- This is just calls out the comments on the main page and everything else is over there. Got it. Okay. So resolving the conflict, resolving disagree or concern from Daniel Beck, from phrasing being contrary to general guidance to best preferred practices. Okay, got it. Anything else on outstanding PRs, Meg? Ah, no, that's probably enough for now. There's a- Okay. I should do some more probably. All right. Okay, so in last week's Thursday, office hours, there was a question about Google Summer of Code documentation, projects related to documentation. And there are two project ideas right now that are related to documentation, but are in fact coding exercises. Right. One of them is the Pipeline Steps Documentation Generator that has- Sorry, Meg, go ahead. Oh, I said try it again. This was our project last year, right? Well, it was not, no one accepted it last, or no one, it was not accepted as an adopted project in any of the years. And so this is still wide open. Right. I think this is just making general improvements to the doc generator. I think we might actually probably need to go over some of this again and make sure it's still relevant, or Mark, it might be good to also have things that maybe you've seen added here to some of this background stuff, because I think this has been like rolling for- Well, this is what we did for Shikot Africa. This is what we did for Shikot Africa, right? No, no, no. Oh, this is the actual software. Okay. This is, so the examples highlighted here, we went through them in the session. Read file here has some clear weaknesses in terms of, all right, it doesn't give you any example, it doesn't give you all sorts of things. And then there's the poster child, the 62 page long documentation for checkout. Yeah, because of all these nested objects. So like the thing is you do wanna see these, right? Like you do wanna know what you can do. The problem becomes, it's just a lot. Like it- Right. So it's just a- They need to be grouped or something. Yeah. Yeah, and then it's, I think difficult to figure out where exactly you can get these from. So it, cause what happened like again, like when it regenerating this, it's pretty much you're saying we have a Jenkins with every single possible plugin installed. So it's good, cause then you can see what you can do, but the problem becomes, it's just like, which one did it get it from? And it's like, you have to look it up. And yeah, I think there could definitely be things that are made easier to read. And then filling in the actual documentation steps, I think is, I don't know if that will really fit very well with the Google summer of code piece. Maybe we can say that, you know, you take a plugin and use it as an example. And then eventually that gets added to the main repository as like, how to better do, you know, how to better, or we can add it to the adopt a plugin. Right. The tutorial is like, how to maybe document your stuff better for being able to work with things like this. Okay. How do you, how do you get rid of the dollars class thing? Yeah. Right. Because notice there are some of these here that very nicely have a short word like accurate. And, and they just did something that this other plugin here that's very heavily used, didn't, hasn't done yet. Exactly. And so telling people this is how you do that thing is already quite valuable. Yeah. Yeah. Because the, the parser is kind of, it's dumb. So it will take whatever it's being told. So yeah, you're right. Like that the file system has, must be telling it to be, it has used this nice name. Yeah. It's got a symbol. It's got a symbol for file system. And there's no reason we can't teach people and encourage people, hey, you should actually use this file, this symbol thing, because it makes the experience better for your users. Right. Right. So I have a question regarding this page. So I understand the problem here is it's a long page if we expand all of these options. So what is the expected outcome? Like, like what, how do we want to improve this? How will it look like? Well, so, so there were two or three different alternatives offered and one of the parts of this project plan would be proposing which one you think is best to do. So for instance, logical partitions of the page may be one page for each checkout in this very special case. This checkout thing is, is sort of a one of a kind of its, of its type. There's one other, there's one other step that is as bad as this, but only one other step. Yes. I can't remember which one it is right now. It's the build step. I remember it very painful. I was like, I want to say it's build, but I'm like, I can't a thousand percent. Yes. Yeah. So the build pipeline step is this one right here and you'll watch as it loads and loads and loads. And it's just, it's all inspired because exactly the way Kristen described it, it looks at every one of the 1800 Jenkins plugins. And if any of them contribute to this, this thing, it will put its documentation there, which is very powerful, but also very large. Yes. So separator, what a cool, what a cool build task separator, really, huh? Right. I was like, but unfortunately end up with that. There's no extra information. So we're like, what is it separating? Yes. What does that mean? What does it mean? Right. And it's those kinds of things, right? Or run, run. Well, that's a pretty generic name, run, huh? Right. And it's so good. Like there's so many interesting things that we're going to be able to, or like, I think, you know, it powers people to see stuff from pipeline, but there could be some better stuff. And again, like we probably need to revisit the description because that description has been there even kind of in general has, like even the project proposal has been the same for, right, multiple years. Yeah, a period of time, because no one seems to be interested in it, because it's not as, I mean, it's not as flashy maybe as some of the other, like other project types. So I don't, yeah. Right. This isn't do some new feature that uses AWS and Google Cloud and 42 REST APIs. This is improve the experience for people who are reading the documentation. Right. So Dheeraj, did that answer your question? Kristen and Meg and I will go off on this thing for a long time if we're not careful. Yeah, it makes sense. Like do logically partition the page so that we don't have all of them in one page, right? Right. Well, So what would be the logical description of stuff that's in the base and then show the others which product we're going to come from? I mean, what would be conceptually, what do we want? So for me, I would think the checkout page and probably the build page would be split into end pages, right? Where one page per nested object here and on that nested object page, it would have a include a link, not just to the plugin that, so this link gets me to the plugin that provides checkout SCM, but it would also be the link from for the plugin that provides this symbol. So this link on the new page would be to check out a SCM, this one would go to the AccuRef plugin, that kind of thing, Meg, and then the documentation and probably should start expanded rather than opening collapsed. Here, if we start expanded, the page takes a very long time to load. And Meg, your expertise would be amazing, wonderful to have as a potential mentor or at least a technical resource, or you can even say a technical resource. And I know it's like maybe a technical resource as in, being able to have good layout, good flow, think things readable. Exactly, right. Don't worry about having to run anything. Yeah, I'm just trying to figure out, yeah, I'm still trying to see what I would like this to look like. I mean, there's no difference between, there's no way to tell what's the stuff that gets used a lot versus the stuff that you've been one corner case for one. Exactly. And quite frankly, I don't even know what they are anyway. Like, I wouldn't even know. Well, that's a, you've got another angle there, Meg, that maybe we ought to have a way of connecting metrics or collecting metrics on the use of pieces of these pages. Right. Well, that'd be cool. Because right now, I know, actually I do have metrics on here. I'll show you the site that I have metrics on. This site right here. This site, we have quite interesting metrics on what comes from its search engine. So that particular word that I just entered has been the number one search item for the last nine months or more. And the next one on the list is that search item. So get and pipeline. And so it makes a big deal for us to say let's be sure that those things are well documented. Yeah. So, but I don't, that kind of data may be available for these pages. I've just never seen it. Yeah. Okay. Is that something that would be hard to implement? Could that be something that we would want to add as part of the store, as part of the task for? I think it very much could be done. And certainly Gavin Mogan is very familiar how to do it and how to use it well. So we've got people who know how to do that. Gavin uses the search data here to guide his development of the plug-in site. Awesome. So he ends up- So it's something useful to have. Yeah. As well. We can add that to the description, just as like, oh, another thing to, or another thing to add to, as a possible route or thing to do. Right. Well, and another thing to review is, okay, and this is rather painful and sometimes filled with expletives that shouldn't be used in normal civilized society. But here is unfiltered feedback from readers who sometimes say in no uncertain terms how badly they dislike something or other. I don't know. Oh yeah. It's, it can be very painful to read some of that. So it's like, wow. Yeah. I went through it and it's very different. Like people are very vocal about things. Right. Yeah, that's a polite way to say it. I love it. Well done. Vocal. It's not that they said things that their mother would have probably scolded them for if they detected them saying that publicly. Dear Ash, you're sounding, are you interested in this? I'm not sure as of now. But maybe, but I need to understand like what's happening there. You said that the document, the page which we showed the 62 long page. So it has those parameters which are coming from all the plugins, right? That's what you said. So that doesn't make sense to me as of now. So I need to understand how that thing works. So there's some work needed from my side. Then I'll be able to decide whether I'll be able to do this or whether it interests me or not. Because, well, the thought that I had is my mind's boggling, but as I read the details of the proposal, it's kind of saying there's a problem. And it doesn't, I wouldn't, if you gave me a very experienced programmer who's not familiar with this, I wouldn't know what to tell them to do. It's... Well, but, and that's the nature of most Google Summer of Code project. Right, exactly. I expected that the person submitting will submit a proposal of I proposed to do this. And in the investigation stage, part of it is in the, even before the project is selected, it's do your research to decide what you'll do. Okay. But for Dheeraj, I'm not sure that he's, he's a terribly viable candidate. Dheeraj, you've almost finished university or have finished university, right? So this, this would be competing with full-time work for you. Right, yes. I guess, I was thinking more just to fix this back curve. Oh, oh, I see what you're saying. If you have any other type of, if you have any other comments or anything else, please like make them, you can mod if there's a section of the website and stuff that has all the Google Summer of Code suggestions, like feel free to update it or ask questions or like, you know, hang on the documentation channel. Like I would, that would be great. It would be amazing. I actually talked, it's so funny. I talked to Alyssa last week so I was like, oh man. But it's the other one I think that we need to cover. I don't know, Mark, if you were gonna hit that was the automatic specification generator. That's the other one that's documentation related. Yeah, so the REST API doc generator is right here. And Kristen, you're an excellent one. I'm terribly weak on this one in terms of what I think this one's less well-defined than the earlier one, for me at least. I would have to do it. I think what we need, I think that the gist of this is what we have for the pipeline steps we want for the REST endpoints. And then we will publish it as a open API document or like a Swagger doc. I think on the, I thought like, I wasn't even the one that originally came with this but I was like, I kind of adopted it because I kind of knew a little bit more about how this is for you. But like, I think we want it published on the website and I don't know if we also want it somehow in Jenkins but I think it might already be there. But I definitely don't think we want it on the website. So similar to how we have the pipeline steps we want just basically what happens with the REST endpoints. So very similar, there's a lot of libraries out there now that can do this type of parsing. It's again, like gathering everything all together and like passing it into the right code and then figuring out how to get it hosted on the site. And if it's on the site, that is everything for the steps generator on my private machine I can run that and get information about just the steps that go with plugins I've got installed, right? And I would use that for the REST API. And that we, you've actually already got. So today, today Jenkins locally will tell you your REST API endpoints and it gives some at least interesting hints. I'm gonna try to call it documentation but it gives some pretty good hints about this is how you interact with this thing. Great. So this is kind of taking it and using a standard. And there's like a ton of tools out there that can, we do not have to like put the UI and put the standard in a beautiful format. So it's easy to read. So it's not like we would have to like, you know, completely write a new UI for this. We just basically can use some tools out there that exist, but it's getting it into this format. And if we publish the specification in the open API format, other people can create, they can basically import it and use it to create their tooling based on what the specs is. So it's just kind of a little bit more standard and out there it makes it a little bit easier to interact with your Jenkins in a programmatic way. Right, right. And so this is a great story for, hey, if you're interested in a coding project in Jenkins that would be deeply loved and is related to documentation, this is the thing. It is very much coding. This is not writing documentation in any sense of the writing that we do ourselves. This is code all the way end to end. I feel like we would, as a document, I feel like it'd still be considered to be sponsored by the documentation site as another thing is figuring out who we want to host it. Okay, cool, cool. I was like, wait, just don't like we do it here. So we want to figure out where to put it and then like probably some extra stuff in the repository about this is how to run it. They're like, this is what they can use for, and you know that type of situation. Right, absolutely, yeah. Is there anything that we could put out that would be a project for an actual tech writer? There is not because Google Summer of Code is not designed to bring writers in. There's Google Season of Docs that's for writers, and that's, we've done one of those, we did one of those where Xenob was the writer we used and she did the writing on the Kubernetes install process as part of Google Season of Docs. But for me right now, we've got more traction on Google Summer of Code and I want to keep focus there. Yeah, just curious that makes perfect sense. Okay, anything else on the two Google Summer of Code? Oh, go ahead. Dheeraj, was that you? Yes. Yes, so you were suggesting me that it would be difficult for me to compete with other people like because they are full time people, right? That was what you were saying, right? No, I was more worried that because Google Summer of Code assumes that you will give at least half time for the entire summer, so you do it, provide at least 20 hours a week, every week for a period of, I think it's 12 weeks, it's at least eight weeks. And my guess was if you're working full time for an employer, you probably won't be available to also give 20 hours a week over the summer. That's true. Yep, that's true. That doesn't stop you from... Go ahead. Yeah, I also read somewhere that we can also extend the length of the project, right? According to the discussion between me and the mentor. Oh, I wasn't aware of that. Okay, that would be... I would have to read that to see. Is that a new thing this year? I think so. Kristen, do you know about that? Yeah, I feel like they added some stuff this year. I haven't 100% caught up with the new direction are, but I know that they are trying to expand it beyond just people in school, university or school, I guess in general. But I don't know if they had... Because I remember first season of Docs, there were like the two options where you had two different types of timelines. I didn't know if that was also being expanded here, but... Okay, so the program would no longer be solely focused on university students or recent grads. Okay, that's good. And now it's multiple... Okay, this is... All right, multiple sizes of projects. Okay, that's kind of cool. Now, what does... Okay, so this year we introduced a medium-sized project. I know that there's ones that are supposed to be shorter. I think if you do not have the full period of time, it was like a... But for, I think, non-traditional or like shorter seasons because of coronavirus expanded school length, I don't know, I don't know. But it's... But maybe it could also be the fact that it's... You don't have to do 20. Yeah, so, okay, so here's the magic. So, Dira, as you were right, it says rather than a mandatory 12-week program, June to August, it can be mentors and GSOT contributors can decide if they want to extend the deadline for the project up to 22 weeks. I'm not entirely sure what that means in terms of calendar then. So they've granted flexibility, which means 22 weeks is well beyond the end of the summer or it will be on September or August, and interesting. Does that mean they're expected to do 20 hours for 22 weeks or does that enable some disease to say 10 hours a week? That's what I don't quite understand. It'll need more research. So that's a good question. And that might then allow someone who, okay, recent graduate has just taken a full-time position, still wants to do Google Summer of Code in their non-working hours. This might be the way to do it. Yeah. It might mean I think distributing the 350 hours in 22 weeks. Yeah. And if that were the case, the math then says that's something between 10 and 20 hours a week. It's less than 20 and more than 10 hours a week. So that would be much lower impact on someone's personal schedule than the expectation of 20 hours in 12 weeks. And some employers actually to get a Summer of Code person in there would be a coup and they might give you five hours a week to work on it or something. Yeah, that might be as well, yes. Some would not, obviously. Yeah. All right. Any other questions, Dheeraj? Okay. No, that answers my question. Thanks. Okay. All right. So Sheikot Africa Contributon was the next topic on our agenda. Are you okay if we talk to that one or do you want to take other topics in the 15 minutes we've got left? That one's good for me. They're all interesting. All right. So we have two more, this and the plugin one. Yeah. I'm not sure the plugin needs an awful lot of time for us. So that's, I would be okay, I'll take it back. There was one other, but I'm not really ready for it, which is the end of year review blog post. I can show you a working prototype of it, but it's shamefully incomplete and needs several hours more work before I'm ready to submit it as a pull request. So next week. Well, I want to get it out this week. So I'll just invite you all to review it and I get it submitted as a pull request. Cool. Okay, cool. I'll be able to help because I'm comparatively free from this week. Oh, good. Very good. All right. Well, so then I'll ask for your review, Dheeraj, because yeah, it's, I've realized the Jenkins project did amazing things in 2021 and there's an awful lot to talk about. As I look through all the things, it's like, wow, this is really like 10 or 15 or 20 pages of descriptions of cool things we did. So you'll see it. All right. She, okay, with Sheikot Africa Contributon then is the next topic. Sure. Okay, so they've changed it. It's going to be rather than four weeks from in April, so April one to end of April, it's going to be, or no, it was, what was it last year? I think we did March one to March 31. This year they do April one to May 15 and they're going to intentionally add a community bonding period. You following the pattern that Google summer of code does where you have a startup period that is not focused on the coding for the project. Then the four weeks of coding and then a one or two week period where they ramp down and write their final report. So big plus there, that's a really good one. Was discussing project ideas with Xenob in last Thursday's meeting to the came to mind inclusive naming. So getting rid of more uses of master, of slave, of blacklist, of white list, those kind of deprecated terminology that is still in far too many places. Then we could reconsider possibly a refinement of last year's pipeline help project, try it again. There were some problems there that it would need refinement and improvement to be sure that it didn't have the same problems we had last year. We want to get new problems. Any other suggestions you have of things you'd like to offer as hey project ideas we should consider knowing that these are brand new contributors with at most a little bit of university or trade school experience and certainly not experienced Jenkins users. And again, our pool does not include people who want to be tech writers, right? It does not. These are typically programmers. Yeah. What about test suites? Are our test suites common? Yes. That's a good one. Yes, that's an interesting one. And a chance to push this thing of the coding's not done and testing to be testing for functionality as well as performance and security. Is that? You just offered what I would call two out of the three of the things you offered, I would consider advanced topics needing somebody who's got prior Jenkins skill. But I think there are some things we could do in test automation that might be a good story. I've, for example, enjoyed having net beans generate stubs for me for objects that I then fill in the stubs. But the problem is there are all sorts of things hiding there in terms of many traps you can encounter and many sorts of problems of, oh, don't call that, do call this. And lots of things to do that I worry that it may require more skills than we can get them in four weeks. Right. Unless we had some very specific targets. And I'm drawing a blank. I'm thinking about in various discussions we've seen a problem somewhere and we said there should be a test for that. And we all laugh, which we'd log those. Oh, well, and certainly I've got, I've got lots of, I've got, I've got a very specific example. So the get client plugin uses JUnit three tests. They need to be converted to JUnit four. Ah. That's actually, I've probably be a good thing to do. Are there any other plugins that have two unit three tests? Oh, yes. Absolutely. It feels like that could be something where a lot of people can help. Right. And as long as we get via, I can imagine if it's a popular or a bigger plugin, it might be a, oh, thank you for helping. Yes, we will help mentor this, but it's, it takes the time that they can focus on, you know, solving a technical issue versus spending time updating tests. Yeah. Yeah. Now it is somewhat of a mechanical transition, right? So it's not, it's not a deeply, deeply intellectual experience, but the flip side is it's awfully easy to make mistakes and render a test that was useful in JUnit three, non useful in JUnit four. Well, even if it's mechanical, if there don't have a whole lot of experience, it might even be worth seeing, this is what you test for. This is like, these are the past, this is what you have to think about. Right. This is how to, how to correctly write the test in JUnit four. And especially if you're saying that you can have something that was useful and make it unuseful, here's what the difference between a useful test and a non useful test is, you know, from the perspective of, oh, you're just running over something, auto-generated thing or something. It's like, no, you need to actually test this type of thought and like. I like that. Because they really, I mean, if they're not, if they're not experienced four weeks of coding is not time to do anything very complicated. Right. And the, you know, we had to keep reminding ourselves the purpose of this is not to improve. Improving Jenkins is a nice sideline. The real point is to start to educate these girls. And then that would be, you know, testing being sort of the Achilles heel and dev ops right now. This would be a great thing to get them going on and all the stuff that Kristen said, we can really. Yeah, so the good insight. Let me, let me do some quick research to see because it's an, it's an easily detected, detected condition. J unit three tests have a certain pattern. J unit four, a very different pattern. And, and it would be an easy thing to say, but here are this many, let's outline the project that would say, these are the, this is the conversion we need to do from this to this. And it's relatively mechanical. Yeah. So it would, it's something they could, at which they could succeed. And it teaches crucial skills in, in test automation, right? They'll spend a lot of time in an IDE, a lot of time in a Java debugger, trying to decide, okay, this is doing what I expect, et cetera, all really good skills to develop. Yeah, I'm liking this. Okay. All right. Good, good suggestion. Any other project ideas? Are there anything like any tutorial or I think we've updated most of the startup guides, right? Like, because that's the other thing is like kind of going, if we're trying to focus on some of the documentation stuff, making sure that all of our getting started tutorials are all like up to date. I think they're okay. No, there are quite a number of them that are, well, there's one in particular that's really embarrassing. I just had a new person report to me at work, joined the company and sent them through a Jenkins tutorial. They said, well, whoops, this is terrible, awful, no good and very bad. Because it does so. So the fix multiple tutorials is a really good idea, absolutely. Right, because it's just getting started, like maybe it's the, this is how you start to, you know, when you start to do software, here's where you usually go and like figure it out or like what are pitfalls that you ran into when you were trying to get it started, how it can maybe help somebody else. Right. I think a lot of those may have the diverse terminology issues and outdated screenshots, because most of them were done before all of the UI changes last year. Oh, that's actually, that's a very good one. That might be a separate activity, screenshot. Because by then, that timing is very good because screenshot updates might be, because April is after the March release and the March release 2.33x.1 release will include significant UI updates. Good timing. Okay, so screenshot updates is a valid thing for us to consider for, at least for those cases where we have them. I don't know that we have an awful lot of images in the documentation, but there certainly are some. Yeah, but it could be, and for them to just go through those tutorials should be appropriate for them to follow and sort of review it. Yeah, trouble fix it. Right. Yeah. So, and the one that had the big problem, the big embarrassing one was this one. It's the first thing you see, and yet there are plenty of places where it is assuming a bunch of things that you cannot assume are known to the person running the tutorial. Oh, no. Yeah. It's, so, so good, good point. Yeah. This would be fixed multiple tutorials might be a really good one. And something is under our control. Right. It bugs me that these tutorials don't have more links to, you know, where you're, we're doing something simple here. If you want to know everything you can do with this, go read the documentation. Right. I like getting started guides that are sort of a gateway to the big picture rather than I just did something useful. And I understand what I did, but how do I do something real? Right, right. Good, good point. Exactly. Because for people like me who are starting up and want to know about Jenkins, if there's a tutorial present, or they're ready to getting started. So that is a really plus point for me. Like I can start up with things and as Meg said, it should be a gateway to the bigger picture. So that's how it should be like a better, easy part to, you know, to understand the product. These might be really, really useful. Yes. Good. Very good. Thank you. I did not. You are an unexpected source of delightful extra ideas. Thank you very much. This is great. Now, one more thing that's on the list is. As part of improving the experience for the participants, they're going to do general purpose knowledge sharing sessions with where they invite all participants to a session about this or that. So for instance, how do you use GitHub? Well, what's marked down and how do you use it? What's ASCII doc? What does it mean to write a good bug report? Those kind of things. And so, and I think those are, those are all good things that we can point them and say, and some of those we can, we can help significantly. Great. Excellent. All right. So we have run out of time. Are there other topics that we need to do in the last, in this last minute or are we set? Yeah, just one question. So as you have. And all the other mentors potential mentors have written on the topics on Alyssa's community. Post on the inside. So my question is if someone wants to know more about it, I think this is the right time to know more about it. Because it's still in the process of getting combined. Actually, this is a great time to ask about it. So let's go, let's go find it. Let's go find her post. And let's see where was it. It was here we go. Google summer of code. So this is a perfect time to ask about it and to start conversations about any one of these things. Yeah. So would we be asking it during the GSoc office hours? Or what do you think? That's also a good time to do it. Absolutely. You could ask questions here in the community forum. Could also ask questions in during office hours. And we've got to get the office hours scheduled. Awesome. So that answers my question. I'll be asking if I have any doubt in this space, right? Yes. Yeah, this is a, this is a great place. I think this is, this is looking for his project right now. It's looking for project ideas, but it also in general has links that take you to the project idea pages where you could start questions and conversations. You know what? Actually, I've got an ingenious, a devious, terribly devious idea here of how we do this to encourage conversation. Watch what I'm going to show you now. Okay. This is, this is. When markets devious, it is fun. All right. So what we see here is this is a blog post, right? This blog post has a one line entry in its definition, which takes it includes this discuss section at the bottom. And I can click this button to continue discussion. It takes me there. Well, I think we ought to do the same thing for these project ideas. So for instance, this page edits at the bottom of the page really, if we could find a way to do it should have a link that takes it to community site for discussion. Uh huh. What do you think? I was going to ask you the same question like when he says to me like click on that particular link of the project, then I was going to ask them, where should I go next? Right. And we should have the discussion section, right? Right. So if we could create a page, we could, we, if we, if we put that discussion link at the bottom, when somebody clicks it, it will start. If it doesn't already exist, it would start a page that talks about this thing. Oh, it would start a topic. Oh, okay. So if we make up the community, the Jenkins IO space for each of these projects, then they would automatically be having the discuss button at the end of the page, right? No, that's that I love your optimism. That's excellent optimism. No, we'd have to, we have to be sure that it would work and we would have to put a a one line entry at minimal one line entry into these pages. To show here, I'll show you, let's go to the improve this page. So this, this page here. There is a, it would get something like this where we would say. Discuss. True. Or it would be discussed. And then there would be some URL. That goes to Jenkins.io. Or to community that Jenkins.io. So that's how it would work. But that we would do once somebody would make that change once and then discussions just work. I think anyway. That's great. Yeah. Now the question is, we got to prove that I'm not just lying. But Oleg, when he added that facility for blog posts, I think we could follow the same pattern and do something similar for Google summer of code project ideas. That sounds great. Yes. Okay. Good. All right. Any, anything else on, on that topic or on any of the topics. Yeah. Yeah. And with the funding, are we going to, last year we ended up with more money than we had mentors. Are we going to be encouraging these companies that are willing to fund to fork over a couple of people to. Yes, that's been, that's been the most, that's been the most blunt part of the whole exercise is Zina. And I both agreed that the crucial thing is. Yes. We absolutely need the money. Right. She called Africa has to be more expensive than we have the money. Then they can't, they can't pay the women. But we've got to have mentors. Last year they had over a hundred applicants. For what we're ultimately 20 positions. In fact, I think that over 150 applicants for 20 positions. Wow. So, so it's, and, and I understand. I mean, as an open source contributor, the time I give is, is precious. Right. I mean, I don't, I don't know, I don't know if I'm comfortable about it, but there's a piece of it where I need to put my money where my mouth is. And actually agree that I'm going to help these underserved communities. Yeah. The great thing is at least there, it's showing that there is a huge desire. Right. That that is, that's to me also like, so we can't fund everybody, but I'm really happy to see that there's that much interest. And something that was brand new last year. Yeah. And last year was the inaugural year. Yeah. I think that's, it can all hopefully like. But as I recall, the message was largely, we need money. Yeah, that's what I remember too. You know, and to, and to, but to, you know, I'll add a little bit, you know, and we need. You know, we need mentors. Right. Right. It was it. And just the fun part of that is it highlights that. I guess what we don't always guess correctly as, which is the, going to be the biggest challenge in a project. I don't know why that ever happens. You know, I'm always perfect and everyone of my guess is about projects. I mean, I think the statistic. You know, you'd have to meal money, but that we had more than a hundred qualified applicants last year who could not be accepted because we did not have enough mentors. Right. And that's a great story to tell just to say, look. This, this is why we need to be actively encouraging people to come mentor. Right. All right. Great. Okay. I think that's it then. Thank you. We'll meet again in one week. And I will certainly copy. I will reference all of you in the poll request for the end of your blog post. Cool. Thanks everybody. Thank you. Thanks. Bye.