 All right, welcome. It's Jenkins documentation office hours. It's the 3rd of May. And Kristen, thanks for joining us in the dark hours of your night. So agenda topics to propose. Why are pseudo car had sent me an email proposal of an outline for a possible project to work on Jenkins on Kubernetes basically taking the Google season of docs ideas and starting on them. And so I wanted to spend some time today talking about that, even if pseudo car is not here. Let's talk about it anyway, just to get your insights on where should the kind of this kinds of information be put, etc. Then I put a placeholder in for jcasc for dirage. She called Africa, I think Meg you and I should probably talk through and Kristen we should talk through what that was. Oh, I've got a, and I've got the retrospective scheduled a retrospective poll has been sent. Please respond. So that's for everybody to respond to right. The idea is we would really like a one final we've got some really great retrospective comments already and I'll like, well, we'll talk about that when we get to it. Contributors summit as well new next topic. Any other topics you'd like to be included. I'm good that should keep us busy. Okay. Yeah, I don't have much. So, so Kristen the one that I think is would be most powerful for us to discuss with you here is the Jenkins on Kubernetes topic. So one of the things that Sudakar suggested was, Hey, let's include some additional Kubernetes concepts in the installing Jenkins on Kubernetes. Let's add our intro to the helm charts. And then the big one was used to plug in installation manager. And this is updating plugins with plugin installation manager. And managing plugin updates as code. Right poll requests, etc. That's reasonable to you. I, I, I love plugin installation manager I know we're using it in Jenkins info now. Any reason not to put this into standard documentation. Oh no, especially if it gets more easily using it and kind of make sure that's up to date. People have questions about it so that would be a good decision. Okay so and in terms of looking at where it might go. The placement of things is oftentimes a puzzle for me so we've today we've got installing Jenkins and the Kubernetes page and it's got helm. YAML Jenkins operator. Would we envision it. Oh go ahead. Oh sorry sorry like it would this be more general or would it be like very hyper focused to that that's what I'm wondering is should plug in installation manager be outside of installing because it applies both to and to Docker. So maybe it's it's in managing or in system administration. I'm open to. I'm not clear on which of those but it feels like maybe it should be a whole separate dedicated chapter on plugin installation manager. Right which it could be referenced from here. Yeah, but now what about here. Oh go ahead. No, no, I was going to change the subject so okay because I was like, yeah because then we could reference to it to it from like each of these different things because each of these different installations of Jenkins probably the only thing that's very specific is going to be like the plug in directory location, and then we can make sure that that's, I mean that's like always the Jenkins home, but maybe some examples or like screenshots of where everything is located can be done specifically but I think it's generic enough that it may be underneath managing Jenkins. Okay, so let's, well and managing Jenkins has things about agents. Yeah, and about scripting and about users so it seems. Now what the sys admin is more about sort of the hardware you're on. Yeah, so, so for me, it feels like managing Jenkins is a good home for it. Okay, good so I'm going to put, I'm going to put a proposal into the notes then with the idea that as a chapter under managing Jenkins. It actually has a section on managing plugins. Managing Jenkins. Oh yes it does right okay so it can. Well so. We need that but then, you know, is the next one and then we can say now there's a cooler way you can do this or. Well, or is it just a part of this or is it just a part of that yeah. Yeah, we get excited by a new feature and want to go out and write a separate book about it but. But the reality is yeah so it's, I think you're right so extend the managing plugins page. Okay, that one that one feels really good, because now conceptually we've got installing a plugin updating a plug in removing a plug in pin plugins and then a new section plugin installation manager. Okay, now in Jenkins, can they manage plugins through cats your jcask also. They cannot. Well, well they joined us perfect timing. Hello dirage, they can manage them through it but what they do is. Well, they can but I guess I would call it an anti pattern it's using jcask to do the in the copy of plugins gives you a very brittle installation you want to have them already inside your Docker image. Before jcask get started. Okay, so I would think it would be nice if that section made a mention it shouldn't I mean the jcask documentation we separate, but just because if you're doing this stuff you're going to hear about that and just the question so you can do and just what you said. And I loved I just I don't have to talk to you about the word brittle. I just got things on it. I'm so happy to hear you use it. Right. Okay, good so then, then, then. We've got installing Jenkins on Kubernetes agreed using plugin installation manager into the plug it managing plugins page. Now then his next proposal was using configuration as code. And now we're back to. I would love to have configuration is code. Where do we put it does it belong in system administration. Because of its, its ability to configure things all the way up. So is it closer to reverse proxy config and monitoring and backup and restore, or is it closer to tool management plugin management and time zones. I think it's very similar for the system administration one, because I think it's very similar. I think it could kind of be very similar to backup of school. On the previous page there was a I saw configuring the system over on the left. Yeah, there's that empty. Ah, lovely. But but this could this could conceivably be a place where we put configuration as code as the first entry on this page. And Kristen your your sense was, because it's it's closer to a backup and restore concept. Yeah, that's kind of where it's like maybe I think it's really close to that. That kind of concept in general unfortunately there's not something there. Well, but to me it's a, it's the entire systems configuration, and it's almost like creating a backup, but in a code way, rather than. Well, and and okay to further support your, your, we've got sections for chef and puppet incomplete but we've got them there. Those are similarly, how you get the system configured. So I think this makes sense to me let's call it for system system admin. Meg are you okay with that. I'm yeah. All of this stuff is circular and it needs just references you know. The beast. Right exactly insert as an as a new. New page new section or no new page in system administration. Okay, all right. Okay, and then then the final topic was the Kubernetes solutions page and the solutions pages are here. And this is a case we don't even have a Kubernetes solution page yet so we've got Java we've got Python but nothing for that. So, this has been one. Absolutely it's, it just goes in there. The content that he was suggesting included helm chart use cases and this one. I was curious. You and I have had discussions in the past about how do we describe all the ways we use agents and this is a sort of a classic example of it okay ephemeral agents in the same cluster. ephemeral agents, borrowing capacity from a different cluster, or static agents outside the cluster as in, let's see, somebody's Raspberry Pi or an Android phone or an iPhone or a Mac. Or free BSD. I mean they're all sorts of use cases where you need static agents outside a cluster are those are any of those things that we'd say oh no we should actually embed those into some other part of the documentation something. Would I ever want static agents inside the cluster. Well, Kristen, can you have static agents inside a cluster I guess you can. I just don't know why you would because the Kubernetes elasticity is the thing. I guess. Okay, what we all know that I know just enough about anything to be real dangerous. But they're oh shoot, what is the name of that feature. There is the feature where you can make your force your whole pipeline to run on the same agent. You mean the reuse reuse node. Sequential stages. Okay. And that would be. I don't completely understand any of it so I'm just looking at dots that look like maybe they connect. Maybe the answer maybe shut up Meg. That's a good answer Kristen often. I'm sitting here and like, maybe back into a lot more back into Jenkins because I don't really know. Yeah, and so, so make I guess my question was, okay, we've got, we've got a page page now on managing nodes or managing agents. What we don't have though is any concept of ephemeral agents and static agents that's been presented in the documentation. And that was one that that that lack of that conceptual gap right now seems like a great thing to put inside managing nodes. But then the question is okay. Is that in managing nodes or in managing nodes, and the same for the agents static agents as well for me I think that really belongs in the managing nodes thing. Probably yeah. Also, is there something about shared versus dedicated nodes. And, and that concept is unique to to cloud these solutions. So that's not on the that's that won't be on the Jenkins, the Jenkins site. Oh, okay. Okay. A good question. Thanks for asking. Oh yeah that's yeah that's right without yeah okay. All right, so well so back to where we were then so any any other insights to offer on the Jenkins on Kubernetes outline. For me that's sufficient I think we're ready to talk about Jenkins configuration as code with the Raj. Yeah, I have one quick question I don't know we need to go into it. But something that I see is it might be nice to end that section with a tour of managing Jenkins that just has notes. And these tasks you know do, you know, this is going to be like backup I'm thinking is going to be quite different on Kubernetes. Then it would be on a traditional you know, and we don't we don't necessarily want to rewrite that. But say, you know, or unless it's something that it's just totally different don't ever do this the way it is and if you're in Kubernetes you got to do it completely. So just like as a high level overview like these are the specific gotchas or. Right, sort of the above I, I, I like a little avuncular piece don't rewrite everything assume that I know it or I can click to it, but say it's just like that except for this. Or you can also do this or be sure you use this directory of your own, you know or whatever. Yeah, just because they're all pretty close but there's a couple little gotchas family all over the place. And then I'll shut up we go on to jcask. Good. All right. Okay, that's, yeah. Okay, good. Due to Kubernetes. So dear, thanks for joining us. I want to put the topic on the list of plug in jcask plug in documentation on the theory that you might join us and want to have asked some questions or share with us what you've learned etc. Did you want to take some time today. Hello. Hello. Okay, thank you. So, yes, last time when we discussed so you told me with the help of a demo that how we can extract it, the configuration from the UI so that was very helpful. And so last time I pointed out that we need to have a developer documentation. So that is one thing that we can discuss about right now. Other than that, I don't think there's anything specific because that was the main concern like having a developer documentation for jcask would be a really great thing for new contributors. And so specifically when you're when you're describing developer documentation for jcask this is things like how to make my plug in able to use jcask is that the kind of thing that you're you're envisioning there. Just further on the kinds of things you'd see in developer documentation would it be, I want to add some new feature to jcask or is it rather I want my plug in to support jcask. First of all, how to use jcask with my Jenkins instance. And how do my plug in uses jcask or that would be good thing as well. And then, how can I contribute to jcask. That would be third thing for interested people who want to contribute. And I think these are major things like I can think as of now. Okay, and so that that first one using configuration using configuration as code seems like a good one that we cover it we would like to cover in the Jenkins on Kubernetes work so yeah agreed so see Jenkins on Kubernetes project so that's a good one. That's focused focused on on users so at least is that did I understand your curriculum you said using jcask in my instance that's me as a Jenkins administrator how can I best use configuration as code to help my life be better and easier. Yes, exactly. Okay. And then. And so this is focused on administrators on Jenkins administrators. And then adapting my plug into support jcask that's focused on plug in plug in maintainers. Okay, and then contributing to jcask development focused on jcask maintainers. Good. Okay, and, and now I was, I thought we had at least the contributing to jcask. Yeah, now I haven't done the, the details to prove that it's there but I thought that we had in docs here contributing that would tell people okay this is how you can help with how you can run it configure it in your ID. Okay, so, and then is there more in the docs directory. Oh yes plugins. And this was, and, and again this is there could be all sorts of interesting challenges here. Okay, so they plug into. And I know we don't have anything on using jcask in a Jenkins instance at least not in the Jenkins.io documentation set. Good. All right. I also have a desire for a reference page for especially Jenkins or especially the YAML file that what Jenkins.yaml file. Oh, oh you you and you do understand that you'll go ahead Kristen. Oh, no, that would be great. Oh, you were I love that optimism I was thinking you must come more often I like this to against one. Oh yeah sure let's do reference. See, my challenge with that one is what you just described Meg is this page. Well no it's this page I'm going to show you the page that it mirrors. Let's see it is. What you just described is this page. Yeah. And for configuration is called right because isn't each plugin can contribute each plugin can contribute YAML snippets to the configuration. That's right. And therefore, it would mean the same systematic thing of, Oh, here are here are the YAML fragment references for for all the plugins that have support and I think it's doable right Kristen Kristen's proven it when she wrote this tool originally that you certainly can iterate over all the plugins and extract based on their class structure, extract documentation from them. Yeah, because well the problem that I've seen in my limited exposure to tasks and jcasket is that we don't have complete documentation about the configuration either, whatever we have about the configuration isn't the GUI. And it says you know, are you having a nice day today somewhere in the background that is translated to something called Hudson dot curious dot nosy about your status. I don't know what the valid values. I mean we kind of we all relied it was all in the background that the UI would keep you from doing something really stupid and dead. And, and it's just, you know, the first time somebody demonstrated this to me, they went through all the screens on the configuration that I'd seen 100 times and all the time, and then they opened up this file. Now granted a certain amount of it I can figure out but I don't know what is, you know, what are legitimate values, what will the system prevent me from putting in as a bad value, etc. And I think what you're what you're describing is the reality that we we we rely very nicely on view configuration to tell me this the setup of my current configuration to give me a valid configuration so it in fact knows this is how I define a JDK installation and it looks like that and I can copy and paste that right into my configuration file. But for me that's, that's similar to the pipeline syntax snippet generator. Go ahead, Kristen. Yeah, I would agree. I was kind of the most the same. I love this page. Maybe being able to see this. Yeah, maybe it's, yeah, maybe that needs to be documented. I hadn't seen that before. But, but still are are they all. I don't know if all the values in there are just obvious as to what the value should be. Not right. The trick there is, if I want to do something I have to configure Jenkins and then export it so if I say ooh I want, I want to X, I want to change my JDK configuration I are here. Let's, let's do the, the one that is very familiar to me. We're going to change the git configuration. I'm going to click here and I make changes. Okay, I mean it's now going to be get to is the program that, and that will now be saved. The next when I click save here that thing will then appear as a change and I can go grab it out of the out of that save file. But, but you've got a good point that we don't have we don't have a YAML based configuration as code equivalent to the pipeline steps reference. Yeah. And with that in, we can make a task, but you know just make a doc ticket for it. Right. Look at that as well even to know. I think there are still things that you can configure on the UI that is do not that Jcast does not handle right. Correct, like all the plugin. I was just talking about right, just to know that that is a whole situation that you need to do separately new better ways or hopefully coming. And I suspect that users for the plugins that are in the suggested use that users may not always think about those as plugins that are separate from Jenkins itself. Some of those real basic ones. Yeah. Always there. Okay. But I don't know. I'm just, I spent too many years writing Unix for man pages so. But you didn't put a file in the system without a man page that documented every field on it. Right. Exactly. Anything else on on Jake any other Jcast plugin documentation topics. How is it going dear. Is it fun. Is it interesting. Yes, everything is very interesting. All right, then next topic proposal was she code Africa contribute on. So make anything you want to share there I've certainly got a topic or two around retrospective. I'd like to hear that yeah I was I think it was a great project I hope we do it again. I'm going to drag in the notes because we've got some notes, actually it may be worth here just getting some gathering some more discussion on because we've got you and me and Kristen here. Yes, maybe let's talk retrospective one more time. Kristen you were you were in the Friday session though weren't you. Yeah, yeah so we've well but here here again here's a chance for us to look one more time so we what we did during the Friday session we asked each of the. Those attending so on yinye Esther and Cynthia each of the three attended and we asked them specific questions. Hey what could we do to reduce technical problems. What could we. What could where their hardware issues that are equipment issues that have caused your problem. What did you learn from other documentation that you would have liked to have known in advance. Next, those kind of things. Do we have this is a nice list do we have like a list of I don't know top the top five things that if we did this again, we would change. No, that's what the retrospective will do right so we've got a proposal to do a retrospective, and, and this was just trying to gather data for it. Okay, started a section here in this document on retrospective. So, here it was okay. Everybody give your comments what went well. And what were the problems you encountered as a contributor as a mentor. And what should we do differently, right what should we improve great. Now I'm, I'm happy to add more text here if, if Meg if you would like to give comments or Kristen, you're welcome to do them here. I can type for you. I think I only put one comment and I think it was a question. Oh good okay so but you have seen this section and right I would I thought I mean you everything else that everybody else had said was good. My frankly I'm not going to put it in writing but I think the first session, the second Monday meeting was worth less thanks to me, but Okay. Oh, do we have on this maybe what we could turn that in that we, we need to do it. We did not just throw them in the middle of the lake and see if they can swim that we ought to start out with have the have them do the classes, a couple of classes or maybe we present. Yeah, and I think that was self paced training course links was here. Yes. Yes. So, so that's a good one. Absolutely. And then for us now. I mean we could have, should we have at the beginning started out and said okay your fruit, we should have sent benchmarks to or milestones that sort of we expect this to have so. So we weren't there in the second week. On India had submitted 20 PRs and a couple of the others were still reading the documentation that they have some way to pace, and that we have a point to know. Okay, you're in trouble here. But then she would say so this week, and then maybe you go through and demo it, the steps that they have to do so they get to watch it record it and they've got that. And I don't think that comment came in. That's a good one to add here. It was sort of talking about in the ad should just, I mean, and there's two ways one of it is that maybe we want to learn to learn that an open source you get some rough instructions and you go out and you figure it out. And, you know, and call for help if you do if it doesn't work. But, but they're young. This is all new. You know, I think most of them were new to dev ops and to Jenkins a bunch of new Java there was so much stuff. It would have helped if they'd seen, you know, this is what you're going to do first and then we would have had, and the big one that we should have hit then is when they got to the point of adding new information is how do you research this. And now tell me more about that one so guidance on how to how to research a, a topic is that what you're saying how to what is what is this argument to this step main. And I think I think some of the best stuff came from Googling and finding stuff on stack overflow. So, should we make sure that the plugin developers themselves, the, for the plugins that we've selected are on board. Yes, they, that would be sort of the number one they should be able to just say, oh, you know what is this supposed to be and what kind of a string or whatever. Yeah, and that comment we had, we had an advance but or we've had that one other time but good to have it. So they can, they can ask they should review the code and see what they can figure out from the code. I get the feeling that people don't very often add comments that are useful right. And as a writer I love admitted or developers who put copious comments in their code but they're few and far between. Look at the code look for comments talk to the pipeline owner or maintainer or the plugin maintainer and Google out there and see what you find in other blogs and stack flow and stuff. And our post to get her, I don't know what priority what we want them all to do but, but I think you know they all hit that wall and it's like, okay, I'm ready to do this. Right. Good. Okay. Kristen you've been set up what do you what do you think was where do we have the more social to work more on building a team out of this group to. We at least had our suggestion from Cynthia to do ice breakers to do introductory segments to get to know each other. Right. I mean, another thing that I wonder is if we should give them. Like the first week is getting set up and getting everything maybe we should have a second week where they work in pairs. I don't know if they would like that. That I mean some some of these plugins like a lot of these are big enough that the two of them could work on it together if they would like, would they like that I don't know. Yeah, I think maybe so so actually this is kind of. So, these were mostly like college students. Okay, because like that could also help target it to, because I think we may have treated them a little bit more like older, like maybe even more of a professional status like more of a student status. And I mean, I mean that move from the idea of like, okay, go out and discover versus very much a like, hey, like let's get on board. Absolutely. Or like, or like a little bit more of a hand holding onboarding process, because I did, I like me personally being the mentor. I think I, you know, it's hard to remember sometimes how it's like to join open to join communities and speak or talk on channels. It's really intimidating at first. It is. It's very, very intimidating, especially if you are coming in as you know a student you're like, oh my gosh these people have so much so much more experience like what if I come in and say something that, you know, may not be right. I'm embarrassed. It's just, I mean, we don't get you know we're all like yeah like come on in and join and talk, but it just having that reinforcement. I think it's a little bit more personal encouragement might encourage personal encouragement might allow them to speak earlier in the process and I feel like in the second week. I kind of was, you know, hey, no one's really saying anything. I don't know what's going on. Yeah, I feel like about the second week that almost everybody was in trouble. Yeah, everybody was scared to say anything right and then in the third week you guys started having man mentoring sessions. And then that was all those then and then things. I wish it had been two months actually. I agree. I agree, Meg, that was a bit of, it felt like we're just starting to get going. And it's just like, oh, so you have those sessions a little bit earlier and also just kind of maybe also that will help with the perspective of not really knowing where they are because it would take a long time to even send me the documents for awesome work that you set up like they were so great. But it would help maybe have them communicate where they are. Kind of as a check in basis, maybe that's something to show them like at the end of your day. Like every day every two days because I don't want to like do a check in the most kind of where are you working on. Do you have any. You know, it's almost like an agile status. Right. I don't know if that wants to encourage like certain people that they think they need to deliver something every day but as more of just a gentle favor in the channel. What are you working on if we notice someone is working on something for a long time like just reach out to them individually and ask if they have a question. Maybe that would help. It is such a short period. And maybe it just needed to happen. Maybe we need to ask for free. Maybe rather than blanket statement. Hey, any reviews. It's just more of a what are you working on right now. Like is everything I can help with. And that would help. Does he have is there any possibility of doing these things for two months. The duration is absolutely a choice that they're making. They chose 30 days for this one intentionally because they wanted to avoid collision with Google Summer of Code. And they were very wise to do that because if they told me we want to do two months. I'd have had to say I'm sorry I cannot give you the month of May, because I will that's I begin we begin the mentoring for Google Summer of Code mid May. Right. So, so they, they intentionally chose the month of April to avoid a collision with Google Summer of Code. Maybe next year, they could start in March. Right, right. Yeah, absolutely. Yeah, so maybe we can. That's a good way to get it in right is like, hey, please. We could have, we could have and should have done some things to get them going a little bit sooner, but you know, I think they were all just getting to the point where they were comfortable enough with what they were doing that they could have had some real fun with the project. It's like a new job there's those first things that you do and everybody else is oh this looks great and you're like I have no idea what I'm doing. And then there's that point where it starts to make sense. Right. And I feel like we cut them off right at that point. And that just the nature the learning curve that maybe two months would be a better. So we really we had that good third week and then the fourth week we're starting to do retrospectives and wind down. So we really ended up with only kind of one week. We might. We did things differently we might have gotten two weeks out of that but that's still not a lot. So, okay, Chris, I wanted to go back to your, I'm kept putting words in your mouth and I apologize for doing that but it's specific activities to encourage questions increase participation and break barriers. What if we asked each participant to show something at every mentoring session, you must show me a screenshot of something or share your screen to show how you're doing this as a way to encourage them to interact with us but even then that may be too difficult, they won't interact and they just show it and say they're done. And we ran into the hardware I did on that. That disaster second meeting. I was, I tried to have a couple of the ones show where they were and they couldn't show they couldn't show their screen their internet kept blowing out. Okay, all right. And then luckily, because I, I had stuff I could have showed what it what I will be talking about any of her what it was, I could have done it but I really wanted one. On yinye jumped in and she did it and did a brilliant job of it. But I had a, I also had a feeling the others rapidly started to get scared of on because they were, I think they had a little bit of a notion that they were competing with each other and you know, Oh, oh no, was such as I mean she was such a rock star out the gate. And then about, you know, a little bit later Cynthia was catching up to her. But, but yeah, there's back to the, is there anything we can do, you know, well we can't do anything about their internet I'm sure whether we can get the better hardware. Not, not, not effectively right telling telling she code Africa hey in addition to the 500 that you're giving them for this one month of work. You also need to provide them equipment that they, I don't think there's any way it would work. Right there's, there's just not going to be able to do it. They pre qualify them to assure they have adequate equipment. And in this case, the adequate equipment worked okay but adequate internet is, you know, hey it's spotty internet it's it's the internet. Yeah. And so make back to the back to the show something if we had. If we had show a screenshot from each participant. That could be done by the mentor without putting a demand on the participants internet bandwidth right if we just go into their participant document say hey. Cynthia here's what we see as your most recent screenshot tell us about that. Right. That's a good idea. Yeah, I was going to say they could post them to slack just before the meeting but that's better. It's in the dock. Just anything to kind of encourage a little bit of, or if you're stuck and can't make progress maybe before the meet you know before the meeting to start asking some questions. Right. Right. And the idea is let's motivate let's encourage that hey we were all going to encounter problems and everybody's we're going to have many of the problems will be different unique to you and we talk. Okay, I will and I wonder if that. Maybe we do it two steps we take Cynthia's idea and icebreaker. I'm Cynthia here's a little bit about me and here's my screenshot and the problems I had. And then we go to the next one hi I'm so and so, and here's my thing. We could do a mix of them where we say, combine one and the other. Maybe that will also help them feel less like they're competing with each other as well. That's a really good point. Right. I really wanted to feel like we wanted them to help each other or like you feel like they could help each other a little bit more, but it's harder when it was, there was not as much chatter. Right. Yeah. Okay. I wonder, actually, they like slack so well. It's hokey and I don't do it but I wonder if we had something like the honey pot in in slack for them to thank each other when they helped each other if that would. Anything. Yeah, that's. And as I'm too old and jaded I don't get excited about it every once in a while I feel guilty and go out and give some people some thanks for it. Yeah, and I'm not sure if the honey pot app is installed on the CDF slack it's a, I don't don't know enough about it to the yes. I think the honey pot like the honey pot honey pot is very like a cloudy thing but I mean there's nothing that says there's not a thanks for some. Oh okay so that is that is not a general that's not a general. Yeah, there's like there was something else that we were using and and there was a problem with there's something so we went out and did our own. But there was a generic one. And it would, but even just, you know, even a separate channel for thanks, you know would just something. Good. Okay, very good idea. Excellent. All right. All of the sums together. I know one of the things I think that we fell down on is we didn't have enough peer to peer activity. Right. Yeah, it was it was mentor to mentoring and back and forth. Well and and that one echoes with on Union and Cynthia both commenting. Hey they wanted to talk with a broader set of people in the Jenkins community now, had we pre registered or pre subscribed plugin maintainers we might have already achieved that one so that that one may be achieved just by. Okay if we're going to if we're going to invite you to work on a plug in we need to be sure that the maintainers agreed to assist us during this one month. Right. Yeah, and I confess the reason I didn't bother to subscribe the plugin maintainers was I falsely assumed that hey this is just documentation they'll of course accept it and immediately merge it. I was just wrong. That that that was not at all. And even if they did that's from the writer standpoint, we didn't have the research support. And that's what we really, because I mean let's face it you and Oleg and actually could look at most these PRs and make a reasonably good guess as to whether or not you're okay to merge. Right. But if they wanted to know what this argument match, and it wasn't written any place you were kind of hope you didn't have that background. Yeah. Okay. Yeah, I kind of like that I, the only like positive I guess about how I felt like it was taking a long time is that you know it's maybe just kind of showing that open source does take a little while. But yeah, it's not a great experience for a month long project. Okay, we had thought that they would we were thinking they would post together to with questions. And I think that would just scared them too much. They were a little bit scared asking us questions until almost the end. Well, and I think that's acknowledging that the slack channel did work better. And even there there were some flaws right we had one of the one of the participants that didn't actually get subscribed to the channel until two days before the project ended. Right. And so yeah, oops, that's a that's an easy checklist item to be sure everybody at the start post something to the communication channel to confirm that we know they know how to talk to us. Right. Okay. Any any other insights to share on the retrospective. All right, well, thanks. Excellent feedback. Let's see, let's put a hyperlink to the well, lots of things there that need to be digested summarized, etc. Yeah, are we going to get feedback. Because I have a hunch that they're that there are feelings out there that these people are still aren't telling us that they might tell her about things that they don't go well. And I'm sure that that they I am confident that she code Africa will tell us what the comments were from the participants. Absolutely. There's no question there. I think they're still processing it. And I'm not not confident we'll have it before the retrospective happens. Okay, let me find the link to the poll just actually each of you, Kristen and Meg you should have received the email that invited you to respond to the poll. We did I saw it just a few little while ago. Okay, good. All right. Okay, anything she code Africa contribute on I need a blog post I got to remove it from the jambotron. And I've got the idea to propose a talk for DevOps world. Yes, and you've even got some of our people are going to join you. Right. Awesome. Next topic was contributor summit. So June 25 be sure you're registered for contributor summit. Yes, this is the page you go to yes you kick that click the big red button register here. The proposed coordination Google doc is right here and it's got a segment in it for the documentation track. All right. And so I had put into this. Google season of docs now it'll have to be. Yeah, it's got Jenkins and Kubernetes. We've already talked about that here on boarding improvements and content improvements were topics I had if you've got other topics you'd like. I'll propose them as suggestions this document. Okay. And I think that's, that's about it any other topics we want to discuss before we call it a end of the session. All right, I'll post the, the recording after this, after the processing is sitting is complete. Thanks everybody. Thanks. Take care. Thanks.