 All right, welcome to the documentation track of the Jenkins contributor summit east version. Thanks for being here so here's some the the intent of this track is to help us identify things that should be on the Jenkins documentation roadmap for the next 12 months. And, and things on the documentation roadmap should advance the state of the documentation help improve it. I've got some ideas here but before I go through my list of ideas, Zina or Christian Kristen were there any ideas that you wanted to add to the list so we can be sure that they're the top of the list. How about Google season of dogs. I can see some of good. Okay. Okay, good. Also, I wonder if we ought to put Google summer of code projects, because oddly enough, there is one project ideas and we should discuss that. I don't know if it will be selected by a student or not but there's one unrest API documentation generation. Exactly. I was thinking about that. I didn't know if we wanted to. If that was all covered in the Google summer of code track or if we want to talk about it here. And since there isn't a Google summer of code track. Okay, this is a great place to cover the Google summer code is sort of running on its own so that's a good. Okay, cool. Good, good one. All right, any others that come to mind before I start walking through the list. Do we have any kind of any other convert like wiki migration stuff that we need to do we do it's it's a little later in the list so the wiki migration plan is in there. Oh, and I've already got she code Africa project ideas let's just put that up at the top so we discuss it. All right, cool. Good. Okay, very good. So, so yeah we have wiki migration plan documentation roadmap for me is sort of a that's what we're all about here but documentation inventory was one we discussed, and I've made no progress on but I think it's worth discussing. We don't really need pull request process and progress because that is more for our office hours than for this this track. So that looks like it's already quite a list. Anything that you think we should add to that list. Okay, then how nothing for me. Okay, great. So then I think in terms of sorting things so that we assure we get highest priority ones done first, I'm going to put site search the docs down below just because we'll review that one in the West Coast version in about four and a half hours. This is urgent that we review it here. All right, so let's, let's talk about first topic would be, I think we should put on our roadmap that we should be involved Jenkins project involved with she code Africa. It's a great mix of Zenob's interests and our desire to bring more contributors. And if we if we put that as one of our one of our topics saying hey, we would like to be involved with she code Africa. That feels like a good thing, and then we need project ideas. I think that we had in the last session we're around updating the screenshots, because Jenkins 2.277 changes many of the screens. And it would be a good excuse to visit that and work through screenshot read retake a pipeline examples are frequently requested. I don't know what your experiences with these contributors do they do they likely have any experience with Jenkins prior to coming to she code Africa. I assume not. So I, I can't really say. But I know we have ladies in cloud track and devil we have a DevOps channel, but I'm not really sure of the tools but I think we should have ladies that have some experience with Jenkins but I can't really say for sure I'll have to find out. But I can put that on my to do list to find out if we have ladies that have any power experience with Jenkins or not so we can know what projects ideas would be more suitable. Great, very good. But I think the screenshot is a great idea. Well, for me, this one, the screenshots would could be done, even by somebody not yet terribly experienced, if they're willing to go a little bit through the process of, Hey, here are the instructions that got me there. Okay. And they may say, Oh, I need to update the documentation because they didn't get me to that screenshot. Exactly. Okay. So this second this last one document examples in plugins is really sort of the same as. Yeah, see I'm not sure that I think those things are the same it's really in order to create an example. Whoops. Examples are are probably are well maybe well suited to going into the plugin source code. That's complicated that really is closer to development task where we'd probably need to do some tutoring. This is how it's done. Okay. I know I'm open to others. Oh, go ahead, you know. So this requires someone with like advanced, like an advanced Jenkins user or probably someone if the person just has probably like basic knowledge of Jenkins a person can probably go through like knowledge sharing sessions come up to speed, or the to be someone who is well vast Jenkins who is like no Jenkins very well to be able to do this second project idea. Yeah, so the second one here is is probably more advanced than the first idea significantly more advanced. The first I think I can see how it could be done. The second one, at least for me, I needed a job the ability to compile something with Java, and then run it in order to see the results of what I was creating. And so, so that's relatively more advanced whereas updating the screenshots. So that's probably just a matter of us teaching them how do you create a Jenkins dot io development environment and update your pictures update the screenshot. They may even be able to do it without without being able to do a Jenkins dot io development environment, and then they just have to look at the images side by side. The good thing about this bootcamp is that it's not just for ladies within she could Africa is for all ladies across Africa so anyone can apply whether you're part of she could Africa community, or not so I think it's be a good idea to put out you can put our modern one project idea so it would be a good idea to just put everything out there. So select if we are able to get experienced applicants during the application process then good enough to be able to work on it then if not, we could settle for less complex project ideas. Great alright so during. So you can assess that during March, because you're in this the plan is to run the run the projects during the month of April right. Yeah, so in March that's when we're going to be selecting the applicant so um, once we're able to agree on the project ideas, I'll share a Google form with you to fill with the project idea so that's what we're going to use in selecting the participant that are going to participate in this bootcamp. So since it's not just for ladies within she could Africa community hopefully we'll be able to get ladies. I think I even I know ladies who are experienced who would like to participate in something like this, and I think they'll be able to work on something like this so I think we're good. Great. Okay, now Kristen are there as you think about that are there other places where you could envision things where we might say, Oh, this might be a good project idea. I would suspect site search is probably beyond the beyond the capacity of this project. It would require deep deep knowledge, but I'm open to other suggestions. I don't think that search is complicated. Oh, okay. It might be. Well, I did a prototype with this elastic web search it was something like two hours of work. I'm just not sure it really fits the program. Okay, my good point. Okay, so well and so that's that's a that's a good one here. Let's include that. At least we keep it in the notes. Yeah. And sorry, another thing I wanted to mention so we don't because I know this is documentation trap meeting so most likely we're going to be talking a lot about documentation for we could also have project ideas that don't have to do with documentation ideas. And, you know, other areas of thinking security, other areas doesn't have to be just documentation. Right, good, good point and there are certainly plenty of places coding activities test automation interactive testing, all sorts of things like that. There are plenty. Yes. Yeah, that's what I was wondering is like is there anything like small or like that is like maybe not entirely related to documentation that might be useful here like that just like a something that has to be self contained enough like even stuff where they get plug in Mark I know you're really involved in that, but like that could be helpful here as well. If you have people who are experienced, who have some experience with Java, Zenab, then, then I've got a very narrow one, some tests that exist today are written for J unit three and they need to be converted to J unit four. And this project has been ongoing for 12 months or more with progress only as students in Google Summer of Code volunteer. So we're making some new progress now but there's a lot yet to be done so this one might be a possible there others like it where, Oh, learn something about test frameworks learn something about writing and running automated tests, and, and be available. Have some casual mentoring for me in the process. Okay. All right. I mean that sounds like a great project personally because then you get experience with writing tests, like good document working with the community has like that sounds like a great project. Sorry. Another thing I wanted to ask is like how many people with Jenkins be able to mentor because it's probably is possible if we have the mentors, it's possible to have different individuals working on different things. See, for instance, someone working on the screenshot, someone else working on the test transformation. As long as there are available mentors to monitor your progress and they work. Right. And I think, I think it's a good question that I don't yet know the answer but I think it's worth asking the question and starting it. The docs piece. I think I could see the docs office hours easily covering that part part of part of mentoring right we could mentor once a week in docs office hours with that. And, and quite comfortably, the get client plug in test rework, I could probably cover but other additional areas, we'd need to bring it to, to a larger group and promote and invite others to help. Okay. Now, and this is only a four week, four week event right so it's just the month. Yes. And that has the additional benefit that it does not collide with Google summer of code. Exactly portion of Google summer of code. Yeah, that was those were things we had to consider when she's in the time frame, and that's why it was shot, because we didn't want it to collide with all the other open source programs. Great. So anything else on she code Africa project ideas before we go to the next. No, so be it. Okay, hotspot for me and Zina view are sort of sort of our classic example of this contributor onboarding for documentation is harder than it should be. And, and we need, we've got several challenges right one is developing on windows. It's not as easy as it should be. And Zina in your case you switch to a Linux virtual machine on your windows computer computer. I know like successfully done windows based development but he's using WSL remember right. I'm sorry say that again Oh, like I didn't catch so you can use me one as well. Oh, okay. Because I know it's possible but I was having issues with permissions when I tried using the BS or one and I wasn't able to resolve it. So because of time that was what I had to switch to the linux VM. I think it would be a good idea if we could probably have like maybe documentation or articles or things that could explain all these available processes for people that would like to contribute. If you like to use EVM, if you like to use WSL1, WSL2, because I know some pieces are not compatible with WSL2. Mine is not. That's why I had to go for one. So. Well, and this feels like a very good onboarding project, right, if we just document the steps so that someone who is brand new can be successful at getting started creating documentation. That's a good project in and of itself. Yes. Now, in addition to that, there's, we have pages, we have pages that include the improve this page link. Those are, I think we occasionally do receive contributions through those so for example, if we go into the Jenkins pipeline and we look at this page, we'll see at the bottom of the page improve this page, and it takes us to a page where I can actually edit. I'm wondering if we could improve the likelihood of people seeing that by either moving it elsewhere or, you know, encouraging them by putting it at the top or by embedding it in some paragraphs something like that. The improve this page for the pages where it works is quite helpful. And would allow oops and would have wrong tracks there we go would allow contributors. But I'm a little worried that it's not directly accessible it's not immediately visible. I've talked about this page link the thing before, and any way to improve or to highlight that as a way to get people to see it and maybe even know that it is there something they could work on would be beneficial. So, I guess I don't know like how. Yeah, that was any way to highlight that. Great. And so, so, so it sounds like no disagreement there that's open open topic. There's an additional challenge here which is many of the pages on Jenkins that I are actually generated pages so they don't have an improve this page. And I'm not sure that they fundamentally can so sort of one example is the pipeline steps reference. I look here. This this reference page itself I think does not have oh it hasn't improved this page, but I suspect it will take me to a place that may not be as. Oh it takes me to the actual page that's good but this is the page generator right this is the program that generates that page. Exactly I was like that's not going to be as helpful. When I get into this page. I think it's correctly has not included does not include an improve this page, but it also gives the user no way to go anywhere to help with this page. It's, it's, they can look at the plug in, but the actual documentation is. Well, this page if I remember correct Kristen is extracted from multiple things because this help is one section of help but then each of the arguments is its own help file if I remember correctly so so this page is actually a composition of many different pages or many different files. Yes. You could capture source for some locations, but I'm not sure how it would be from the user standpoint. Yeah, I mean, for a user who says oh there's a misspelling or there's an error or just something just wrong in this text. I don't, I would assume they'll they'll want oh where do I go to, I want to help with that where do I go to help with it and the answer is deep inside the get plug in source code to a file that contains the word URL in its name and, and it's, it's a long ways in. Well, if you can adjust to the hyperlink there, which opens this file in edit mode on GitHub. So we would have to put the links to where we get the help documents from. Is that your saying like, so, yeah, if you do that, it will be quite handy for users. Okay, I do not say that it's trivial to go. Oh my. But yeah, I think that's, you're right that would be the best place to go. And then also maybe that would encourage people to fill out additional help. Because I think like Mark and you were you saw someone had tried, he was asking to quote unquote like simply update something. This would enable them to be able to go and do it themselves. Because it's not dynamically generating something is going to make it difficult to do simple update. Right. Well, it's okay so so I think I think that was a sort of a cool that was a good idea to think, consider adding a link on each parameter page in pipeline syntax to the source file for that parameter. Did did I capture that accurately like or did you mean something different. Like right here, something like that. So basically, basically I can prove this page but for parameters so other chunks. Right so so the concept then I think that would mean that would that page would open to something like this. And it's, yeah finding it maybe even a challenge it's in source main resources, probably Jenkins plug in, get get step. Here we go. It's this file. Right. And so we would dream of a time when URL here would have, I don't know, a hoverable link right next to it or something that would jump to this. Yeah. Cool. Okay, good. So technically it's possible. You can use the generator for that. Yeah, I was thinking I was like, I think we just need to pull in some extra information in the generator. It takes sources anyway, so it knows from where to take this data. Well, at least it, I thought it was extracting them from the, the eight the JPI file so so it's getting them from the resources which is thanks to maven directly mapped to source code right or almost. Yeah, like the reason how it's able to do all this is we pretty much launch a Jenkins or like a plug in manager instance and then load everything into the plug in manager and then use plug in manager or like use class like the information in the classes to pull descriptions and help help text. So it's not like looking at the classes, like the actual lines of like file names. So I don't really know how we'd be able to get that right now without doing some digging. But yeah, it, it, it's pretty much to get all this stuff we create a plugin manager that has every single plugin loaded into it. And then goes forward from there. So figuring out like how it's, how they relate back to actual code will be interesting. And I don't know how to do that right now, but we can try to figure it out. Good. Okay, yeah, so, so I think I think that's a that's a that feels like that's probably relatively advanced because it would mean looking at the pipeline steps doc generator, and extending it somehow but if if we have someone who has Java experience and we've already got evidence that a lot of code students are able to make progress on pipeline steps doc generator right we've got at least one who's been investigating now for a week or two and been asking very good questions about it and obviously got it running. Good. Okay. Any other recommendations or suggestions on contributor onboarding Zenab you were most recently through this experience are there other things we should be considering. Sorry, can I jump in quickly run to a meeting. Oh yes oh Gavin I didn't know you joined us just for a few minutes. Help me on windows thing. Is there any interest in looking into switch Jenkins IO to Gatsby. I think you have a script with better windows, and then it would be same as plugins. I don't know the project it is curious if that would be an interest or you want to stick with Ruby. So, it would be a good Google summer of code project. Potentially. Anyways, I got to run to another meeting sorry. Okay. Well so so Gavin, I'm going to put that on the list and we discuss we discuss separately later or we've got another session in four hours or so and consider because site other site generators were on our minds and Torah something else so Well then I think about Gatsby is all the ui is already done for the plugin site. Oh, yeah. Yeah, okay. Yeah, that'd be a huge man. Okay, so, so, since he had to drop off. Kristen, can you help me is Gatsby is a site generator like Ostrich is or is it a an ASCII formatting spec like ASCII doc or something that completely different. It's a framework and a set of tools for JavaScript. So basically, you can consider it as a framework. It's a bit more than framework though. It's used for site generation so it's used for the generation of static static sites like, like the plug in site is and like Jenkins is one of the options. Okay. It's me it's like if we could consolidate so it's easier like everything is kind of using the same thing it. It's another lowers a barrier to entry development right. For a no one be easier to, to need to contribute. Or, I think you can share it would be easy to be easier to share themes. Okay, I don't think that it helps with onboarding of documentation contributors. Definitely helps with onboarding content contributors or website engine developers. So, so my experience as a writer would be that I would continue to author an ASCII doc and, and then Gatsby would do the processing to convert it to a static site like I do it today with Ostrich. Yes. Okay, got it. Thank you for my not being up to date on all those things. That's great. Okay. So in principle, it's an interesting initiative. But I'm not sure what it really achieves the goal of onboarding contributors to dogs. Right. Yeah, well, particularly now. If, if multi platform is an issue then if Gatsby is readily usable on all variants of windows that might help, but that may not be as strong as compelling argument as we'd like. It's relevant to all this. Well, you can build the website on windows as well. Why you cannot build it easily it's because you have make files and wrappers which are designed for the greatest environment. So these wrappers do not work correctly on windows, but they work correctly and we say if you configure it properly. So it's not the framework itself. It's additional environment we use to make development. Okay, so the, so the, the primary barriers then in contributor onboarding really aren't the awestruck generator. It's the things that we've placed around it in order to make our work faster and more successful. I see. Okay, got it. All right. Thank you. Any other things we should discuss or note with regard to improving contributor onboarding. We should be doing more programs and we should be taking more tasks. Because historically we get contributions through various programs and outside them. There are not so many activities. So what could be done. There could be additional, let's say user experience hackathons, or that could be ongoing programs like you can dedicate some budget for spark and say that hey you create documentation based on whatever conditions you get a T shirt. So something like that could be doable. But if you want to onboard contributors, the main problem right now is the tooling is outreach. Good. Okay, yeah, so, so things like Hectober Fest, the Google summer of Google summer of season of docs. Other examples like that are outreach programs. Do you think community bridge is a vehicle for this or is it more that that would be a funding mechanism to do help drive it. Anything else on on contributor onboarding. All right, next topic then was Google season of docs 2021. This one I'm, I think we should just set our goal that we want to participate, but I apologize I have not read the detail the documentation in detail to see what the, the new requirements are one of the requirements has to do with their funding model has or their payment model has whereas previously Google season of docs paid the contributors directly. Now they pay the, the open source project and then rely on the project to pay the contributor. Speaking of that we still haven't received our stipend from the previous year. Oh, dear. Okay. All right. You and markie couple of months ago but I'm not sure with this. You contacted. I, I definitely have not so I need to take that so that's mark needs to locate the stipend from last year. That was Google season of docs. So for JSOC we received the money but for JSOC they go to SPI for JSOC we agreed that they would go to CDF and community bridge. So they may might have reached the Linux foundation, but they haven't been able to edit our community bridge account. Okay, so it's so the challenge there is may have gone to CDF, but it didn't meet it didn't reach all the way not into the Jenkins account. It's not CDF so basically CDF has no its own legal entity. And then they use Linux foundation treasury. So basically for all links foundation projects, Google just sent the money to the same account. And then there should be additional details and comments for payments that should have magically redirect it to community bridge. This magic didn't happen. Okay. Okay, that's, that's one that I've got to get done then. Okay. I haven't read enough about the rest of it to tell what other requirements I assume that they will expect project ideas, and that those project ideas. Um, so I noticed there's a GitHub repository this year. I don't know. Um, because I knew there was nothing like that for participants and organizations. So, basically I think you have to clone your repository and add your details as a participant and also as an organization. Currently, I think there's just one organization there. Well, I don't know if of us are joined by new, the last program there was nothing like that because I didn't have to add my details to any repository or anything like that. Okay, well, and it looks like we are in the right time we are one month away from their deadline for organization applications. So, so if we want to participate we've got four weeks roughly to get that ready. And that means I've got to I've got to work out the funding question or the funds transfer question to be sure that that things go where they need to go. All right, let me put a link to this. All right, so March 26 is the application deadline. I think another thing that's important here is to make sure that we have, yeah, like, I guess it's a nice bullet before we even try to do this, do we have good project ideas that'd be worth it. Right. Yeah. So, and I had heard several already in just in sessions recently cloud native things like hey, more details on how you use the operator, more, more pipeline examples is certainly an a frequent request from the feedback on our sites hey give me another example, why don't you have an example of this and of that. So, any, anything else with regard to Google season of docs, Google summer of code we've got, we've got the rest API documentation generation project that is a proposed idea. I'm going to link to that. And 2021 project ideas are here. And the automatic specification generator is very much about documentation. Right, it's, its goal is to provide a rest API description for the Jenkins rest API is, but in a format that could be used to be could be presented through things that present things that can be applied with the open API spec. Right, that's the now Kristen you've been you've been involved I believe with one of the students investigating this. Yeah he was asking some questions and I tried to point them in some good directions and kind of what to look at maybe as background to get used to, like, what rest generators are out there, the, the, what we're using for the pipeline step generation. This, this looks like a promising thing I don't recall any others go ahead. As I know it's like we'll see like have what the students proposal looks like to you. Yeah. Yeah, others don't have as immediately obvious a documentation impact as that one does. And they all have a documentation component, but it's more as a result of doing the development that it is documentation creation like that's like this, the rest API docs is right. I mean I guess the first thing I was like we should definitely make sure that is part of Google summer code that there's a heavy emphasis on documentation. Or like they need to make sure that they document their projects. I know that there's blog posts that at least should help with some of the things but any type of tutorials that they can write for, depending on whatever they did be helpful as well. Well, and okay there's one for me that probably I'm guessing just looking at, let's look at those project ideas. This one is a plug in that will probably provide a pipeline step. Therefore, that pipeline step should have documentation for the step and documentation for its arguments and preferably some examples. This one is a pipeline step right and it should have documentation for its arguments documentation for the step and examples. Now this one isn't all right that one's not a security value thing is not a not a plug in per se, but this one is so at least half of these are aching for and maybe what we do as a doc sig is periodically insert ourselves into the mentoring team saying just parachute in briefly and say, we wanted to show you how to create documentation for the thing you're creating just to remind you that you need to do this. Yeah, even seeing that Kubernetes operator one of like oh this is perfect ties right into the documentation we just updated. It's a good chance for them to the student if a student chooses that project and it gets accepted for them to make sure that that documentation stays up to date. And, and I had, I, we've got the action item from other meetings where we want to tutor people on how to do this, how to provide online help. I liked yours of, hey, identify places, identify locations in existing documentation that should be updated. I think the operator one makes perfect sense to do an update to Jenkins on Kubernetes. Yeah, like, you know, just wrote all this stuff it's like let's be, it's like let's make sure that all the stuff that you know you just wrote state. Thank you so much. Yeah, oh yes right. Like she's just, you know, you just did all that work. Like making sure it's like making sure that it stays in sync with everything else you know like it's, here's a chance to make sure to make, I guess encourage good to the docs practices right where it's like hey you might be doing something. Here's this startup guide, make sure that it's what you change is reflected in the guide. Yeah, very good. Excellent. Okay. Any other, any other ideas with regard to how to help Google Summer of Code. Well, the real problem is that these ideas is mentors and all of them. The project ideas. You have a lot of areas in there but documentation seems to be more less contained. So if you go to rest API, what else could we do with docs there. I don't think really too much right because like a lot of it's the emphasis is on coding and a lot of what we're running into with docs problems are the fact that we need work like, like documentation versus code. I don't know really what else. Also maybe pipeline examples and demos. So theoretically creating a bunch of demos could be counted as a coding project. Oh, okay. Okay. I didn't know that. That's interesting. That's a good point. Do some exploration about what you can actually do with pipeline or pipeline today. Yeah, so it's not like taking 100 Hello World pipelines. For example, if you said that let's create reference pipelines, let's say for Android development. Like that, then it magically starts assembling a coding project. Okay. The same time it source documentation thing. Yeah, I like that. Okay, or a, a go lang development pipeline example, right or a. Yeah. Java's Java's pretty broad. Well, I guess we've, we've got examples already of, of Java and and npm. And maybe calling of examples is too strong. We have tutorials for Java npm. Python. I think are the three we've got currently. Well, I think any other topics on Google summer of code before we go on to the next. All right, so this next topic then improvements to the pipeline step generate I think we've already covered. We talked about different, different possibilities that might help us a bunch there. Anything else you'd like to add there before I otherwise I was just going to delete this from the notes and go on to the next topic. I think we're good. The next one is wiki migration plan so Olivier wants to wants to avoid having to up wants to spare us the update update of the current wiki. And I understand that right that's that's an overhead that the it's read only not giving us a lot of value, but it has it contains lots of useful content still. The challenge there is the transformation has been difficult because it needs a certain level of skill and understanding as to what information there is useful and what is not useful. It's not a it's, it's not, it's no longer a directly mechanical transformation. Well, but it's still not fully automatic. And we have hundreds of still pages. Right. So, yeah, it would be possible to apply some scripting magic, not automate conversion, but it's still require some coding to do that automatically. Yeah, one of the one of the suggestions that I'd heard was hey, if we wanted to spare the spare cells the update consider trying to convert it into a static site. So keep its content but just convert it to a static site. And I'm not sure if there are tools that would do that. That would buy us more time and not have to update the wiki software. Because we can just use the same exporter logic, generate a ski dog pages. It might not be fancy, but it can be done in an automatic way. Okay, so the idea there would be use use the a doc translator. All the pages, and then just keep them there, keep them there until someone can make a make better decisions about them. Yeah, it's possible to do something more sophisticated, like automatically migrate content, non plugin content. You can create something for plugins. But if you just want to kill confluence maybe such static generated would be the best thing. And you can actually even avoid hosting this site you can just at the redirects to get up pages. I've been taught of that so to get have pages so that they would host the site while we're in this transition period. So basically it would be transform each page into an ad hoc file in a GitHub repository, and then put in GitHub pages front end over the top of that repository is that what you're saying like, I wrote a script to do that for all the plugin it's really not that hard to do. Oh, okay. All right. I mean I don't know if it's worth keeping the one I have but I just want to see if we could make a repo that was editable by people in transition period. And it was totally doable and you could be served GitHub will serve static HTML files just fine. So basically then that would mean that a page on the Jenkins wiki would could be redirected directly to a page hosted by GitHub. And, okay, the layout will likely be different because the destination page will be asking Doc, but but rendered using the GitHub rendering. I don't know what all like browsing do a one time to export every page through ASCII doc and convert it into a doc file and put that in the repo that's now editable by people and serve by GitHub in the shutdown of it. Yeah, that's that's what I understood. Oh like did did Gavin's description there match what you were envisioning. So, again, if we just want to get written confluence we have resilience of options and option would work. Okay, good yeah and I think, I think that's the that that was the open question for me I, if my original assumption on wiki migration had been not that the goal was to just shut down confidence but it was to get the content into the new destination and validated but that's a much bigger project and I don't see that happening reasonably during 2021, not being complete anyway. So this idea of a mechanical transformation or of a of a converting it to static a doc pages has, I could see that that might be feasible in 2021, where the conversion of content into Jenkins.io destination pages in the official handbook is probably not going to happen in 2021. All right. I got what I needed from that wiki migration plan discussion anything else there. Okay, since Gavin you're back, adding site search to the docs I have to highlight what you've already done Jenkins plugins. Mark you wait. Search by Algolia do you see that. Tell us about it Gavin, tell us tell us how it's going tell us what you've learned. Yeah, I mean it's, I don't know there's not a lot that I've learned so far. I do like. So, essentially, plugins site originally used elastic search in bed into the plugin site API, and it does work. It's just hard to manage. So, I looked at Algolia. So essentially every time we build the plugin site we upload all the results of all the metadata to Algolia and then go it can then which will do its own searching. The nice thing about Algolia is it also has built in metrics. It's not only using the back end side of it but it also can do front end side as well so right now we can get a list of like what words are being searched for what phrases how many results are returned for each search result. And then it's marked notice the other day. It actually does typo correction, which is really cool so if you have a common word that you type oh it'll switch it over. I think it has synonyms support so I think you notice that one plural word is found properly. I'll admit I haven't played a lot with their searching but that's just out of the box functionality we can actually add our own synonyms we can do. You could even hook up their front end analytics and it can see which which result people are clicking on the most, maybe not mostly not maybe not super useful for the plugin site but might be more useful for like the doc site itself. Front end analytics. So I was going fast. Yeah, it's, it's pretty slick. It sounds like their open source offering will work for us. I have to see how we'll give it a couple days because I think we have still five days left on the new trial for the plugin site. But, and then we'll see how much traffic we're actually generating and everything else but I think it's totally within reason to request open source stuff and there's no reason. I can't use like site search if I fall back if I go it goes away or something. But I mean, it's pretty slick. And then if you look at their demos, they have instant search support. So they'll can actually provide you list of search results as you type in almost real time like it's super super fast. I'm sorry, I'm going to mask on this in here. So it's hard to hear but I it's called instant search. Insta search. Oh insta search. Okay, got it like that. Yeah. So it will offer hints. It suggests words while I'm typing. It's actually just real time fast response. Right. So you can, like when you're typing in Google you can get results right away while you're still typing out your query. Okay, so they on their docs, they have tons of demos as well. You have to see some of this in practice and see what you need I just hooked up the basics of basic search. And then I actually added authors into the search because I use it. So I thought it was nice to have. And that was it that was a crucial thing right because you've added maintainers authors added as metadata. Yeah. To the search. Thus, thus we find plugins by maintainer. Yeah. I don't have a UI for that specifically but you know down the road we can have like right now we have a label, you can search for the label adoptive plugin. There's no reason we couldn't have certified author as well if you want it, but so this is just an experiment to see if it worked I figured it was easier than to hook up the main site. So it's been a positive search thing so far. Are there, are there, are there limits in terms of how much of a load we can place on them and have you have you hit any of those kind of limits yet of their I have not. We've only been running this for, we haven't been running nine in 24 hours yet. There are limits, the free, the free one which will be switching over to soon has low limits, but the open source one is pretty high and they and from their page it seems like they're pretty open to whatever you want as long as you talk to them about it. If you want to check really quickly if you can log into the site you can see their overview. So Algolia.com. Yeah. That's interesting. Do I already have the account logged in. I probably do. Well, I know, I know you have access. Yeah, and I don't see it in my, I definitely do have access. I can't log into this laptop so I can't show. Yeah, let me see if I don't, I don't. I mean, the basic. Oh wait, yes, of course I do login with Google. Of course here we go. That's how I would have done it anyway. Yeah, so Jenkins plugins. That's my dev. That's my dev one. The second one is the. Ah, okay good so we're in. So we used in our run the free trial plan right now we're not free yet over in 24 hours we use five units which includes updating indexes which I can definitely make less expensive. And how many search requests we had 4,000 search requests in the last. So go to the analytics on the side you can see people who you know what searches are the fourth one. 49 users, 100 searches, an average two searches per user, and then the tabs across the top will actually see what the searches are what's popular what's not popular what has results. Now we don't have any of the front end one so searches go quick doesn't work but. Yeah. Wait, wait, oh you're saying searches without clicks doesn't work right because because we're not giving them that data right we don't have whatever. That's that's okay. Yeah it's it's I'm in pretty slick with it and I think it'll be a lot cooler for non plugin because plugin sites can be a little bit boring in the searches, but. And geography based view of who's who's hitting the sites and you should scroll down that page a little bit further you can actually see the latency for each country. So Canada is the fastest which yay we rock. I have fiber and I'm probably the only one from Canada searching. That's great. Excellent. We just have to move you south by several hours put you into Seattle or something. Yeah, yeah, but I mean it like I said this has been a good prototype. Nothing in the plugin site is committed to this yet we've wanted to see the work. I mean there's no reason we couldn't do another trial in a couple weeks with elastic search if we want to go that route. So, I don't know, I saw that you had notes about it I don't know if they have a sad product as well. Yeah, there is a product called website search. So it's not the elastic search crusades that others and the long service, which is of course based on elastic search. But it's a separate company which was acquired by elastic several years ago. And yeah, and I think we okay you gather for the dark side the networks I mean I could hook up one for plugins as well without much issues. It's not it's not a very complex set of data. Yes. So, I chose this prototype. It has support for synonyms and for other things out of the box. For example, our favorite thing is note slave agent search would work out of the box. And I'll say you can index multiple domains on the same search. So you can use search for plugins or website. I had a prototype for several engines. Yeah, Agolia has all those things. And then Agolia has an AI feature which I don't know what it does. And I don't think. But they have a little tab that says AI. Yeah, and that's very bottom. Oh, here we go AI re ranking. Yeah, I don't know what it does. I don't think right. And it's a paid feature but I'm just like, yeah, they have AI. That's, that's cool. Okay. So like from our point of view both feature both systems have similar. Yeah, right. Search engines. So now in case we can take whatever we want, we can also contact Google to see whether we could get sponsored. Because you can also use Google search, the problem that by default it will show you promote links. For example, we can create a search in just five minutes of work. But then for example, you will get paid promotion by Circle CI, you know, search layouts. She's definitely not good. Yeah. Right, right. Like companies, companies antagonistic to Jenkins, right? Yes. And actually I contacted Google in September. What would it take us to get sponsored option? And well, basically the response was that the Linux foundation isn't exactly an unprofit thing from our definition. So most likely not. Oh, okay. I based on what I've seen about Google and how you communicate with them, not you, but people do. My preference would be elastic or like Goliath over Google. Okay. Just because if there's a problem, you're more likely to get no response than anything useful. So for elastic, we have a number of contacts. Victor was going to look whether we could actually get sponsorship. Again, I contacted elastic. And at that point, the response was that now they don't have such program. Oh, okay. So, so you did get an answer back from them that they really don't have an open source program currently. Yes. And I can tell you flat out a Goliath does because it's very public on their website. This is how you apply this is your minimum requirement. This is what, and if you don't fit in with in the guidelines we can chat with you. Good. All right. Excellent. So, so Gavin, it feels like we've got five days on the trial. I assume your intent is to continue through that and now do would it be to our benefit strong benefit to apply for open source sponsorship before the trial expires. I'll, I'll, the one of their, when I signed up one of their Olivia is here too. I've been a contact or one of the sales people contacted me so I might just reach out to them. But I think that's what I'd like to do before it ends. Okay, all right. So, so the idea then is. Okay, so, or maybe. Even 20 minutes ago I received an email from an account manager to ask if we have any questions so maybe I can try to see with him, if we can have an SS sponsoring. Yeah, or we just asked to expand the trial for because we just finally got it set up yesterday. Yeah, one of us will take care we'll get it, we'll get something in place to send this trial here before we commit to anything. Okay, so, Olivier, did I capture that correctly that you were contacted just recently by an Algolia account manager. Okay, good. All right. It's part of their signup process. So yeah, but they're they're super responsive. Yeah, that's wonderful. That's really great. Thanks Gavin. Do you do you want me to continue to, I mean, do you want me to engage or I'm doing it go ahead otherwise I will probably tomorrow I can't do it tonight. So, I'll do them. Okay. Great. Excellent. Gavin anything else you wanted to share on in terms of progress on site search. No, I would like to decide at some point if we want to start giving them front end information. It seems like it could be a privacy issue. But it might be interesting to see how much data we can get with analytics on it. Okay, so I missed part of the question so could you phrase that again it was, what kind of information are we not sharing with them. Right now, we're doing a back in search for just doing an API call. We're not tracking to see any of the actual, let's say, quick information like which results are useful for them which that kind of thing. So, that would be essentially a little bit to be injecting a little bit more their JavaScript into the page which means they potentially could track all kinds of more information about the browser and everything else. So I don't know if we want to do that if we normally do that. So, I didn't hook that up but they will be nice. We might want to do in the future. Olivier, can you help guide me on what we do with regard to tracking right now I thought we had some site tracking that we do for www.jankins.io through. I don't remember it's good. We have Google analytics, but we disabled most of the options so we mainly use, we mainly collect information about where the people come from, how long they stay and stuff like that. But for instance, we don't buy default with disabled as much analytics. Okay, so I would I would assume it would be okay to collect the same kinds of information with Algolia that we're currently collecting with Google analytics it's no if so as we don't make it worse in terms of the information we're gathering. Is that a safe assumption or is that that being too creative. From my point of view, I just didn't do it because I didn't wasn't sure if we wanted it and it's useful, but yeah. I think if we want to enable if we want to collect specific data, we have to be clear with the community about why we collect those data, because many people doesn't like the idea that we collect data by default, and I'm part of them. So I know that for instance, compared to the US, European people are usually more concerned about data policies. My approach would be we do not collect data unless we have something that we want to to understand. I would hold off until we get open source sponsorship and then we have an account manager me ask them, like what their front end collect data collection is because if it's just tracking on which search result you click on, then I don't think it's an issue. If it doesn't, if it doesn't collect metrics about the user and just collects which you click on that fine. But if it starts collecting about saying hey you know everyone in age five clicks on this link you're like, that's not what we want. Okay, that sounds so yep. So, so I think I got it correctly Gavin understand the metrics they're gathering before we decide to enable any of them. Did I phrase that correctly. Yeah, and I wouldn't even worry about it until we decided for doing elastic search or like it's just not right. Yeah, so so that's your conservative approach of don't gather. Don't gather anything but but the very basics sounds really good until until a decision is made good like but you saw the stats I mean we know I mean they track IP request for searches so they know what country that's basic searching. We know how many searches they do, and then we know what people search for because this is nature of what people searching for that's good enough for our use, I think. Right, we don't really care if they're you know on a phone or you know in this country doing this search or anything out there that we just we're just curious about what the like if you look with search with results. People are searching for Java 11 plugins. That is something we should probably address. That means we have to put a warning and or something you know like that's the piece of information whether they click on that their result is only care for going to tweak these search results drastically we're not looking at SEO type things. Right, right, yeah so yeah okay here's your example you said you mentioned Java 11 so yeah so if somebody's looking for that and that may indicate we need to do different labeling or different you know because this Kubernetes v one point whatever with the version that just means that our, we're not actually including version numbers in our search methods so that's something we could fix but we don't need to know that which one they clicked on for now. Right. Good. Okay. Excellent. Anything else then with regard to site search. The last topic I had was documentation and inventory rework inventory and rework proposal. And basically this is, we've got a lot of content on the wiki that needs to be mapped into a where should it go in the Jenkins handbook, or where should it go on Jenkins.io and it's a much bigger project that the docs office hours will take on incrementally and stepwise. I don't think we need to have any deep discussion here just noting that this is one of those things where a group of people working across several months. We'll be able to improve what our final result is, as we steadily move more and more content from wiki to curating it and then putting it into www Jenkins.io. That covered all the topics that we'd identified are there other topics we should include in discuss before we end this track. So, one of the things that's helped me in the past was if I described described the things I intend to talk about during the summary session tomorrow. And so I'm going to mark those here I wanted to talk mentioned that we we think we should participate with she code Africa that contributor onboarding is is a key topic for us and Oleg's point about outreach programs are the most, most crucial is certainly accurate. We want to be in Google season of docs. I don't think I was going to mention Google summer of code because we'll be involved. Well, maybe I should because we want to be involved and we want to remind people about how to make docs effective in that environment. So yeah, let's put it. We talked briefly about the wiki migration plan and that we need a plan so mention that and then site search and for me this is a big one. Just just a question regarding the wiki. What about putting it on the VPN. So if we still want to keep it as a full back solution, maybe we can just disable the Apache service. So we would for instance need I mean, basically what I want to try to do is to not keep that service publicly available if we don't maintain it anymore. So if we just disable. So if you just wouldn't place a firewall rule that that block everything. Maybe we can see keep it as a full backseat and find information. I don't, I don't think there's any point in. You mean like only allowing. What would be hidden behind the VPN just logins. I mean, if it's read read only then on the VPN it's not useful anyways. Yeah, see for me, I think Gavin, your point is, if we make it private, we've, we've negated its value to the people who are currently reading it for information that's even though it's out of date it's still information. So we can mirror it, like use W get mirrors so we can just dump all the content to the static HTML file and then serve that and get rid of the actual confidence part. Yeah, that's what we just cast before you joined so creating static site. But once we create a static site with content we do not need confidence, we can just kill it or save up somewhere that we want to need a service run. Yeah, perfect. That's easier. Yeah, and, and so, so I think, I think at least the conversations are going in the direction that that you were, you were wanting Olivier that hey let's let's make it so we're not maintaining a wiki service. And then all we have to do is get rid of that. One step at a time Gavin one step at a time. No, all the steps at all the time. You sir are an optimist I like that that's great. All right, and then I want to mention. Okay, so those topics. Any objections to my using mentioning those topics during the, the presentation tomorrow at the closing session. No, I have no objections I just remembered. Zibeck didn't update to the wiki migration stuff to make a more accurate progress indicator. I don't know anything about it, but I know he did a change to that. Oh, nice. Okay, so you're saying that the wiki transformation this conversion progress is now more accurate. Yeah, he changed. I don't mean I don't fully understand the change it looked good and we merged it but it's it filters out a bunch of the plugins that are not used anymore. It just had better results and I wish he was around to say what it was about. But this is another thing that might be nice to mention as well for people who are using it. Yeah, oops and I see I misstated numbers were one third of the way through our plugins. We've translated 600 over 600 of the 1800. Okay, thanks everybody next meeting is the Jenkins governance board. I'm going to go ahead and end this I will post the recording of it once the recording has processed. See you in a bit. Bye.