 So welcome to the documentation office hours. It's the 26th of April, 2021, and we're doing office hours for Asia and Australia today. This is great. Thank you very much. So here's what I've got as possible topics. We've got the she code Africa contribute on running we're in the very last week of it. And then I just received today the search report from the Jenkins plug insight that may give us some insights in terms of documentation. Are there other topics that you would like to add on to our agenda. Yeah, I'm a little bit sick. And so, so the car you're reminding me I should have the decency of making this big enough for human beings to actually read it. Sorry about that. Yeah, terrible. Yeah, and so the car are there any specific topics you would like to like to discuss so I know we've got, I guess one that's on my list is contributor summit. So we're coming up June 25 with the CD con conference. So if you're not registered for that so we should, we should talk about that. Sorry to the car and here I am interrupting anything else you would like to put on the agenda. No, the only item I wanted to check was I was interested in the Google season of talks project. Okay, and are you. So, if would I get reviewers, if I decide to. I am willing to do it on my own time. So, I would okay. All right, well so let's, we certainly can spend time discussing that I would love to discuss it. Let's talk about it. So, Mark. And so the car. All right, go ahead. I missed that said, could you say that again. Sure. So I was wondering that we can have a really, really brief discussion about documentation related to jasks. Okay. Great. All right. Good topic. Any other topics. Do we want to revisit the issue of the steps documentation we've gotten some with she code Africa but I think we've still got a problem in that area do we want to talk about our future. Yeah, that's, that's okay that's a very good one let me, let's pipeline steps improvements how about if we put it that way mag and then we'll, we'll talk strategy about it show it with Sudhakar and Dirac here here both it's good to have extra that's advised to look at it and, and give inputs. Good. Okay. Any other topics. No, that's it from my side. Okay, good. All right so Sudhakar you had mentioned. So we had, we had proposed the Jenkins project proposed a Google summer of docs, or Google season of docs project. Yeah. But it was, was not accepted. They only accepted 30 projects this year, and we were not one of them. And so we're doing a retrospective now to try to understand what we could have done better to do a better job, however, there's still an opportunity for us to consider. So the project definition is still there. Yeah, right. It's available, and it's Jenkins on Kubernetes. Yeah. And so that's that's certainly very interesting for for us to get further documentation for Jenkins on Kubernetes. I think your question was, are we willing to review pull requests. Yes, absolutely. We're willing to review pull requests. Now, if the second question is, is the Jenkins project ready to fund a writer to do the writing. The answer there is yes potentially in the future. So we're willing to review pull requests immediately. Okay. And when I say in the future is the project willing to fund documentation development, something like, like GSOD would have been and the answer is, yes, the governance board has has been has been willing to consider that. Okay. The problem is our mentors are are loaded right now with Google season of code or Google summer of code. And that will continue until September. So the likely time when a funded development effort would be is probably not until September at the earliest. For me, that's okay, I can start and maybe by that time I'll finish it, but funding is not a real need for me at this time. Okay, all that I need is pull request review, like for example, right, I will do an initial outline as to how I will approach it. And then maybe in another one or two submissions, I'll finish the submission. And that would that would be absolutely exceptional so we've actually got a, let me give the, this is my rough draft that you, you are welcome to consider as as just a rough draft and see hey what would what could we do instead of that. My rough draft came in this Google season of docs 2021 application. Oh, no, no, hasn't been merged yet shame on me. Okay, so let's go look at the pull request that's proposed to include it. Or maybe, maybe I can find it. No, that's not it. Okay, just a minute, I'll find it, I promise. It is right here. Jenkins.io, the pull request hasn't been reviewed and merged yet so it is this one. And included in it is a detailed document about proposing an outline for the for for the whole thing. So, so let me embed this link. And if I can find it, I will also embed this the page is actually already there I just have to find it in the navigation so just, if we give it just a minute. And we need some projects Google season of dog or something. Yeah, here we go documentation season of docs. Let's go find it here. It's got to be this one I think is it. Yes, there it is okay so here is my, my poor and just so you're clear so the car poor attempted an outline of the kinds of things that we should we should have covered and be warned that as a, as a as a contributor. So the worst of all possible people to suggest what is the best way to describe Jenkins on Kubernetes. I don't have enough Kubernetes experience to be a good one so this is a great opportunity for somebody to come in with much better proposals than I would offer. Yeah, I, yeah I have taught the cloud computing and systems for that and it takes for graduate students. Oh, wonderful. Oh, so you have you have real world experience. That would be absolutely exceptional. Yeah, so yeah. Okay, so I'll take that outline and start off. But I just wanted a calm, a comment and a question basically the approach would be to describe it how to install using mini cube. And most of the features of Jenkins. Right and yes, and then, and then provide links for the different cloud provider platforms. I think that is, that is an excellent approach, and I can give you links to, to the existing materials what we've got now. Last year we did a Google season of docs project that started this. And so we've got installing Jenkins on Kubernetes. Yeah. But, and what it has is. Yeah, let's see it has mini cube. Any cube. I think it has helm charts. Yeah. And it's got one other variant that I don't recall let's see oh YAML files right or two others YAML files and Jenkins operator. So, okay. And and those. And Jenkins operator. And of course Jenkins operator is an active project for for this year as a proposed project for Google's summer of code and so this one will likely get some attention. YAML charts are actively being developed. YAML files, not so much charts. So yes, absolutely that's that's there and then we had an additional section that was added that is incomplete, but has been published and is available under scaling Jenkins on Kubernetes. Okay. Yeah, just one other question. So now we have Jenkins X, right, that is being also being pushed. So what is the motivation for documenting Jenkins on Kubernetes. So, so there are many, many use cases that Jenkins Jenkins X is intensely focused solely on Kubernetes. And on delivering micro service based things into cloud native environments. And that means there are many, many use cases that Jenkins X just can't do on the flip side there are many, many things in the cloud native world that Jenkins doesn't do as well as Jenkins X does. One is a horizontal, broad application Jenkins and the other one is a very intensely focused vertical application Jenkins X. So they each sort of have their own sweet spot for where they, where they fit and there are many, many users running Jenkins on Kubernetes because they need to be able to deploy to what you might call classic environments where they're running on Kubernetes for elasticity, but they need to be able to still deploy back to virtual machines or they need to be able to deliver code that's built on Windows and as an application or builds for an iPhone or for a, an Android phone. Okay, yeah. Okay, so, yeah, I agree Jenkins is kind of a canned solution for Kubernetes Jenkins X. Right. Yeah, yeah, okay. Yeah. I do be needed. Oh, that's all I had. Excellent. Well, thank you that's great looking forward to that to the car. Thank you very much. That's really wonderful. Yes, thank you. All right, so next topic then was jcask plug in documentation so do you want to give us some insights on what brings you to the question and share with us some of your insights. Sure. So, am I audible. Hello. Yes, yes, yes. So, while working with jcask, I started just few weeks back and I was trying to understand how it works. And I searched the internet to understand what's the logic behind it and I was able to find many, many blogs. And each of the blogs was describing like how you generate a YAML file and how to upload that YAML file to Jenkins and how you can just magically see that everything is being done with the help of that YAML file. And all is good for all of those kinds of blogs, but from a person who wants to contribute to jcask, I think blogs need to cover something more than that. For example, they also need to tell us like it might be really great if they can tell us as well like how things are working inside at the class level. Like how the YAML is being passed and each of the identification level data is being taken and being put into Jenkins and how Jenkins is using that and configuring itself. At that level, I'm more interested in. Now, the question is why am I interested in that level? Because if I as a contributor knows how the changes in YAML files are going to reflect in the Jenkins at the class level, then I'd be a better contributor. I can contribute to this plugin really well and it would be really great like the contribution level for this plugin would be increased from even from college students as well. Not be restricted to someone who just knows lots of has lots of experience in coding. That's what I was aiming for. Yes, because we don't have the for official documentation, not counting blogs for jcask is the read me in the repo right mark. That's that's correct so make already highlights a very good point that that so let's let's identify some of the weaknesses that currently exist right. So dear as noted one developer documentation. The other is there is no documentation for jcask on www.jankins.io right it's or almost none I think it's just blogs. Not docs, you know, not a not a manual that talks about it. And so so that's already and then you noted developer documentation is mostly inside the plugin source code. And that's that's not a not not always conducive to a first time developer. We do have, we do have a get our chat channel dedicated to jcask. It doesn't fit. Okay. There we go. Okay. And we have a special interest group for jcask. And so that one I could link you to it as well. If we can find that configuration as code here we go. And now lately though the configuration is code special interest group meetings have not been happening. There wasn't a significant sufficient interest amongst developers were actively working in so that those are two places though that you whoops that you could certainly ask. Go ahead make. Oh back to weaknesses. Maybe I'm just too much of a writer nerd but I would once we get jcask documented well, I would like to have it sort of integrated into the regular Jenkins configuration. So when you're when we're telling them how to do this and how to do that. You know I don't know what the thought I had I don't know if I think of it when I got in there, but to say you could do this with jcask instead. Right, good point where because ultimately what I want to do is configure my Jenkins I don't care about the tools I want to configure right yeah exactly. Yeah to the extent that I've looked at I've only looked at it a little bit, but I almost feel like we need reference material or something because if I'm used to the gooey I see these nice long English sentences, do you want this or that. And then when I look at the cat the jcask files. It's all this cryptic annotation. And I will say that most of the time I can kind of guess what it is but it's not crystal clear it seems to me that we need some reference somewhere that says, you know this is the equivalent of the English or whatever. Dear us do you have do you have suggestions in terms of what you would recommend is how we approach it. Yes, so as just mentioned by make if I understand correctly, we are looking for a reference for a Jamel file when we're configuring a plugin, let's say, right. Yes. So I was looking through the people of jgas and I found out that they have a demo folder in which they have added the example configuration of some plugins, not all some plugins. So if you click there are many plugins there and if you just let's say click on get. And under that there is a Jamel file and it shows what you need to include in your main Jenkins dot Jamel file in order to include this get plugin there. So it's like an example for user who just is very new to get plugin copy and paste it. But the problem here is that not all the plugins are covered there. There is some contributions needed from students or developers, because there are so many plugins and I think in that demo there are around maybe 3040 plugins only presents. So yes, if we are able to include more and more plugin demos in that, then that would be great. Like for anyone just go there on that demo folder and just copy the Jamel configuration and just get to know how it works. Wonderful. Well I would say almost anything that you do which move us forward on this this is, I mean it's a hot new feature that everybody's excited about and then you want documentation it's like oh well go look at the read me in the repo. Yes exactly. And I was my second part of the question was that the same thing like if I can contribute to write a documentation as per I definitely need to learn a lot because I just found out about it few weeks ago but I would love to make it more simplified in the form of a documentation. Like the way you think. So would that be a good idea for me to take up this because I don't have like expertise on this but I can ask a question on get a channel and get to know how it works. Right, which might actually revive some interest I mean we've got, you know the same might get active again even if there's somebody. I think they sort of got it implemented and now it's sort of gone dormant right it. I don't know mark are they working on additional features for it or is it pretty much feature complete. Or, we don't even know. Mark you're muted if you're speaking. There, my mistake. Okay, so yes the, this is a great time to add, add examples. So, so dirage. The, the examples look like they are in the form of read me files with specific example code inside the read me. And for example, while we have get lab. What we don't have is a get lab branch source. jcasc example and so get lab branch sources of is quite a popular plugin. That's not here I guess another way you so my thought was how do you decide which things, which example to do next. You may say, I'll use plugins that I've got installed. You might say I'll do things based on the, the count of installations of the plugin. So, then you could look at the plugin installation counts to give you a guess. Hey, I should do this one next or I should do that one next. That sounds like a great opportunity. Thanks very much for your interest. Okay. Yeah, so that's, that would be a great benefit to the community. Now, now we might, I wonder if we ought to then as a future future idea as you develop more demos. Consider automatically copying those demos to www Jenkins.io so that they can be found by the to be found by more common users. I mean, because it's it's already got these things are represented as read me's right they are readable files and you can put. Yeah, look at that. Oh, that's if you go to the Kubernetes plugin, you'll be able to see multiple files in it as well. Okay, so, so if we look at you said Kubernetes. Yes. Oh yes, look okay look at this. Oh my. Good. Okay, so, so lots of ways that that these could be useful. Okay, this is what this is is this is showing how did what a Kubernetes config map looks like that has the configuration is code definition inside of it. Nice. Okay, and this one's even using job DSL. Wow, very impressive. I actually asked two questions yesterday on get a channel of jgas. The first one was that how do you decide which plugin demo you want to put up next on this demo folder? Like, how do you decide the priority? So, Tim actually answered me and said that we actually ideally need if we have as many plugin demos, that's great. But we go by the popular ones first. So that's the way forward. I think so we can start looking at the most popular ones if they are not documented here in this demo folder that we can add their configuration. Now, then I second question I asked to him was that how do you actually, I think this is a very big question. But for me, I had really I had doubt that how do we generate a YAML file for a particular plugin to add it into this demo folder? Then he told me that you need to just configure it on your Jenkins with the help of the UI and then download the YAML file from that jgas. You can actually export your configuration after you've done configuring in the UI. Now, when you export it, you get the very, very big YAML file and out of that you can just extract the YAML, which was automatically written there as you were just configuring it in the UI. Now that extracted YAML is what you need to put in the demo folder. So the problem I think here is that how do you decide what should be in that demo? Like if we take example of I think job view plugin, so it gives us many, many options to add lots of filters. Now if I want to add a demo of that plugin into this demo folder, like there's so many parameters, how do I decide which one I want to put in? So I have to do lots and lots of configuration. Where do I stop? Where do I draw the line? Like this is enough for a demo folder. Then Tim's resisted me that you need to just configure it as like it is sufficient as much. Just configure it that much. So last thing I want, I know I've been speaking for a long time. Last thing I want to add is that these demo examples in this repository, I don't think they can be meant as the best way to know how to configure a plugin. Because if I add job PSS YAML into this demo folder by just playing with few filters, a user will come here and see that they actually have a YAML file for job view plugin. I can actually use that. But they will not be able to understand all the parameters because I as a contributor only dealt with just two or three filters. So this is not the go to destination as of now for people to know about how to configure a particular plugin. That's the point I'm trying to make. So, I'm sorry for speaking so long. Oh, you were great. I wonder if we might consider our experience with pipeline steps as an illustration of the kind of thing that you were just describing. So what we've seen is that with the pipeline steps documentation users often what we have is we have incomplete but accurate but correct material and it's incomplete in the sense that it gives the name of the argument but does not tell what the argument does or what it doesn't do. And what we've found is that users are grateful for that because at least it tells them oh this is what I have to do, but they want something more exhaustive. And what we found is the best way to get them something more thorough is to tell them to use the snippet generator for pipeline or in in the case of jcast to tell them to configure it from the user interface and then use export to do that. So, so now, Durush, have you had some experience with jcast because I could quickly bring it up for you and show you an export of a of a production sized instance if that will help. Yes, definitely. Okay, so, so here's my Jenkins server that I have running. So this is, this is a Jenkins instance, a controller that I have running that I use for tests it's got several thousand job definitions folders credentials, all sorts of things like that. So if I go to manage Jenkins, and then configuration as code. When I show view configuration, it will compute the current configuration and show me all sorts of things that are the samples of this thing so what right now what we're looking at is the encrypted credentials of these things. So we've got all sorts of other components, we'll get through the credentials here in a little bit. There we go. So now a bunch of labels that are defined on this one, the agent protocol definition which protocols are supported the authorization strategy, all here, and each of these I think as an example of the kind of fragment you were describing. So here's a tool definition for, let's see, let's find a tool definition. Here we go. Here are some agents that I have so some nodes, and it's saying this node has this IP address. And it is this computer name, etc. So, so here are your fragments. And what you do is copy that or save it to disk. The other thing we can do is just download the configuration. And now I can load it into my text editor like this. Oops, let's load it into the text editor like that. And there it is. And now I have ready to go all sorts of things that I can do with these. I can turn it into fragments just by deleting pieces of it. Does, does that, does that help with what Tim was describing in terms of view the configuration and download it. Yes, that actually makes sense to me. But that's, that's quite similar in terms of experience to the thing we get when we use pipeline syntax where we have the same kind of experience where I do something with it. Prepare this thing. And then when I click generate pipeline script here is the script that I would paste into my pipeline. And the same kind of thing as the, the same concept is applied in configuration as code, I can generate these fragments like that. Now, if you'd like to see examples of fragments of that here is another in case it helps you. Again, whoops, GitHub. Let's look on my GitHub, just a minute, because I've got a repository where I have a number of things that I track this Docker LFS repository under its LTS with plugins branch has some, some interesting JCASC example here so here is Jenkins.yaml and this is my, my JCASC definition that I'm using. And there, there are things like this all over right so there's nothing particularly special about this one. It's, but, but the concept is there. Yes. So it is a movie scheme generator for all these features. Good good question so is there a schema generator, and the answer is there really isn't because the, the JCASC is JCASC. What, what would you call them the data structure is defined by introspection of the Jenkins Java classes. Okay, okay. So it looks at the plugin class hierarchy and, and extract certain things out of that out of those classes and uses introspection to do it. Okay, okay. Yeah, very good question. Do you have anything else that you wanted us to be sure we all go ahead. Yeah, if you look back at all these shrink wrap products right until the first decade of the century. We used to do a lot of schema generation using tools. Right, right. And, and well, it's, it's a hint actually that computers have gotten so much faster that we don't even have to do schema generation will pay the penalty of doing schema generation live continuously. It's like wow really I am wasting that much processing power to do live schema generation all the time. Yes, actually, we're looking at the code inside of it, looking at having it look at itself and decide what the schema should be. Yeah, yeah. All right. So, anything else on on Jenkins configuration is code. I was wondering if you can tell me, like, you have written that how to decide what to include in a demo of a specific plugin. So you have written that configure in an interesting way and then save that right. Can you please tell me like the what how do you define an interesting in this case. So there, the, if it's, I think the definition of interesting is if it's interesting to you that makes it interesting. If, if you say, oh, I'm not sure what interesting means, you could look at other other locations for for ideas for instance, the CI that Jenkins.io configuration is interesting. And it's interesting because it's large, and it handles many, many things. There are other configurations like it. And since I think the machine release.ci dot Jenkins.io is now being tracked by by configuration is code. I don't know if you have access to read that configuration is code because it contains some sensitive information like the code signing keys, but, but those two, this one will tell you the interesting configuration of a Jenkins controller and others. Let's see, and I think my marks Docker LFS LTS with plugins is interesting, though, not. It contains no credentials, right it contains no secrets, no sensitive information. And so keeping sensitive information is an important topic so I did did that answer your question. Great. Excellent. Okay, so next topic then Meg you had asked about pipeline steps improvements. So for for benefit of Sudakar and dirage. You okay Meg if we first do a let's look at how bad it is. And then talk about where we're going next. Right. Or we could talk about what's happened with she codes with the contribute on. Yeah, which would you prefer we could do I don't care I'm good either way. Okay so I'm gonna I'm going to do a two minute overview of how bad things are oops. And then we'll talk about to about the steps we're taking to improve things. So Jenkins the Jenkins pipeline domain specific language is defined dynamically by the plugins that are installed in the current Jenkins installation. So here we also present a summary of all plugins and the pipeline steps that they implement in this pipeline steps reference. So this is, this is the set of all all plugins that provide any pipeline implementation, and only a subset of these are installed on any particular users computer but they are some subset is installed. Yeah, and this is an auto generated doc. Right, absolutely. And and it shows. So let's show how it shows what it means to have an auto generated doc and a doc that has been that is is the output of programmer written documentation. We love developers we really do but sometimes they don't write documentation much. Let's see if we can find here it is pipeline build step. Okay, so this one gives a reasonable description here of what what's the job parameter. Now what about and what does propagate mean and what does this mean, and oops, no description of what weight means. And if we start expanding things here, it gets gets much worse so let's say, what about get parameter. Oh, it takes a name and a value but that's it. No description of what the name means how it's used what the value is. What about a file same thing what about date parameter oh it's got a name of value in a description. And this is the kind of. Oh, wow, if you're, if you're using the Jenkins pipeline and this where your only source of information about how to use it. You are very very in a very bad way. Right it's this is this is not going to help you. But this makes it actually quite easy to use the pipeline. I just choose the thing I want and it generates the syntax for me. And getting frequent complaints from users that they were apparently reading this page without knowing that they could use the snippet generator. Yeah. And they just didn't know and so what we've been doing is having a team of writers in in West Africa. They're actually writing hints to people on these kinds of pages that says, please use the snippet generator. Although even there there's stuff like the one you were just looking at it's like name of project. Well, is that the display name for the project or the name I gave when I said create new item. Right. Even there some of that is not. And so the snippet generator doesn't tell me everything. Right. And, and there's plenty to be improved in. I don't know what's under the question mark. Yeah, but there's plenty to be improved in this right that is absolutely plenty to be improved about about what this is. Yeah, so now okay now make back to the, our top. We should we talked about pipeline steps improvement right. Great. I had a question. Basically, if jcasc gets widely deployed is the pipeline functionality visibility that much less critical. I actually they're they're quite distinct from each other. So, Jay, jcasc does the configuration of global and system level definitions of Jenkins things like which, which authentication method should we use. Okay, etc. But what's my LDAP server, those kind of things. I mean, it will remember the credentials for my GitHub server or for, but what it does not do is define the code that should be executed while running a pipeline, and that really needs Jenkins pipeline. So, so that distinction is is the is the subtlety there. Yeah, yeah. Okay, got that. Okay, jcasc. Yeah, excellent figures the environment for Jenkins. Exactly. It truly is my mental model for it is is just configuration. It's not execution, right, it gets the initial conditions set and then steps aside. Okay. Yeah, thanks. So now in terms of of persuading people to use the snippet generator. One of the things that we've gone after was something like this as an idea. Oops, let's just do get maybe that's what it is. So I get for editing the URL shame on me. Okay. This is not even the right page right this one was the, the idea we had was should we try something like this where we embed a link to a video into the page in hopes that some portion of the users will click the link and go to the video. So watch. And this case it says this is a 90 second video clip. Watch it on how you use pipeline syntax. Now the hint is, it's only existed for. Let's see, so March, April, May, just approaching three months and it already has 1500 views. So it's it's not been ignored. And so there's some hint that this video technique might actually be be helping some people. Yeah, yeah, yeah, yeah, pipeline connector will be very useful, given that every project. Right. Yeah, I agree. Now Meg, that's, that's me blathering, which, which pieces of pipeline steps improvements that you want to highlight. Well, I'm just thinking, I mean what the sheet we had the sheet coders had a couple of steps of plugins and I think we decided to not have. They were high priority ones, but they were so complicated. We couldn't figure things out and we gave them something more. So we still got that. We're going to find more people who want to keep working on this. I see what you're asking so that's, that's a that's maybe that's worth highlighting here in this session that have not yet been touched right have not yet been touched to improve their documentation. And so for example, what we did with she called Africa is we generated a pivot table of which plugins had the most complaints. Now this is a this is an awkward kind of pivot table right this is, this is not the thing you say oh everybody's happy about it it's rather which things cause the most complaining. And here is this table that shows the most complained about plug in was the build step with 86 complaints of those 86 only one said the documentation was very helpful. Every other one was worse than very helpful. The second on the list was the SCM step. Check out. And again, not a single vote for very helpful. So obviously we've got lots of things that we can do to improve this. So make was that was that sort of addressing your question because I think you still got. Yeah that we've got stuff hanging over where I mean it's a resourcing project I guess and for open source. Yeah, and it's really documentation of their parameters. Great. And they're let's see over there. What do you call it their steps, parameters and return values. Yeah, and code examples, calling sequence. Oh right right. And they need examples. The most frequent request in the feedback on the documentation is give me examples of pipeline. And it's the same question that dirage was asking with regard to configuration is code right. How do I write a good example that will satisfy a significant portion of the users when I don't know what their arguments or the arguments are most important to them. Right. Right. So we'll aside what I don't know if we want to put this, the possibility of putting a check in for when changes are made to a plugin that has steps to at least ping them that there's nothing in your HTML directory or something. I suppose we can tell we can tell whether it's useful or not but we could, and we probably can't bust them now start busting them now let's not let them, but we can at least put out a warning that this is not does not seem to be documented. Oh right right okay that's, that's for instance we could automate a test that asserts plugin steps have documentation. Right. We could automate it that plugin steps have, have a symbol defined. Yeah, good. Okay. I mean, I think there may be a certain number of plugin developers who don't realize that they're supposed to do that. Right, right, I think you're correct. They would be willing if we would just tell them hey you know that you're missing documentation for this this and this. Right, and then tell them how to do it. It's not be instantly obvious okay. Great. And, and those comments are under she code Africa not pipeline steps improvements. Right, right I was just going to delete that. So I think I think because for me at least well which which makes more sense to you make do you want those moved up. Oh I don't know it's up to you. I don't know like that because I was just say, I'm just curious what we're doing to wind down she code Africa. We got a leg was quite insistent on slack last night that we should begin the, the winding down process yes so most of our Monday meeting went to that which is probably good like did it so. And so one more thing that you and I need to do so mentors will need to grade the, the participants. And it's basically pass fail to decide if we recommend that they should be paid the $500 stipend or not. Okay. And what I've got is mark has the action item to extract mark to extract summarize. Results to date for others and then invite comments from other mentors. The idea being that let's let's have just one of us do a legwork of reading through the documents deciding how far did they reach how many pull requests, etc. And then what about a summary of things. So you mentioned something about sending out a survey before the Monday meeting, we I think you were talking or the Friday meeting. And I wonder with the steam very I don't know that this group is going to be comfortable in a meeting to speak up and say, you could have done this better and you could have done that better. Oh, right and in fact the retrospective has already been sent. Right. Okay, good. And then these got issues that we can talk about we can say, you know, right and it's not. So let me see if I can find it really quickly here because retro retro. Because if I link to it then Jenkins. Looks like I'll have to look for it further. It's been sent by Oleg and oh actually, I take it back I know right where it is Meg. It's right at the bottom of this document. Oh yes, because that's where you took notes last night so it's all the way down here, here's the retrospective. And I've started filling in some comments from me Oleg put some from him, and we hope that the students will insert their comments as well. And that's what I'm wondering if an anonymous survey. To send out to the mentor to the to the she coders. I think some of them are going to be very uncomfortable saying negative things. Right, and, and I'm, I'm not sure how to how to resolve that because even an anonymous survey. We only have a sample size of five. It's, it's, it's not not going to be anonymous no matter what. Right and we can but we don't what I'm what I'm thinking you know is it would tell us if, you know, if all of them say something about the same thing we can talk about it at least you know. Right. It's just another it's another way to get feedback. It feels less intimidating than putting my name on a document or saying something in a meeting. Okay, yeah. I don't have a survey planned. I'm, for me, surveys are very difficult to create. If you are, if you think it would help. I'm, and you're willing to do it I would love to try the experiment in my case. I'm just going to go with the retro retrospective and then we'll ask questions in the meeting. And yeah, maybe they and maybe the good because I think I mean it would be the question is getting information from them about how we could have helped them better. And, you know, so if we put enough of the, you know, problems that we saw there, then we, you know, then they're, they can either agree with us that it was a problem or they have to disagree with us that no no that wasn't a problem so. Right. Yeah, and I like that because that way they they share with us well it wasn't a problem for me. And one of them may say oh but it was a problem for me. Yes. Right, right. Good. Good. Okay, we've, we've only got three minutes left. There was, I'd propose we just briefly touch the last two topics and call ourselves done. Sounds good to me. Okay, so the search report from the Jenkins plug in site looks like. Where is it. I just received it today. And that's why I was so so charmed by it. Nope, I don't see it now in my list I should have. Oh, nope, I don't have it. So, plug in search. Now. Oh, here we go. I'll go the usage. This is now this is from two weeks ago here I'll show it. So you can see so this highlights our total usage. Ah, here we go and this is what I wanted to see is open up the Algolia dashboard. So because we're using Algolia as this open source as an open as a their open source program. It lets us take a look at how things are going on people who are searching the plug inside. And so we can see oh hey we're down here. I've got to look at the. So we're. Yeah, so conversion rates not terribly helpful but there we go one hint at 10% no results so one in 10 queries to the plug in site generates no results and if we look at this. The top searches without results are right here TFS, check style, PMD and of those three, these two actually have plugins that implement them. But they're not named PMD or check style. So, so there's something we need to improve there in terms of our aliasing or our synonyms to say, okay check style should be a synonym for the warnings next generation plug in PMD should be a synonym for the next, the warnings next generation plug in. Great. Okay. Thank you very much to everyone much appreciated. I think that covers the topics that we had for today. Right, and you guys are ready to start work then you have everything you need to do what you need to do. Yeah, this is a darker. I do but I have a question. Is there a website or something where I should look at getting started for technical writers for Jenkins project to understand the tools used. Yes, yes, there is absolutely so let me, if it's okay with you Sudak, let's go to. And this will be available in the recording as well if you need to refer back to it. So the GitHub actually first thing is, when you see a page. The simplest way to find where that page is maintained is usually down at the bottom of the page. There is an improve this page hyperlink. Okay. And so if I click that improve this page hyperlink. It takes me into the GitHub repository for that page. So, so there's the first of seeing Oh, here's a page now how do I do it. Now, now the general how do I contribute. Here's this contributing dot a doc that gives you an outline of what it means to contribute what are the, you know, as a newcomer what do I need to do how do I communicate with people. What do I run, how do I, how do I build the site locally so that I can see how it looks, those kind of things. Okay. Are you familiar with ASCII. Yeah, yeah. Yeah, okay good. Yeah, I heard about it but I haven't used. I've done a little bit of markdown and stuff like that. So, yeah, yeah, it's you if you've done markdown this will be feel very comfortable. It's, yes, it's slightly different than markdown but it's it's just a markup language. Okay. Yeah. And since this Kubernetes thing is a and Jenkins are kind of a overview topic. Can I use you mark as the point of contact or should I still yes. Okay, thank you. Now, with with the caveat that you're, you're asking question of someone who is not an expert but I know a lot of people who are experts. So, so I apologize. Evangelist right so that's why I'm asking you. Right, right, so the source of information. Yeah, I've seen a couple of your videos so yeah. And also there is the Gitter channel. Right. Okay. All right, any other topics we need to discuss. I'm good. Okay, thanks everybody recording should be available in probably an hour, if it's not available in an hour it will be 12 or 14 hours before I post it, because it's time for me to get some sleep. Yeah, yeah, I agree. Yeah, thanks for staying out. Thanks everybody. See you next week. Good day. Bye.