 All right, welcome to Jenkins documentation office hours. So here we are. Topics that I had on my agenda. We're see any action items we had from the past. No. Okay, good. So topics I had included site search for plugins that Jenkins.io status report site search for Jenkins.io documentation site. Jenkins contributor summit, just a bunch of action items there. Google season of docs. There we need to, I think, determine some action items and Google summer of code. Anything else to put on the list, Meg? Um, do we have an update on. She codes Africa sponsorship. Good. Let's put it on the list. So. And so let's let's put she code Africa contribute on how about, and then we'll talk about both sponsorship. Okay. Contribute on. Sponsorship. And, uh, and project ideas because we need both. Project ideas mentors. Okay. Good. All right. Let's move that one up high because that one is. Is good to have. And much less about status and more about what we need. Okay. Anything else. All right. So she code Africa contribute on. It's coming in April. And sponsorship. The Mark wait has asked his employer to sponsor. Looks promising, but not committed yet. And Alex Earl. We'll ask his employer to sponsor. I don't know how that will go or not go. And Mark has asked, what's that? Go ahead. Can I ask who Alex or a works for? Is that. You certainly. No, is that who does he work for? Yeah, he works for Broadcom. Okay. And to ask his employer and his employer is IBM. So I haven't had any response from Jim yet. Alex said, yes, he would go ahead and ask. If you're aware of, and if you're aware of others who are in the community that might be, might be worth asking them to ask their employers. I think it's worth, worth us considering further. Yes. Project ideas. We had. See several in, in document notes, right? In these notes. They included things like. Screenshot updates. Technology updates. There were. Let's see what else. Kubernetes Jenkins on Kubernetes continued pipeline examples. All right. Pipeline documentation pipeline. Let's see how would we say it pipeline. Argument. Help. Step help. For specific plugins. All the different set of skills mentors. I assume that given it's she code Africa that you're probably not well suited because your time doesn't likely work with their time. What time are we talking? So figure their Europe, their Europe or Europe plus one hour. So very, very early in the morning. Or very, very late at night. Yes, that's true. If we work until like three or four in the morning. So that would not be a problem. I could. I could catch them in their mornings. Okay. Willing if. Early morning. Africa time. Works. Good. Good. Okay. Tag team that would keep, you know, they wouldn't have to be waiting 24 hours or something for. Right. And Kristen, if I remember, I was closer to. Yeah. Early evening. Let's call it early evening. And I think Kristen is the same that for her, we currently meet at. Yeah. About 6 p.m. Africa time, which is in her case, I think 9 a.m. ish. Okay. So. All right. So ideas. Good. We're certainly looking for more. And those ideas are in large measure documentation ideas. And what Zenab reminded us was that. They would also love to have coding suggestions. And I'm open to those as well. I just don't have any immediately to offer. Right. Maybe we can team up with Oleg Oleg's probably got his. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. That's a good one. Actually, let's take that one. Friendly issues. Do we have any test suites we need for either. I mean, reasonable to do either docs or software. Sure. Sure. We've got. Get client. Plug in. J unit three. To J unit four conversion. So we have a lot of. Of crucial test coverage of crucial program of crucial plugins. We've got acceptance test harness. To encourage these junior people to get serious about testing, because we'll never get the old people to get used to it. Right. Careful, careful, careful. I'm old. I can say that. Okay. That's good. That's good. That's good. That's good. That's good. That continues. And I will continue to be addicted to test it. I like it. All right. So anything else on Chicago to Africa. I'm thinking that's enough. I'm not. Do we have any idea how many people might participate? Depends on their funding. Okay. So the, it's a, an interesting combination of if they don't get funding, they of course can't pay these, these people to these women to do coding. They have to be paid for that month to do it. So it's, it's, and that's very important, right? This is not just in volunteering your time. Roughly. How much does that, like our $5,000, how many people does that sponsor? I have no idea. I don't know what their rates are. I don't know how much overhead the organization takes. Haven't explored that. Just curious. Yeah. I mean. My experience when my friends were in Namibia and Ethiopia, they were like, I don't know what like $200 or $300 would pay for. Right. Right. And that's my suspicion is this is probably. Very, very reasonable rates. That's my assumption. Yeah. All right. Next topic. So do you have an action item? Do you want to talk to Oleg about whether he has anything he wants to throw into the mix? Oh yeah. Let's, let's put that. And people who would like to mentor. I don't know. I don't know. I don't know. I don't know. I don't think you want me to mention them. Good. Yes. Okay. So docs. Good. Okay. It may be that we even just have stuff that needs some serious testing that it's not getting. Right. Right. That's, that's another. And I don't know that that fits with what they envisioned, but it's a good, good question. I don't know. I don't know. Testing. Performance test automation. It would be fun to have some usability testing on the. New user interface. We think it's good, but I'm. Even I know too much at this point to be a worthy tester. Right. If somebody's fairly new to this, does that make sense to them? Good question. Yes. I don't know. I don't know. I don't know. I don't know. I don't know. I don't have any testing that you can automate. Right. You really have to watch over the person's shoulder and carefully observe what they're doing. Right. And there could be cultural ramifications too. Yep. Anything else on the contributon? That seems like plenty. If we get half of that, I think we've done well. Okay. So site search for plugins. Jenkins.io is running. Working well. And it's well behaved. Cool. Now I have not looked at. Let's take a look at the statistics just to see. Log in with. So if I go to Jenkins IO, will I find this search box and I can play with it? You will. So I'm going to, I'm going to include it actually in this recording. So let's put. Here is the Jenkins plugin site. So when I look at the plugin site, it has a browse button on the left and a search button on the right. For plugins. If I browse, you'll notice it brings up the list of all 1,800 plugins and a search by Algolia. Icon. Oh, wow. We've already got it. And now if I look for, let's say I look for a maintainer like me or a. A concept like a branch source. Or maybe a strategy. Or maybe a project like that. Basic build strategies build basic branch build strategies is not the word strategy, but the Algolia search engine knows that strategy and strategies are synonyms for each other. Wow. So very, very nice. Yeah. And it's, it is, it is every bit as fast as it was before. And it supports all of the layouts, you know, all of that. Yeah. Yeah. Search for coverage again. When we did that last week, I didn't want to get to go down the rabbit hole with everybody else there. But that you not go JUN OCO or something plugin. That you ran it. We were using, we were looking at it for how poorly documented it was. Oh, I don't, and that was supposed to be for code coverage. And I don't think the search picked it up last week when you did that. It's an interesting one. Yeah. Let's look and see why not, because it should have. You're certainly correct. It should have found that. But let's find out why it didn't. Okay, so it doesn't, it has the keyword coverage. It has the topic coverage. I searched for the word coverage. Am I just not seeing it here? Is it there? No, it's definitely not there. Okay, so, oh, wait a sec. Go back a page. No. Okay. Oh, now that's interesting. So somehow or other, it's stuck. Chococo. There it is. And it has the word coverage in it. Lots of places. And yet it did not find it. With the word coverage and it's showing the results are rather odd. It shows two. One and two. And it does show all 12. But if I click one here, it goes into an I'm stuck. So I'll need to report that. Now I wanted to see what the. What's the, what's your name. The, the group that does the software. Have we got their permission to use it? Are they considering us nonprofit? We do. We do have their permission to use it. They have granted us permission to use it as an open source application. And we're using it. And they've even implemented. They've, they've already started the indexing of the doc site. With the thing they call doc search. So they've already started it. And Gavin hopes to. They've provided instructions. To integrate their search into our site. And they've already got a search. Yeah, I'm wondering if we should look into this for the cloud V stock site. Yeah, that's, that's an interesting question. And I would assume that they've already got a search. Thing behind it. I'm trying to remember, I haven't, I don't pay that much attention to that. And I should. I tend to go to Google. But, uh, But this looks so powerful and it clearly got implemented so smoothly. Right. And I think I saw something go by that that was one of our, like, North Star things was to improve the search engine. It adding site search is on our roadmap. Yes. And. You're for open source. I'm saying for cloud these, I think. Oh, I see. I think that might be a North Star item that. Good. Because it looked like it was going to be a biggie might be down the list. Whereas if we've got a. Well, there's great advantages to us. Jenkins IO, if it's good, you. Right. So I'll, I've got some things I need to report on the plugins up Jenkins at IO site, but let's see it was the reminder was. Tab two initially. Instead of tab one. And clicking tab one. Causes. Spin. And the other we saw. I just realized that in everything that I put in our courses about plugins, I always assume that they know what they're going for. I haven't any place told them. You know, go to the site and search for things. And now I will, I can actually add that this afternoon. Good. Yes. You know. All right. So I think that covered plugins. Jenkins.io and ww.jankins.io anything else. Any action items out of that, right? Well, well, certainly we do, but they're coming up in the next, in the next topic. Oh, okay. The contributor summit. We need a docs roadmap update, which means site search and more. Need to be added to the. To the Jenkins roadmap. We agreed on those and they were very well received. So I've got the action item. Likewise for the platform roadmap, because I was the track leader for that one. Kara bill of Mark is the track leader for. Cloud native and. She or I need to create that. And then Oleg Nanashev was the track leader for securing the delivery pipeline. I don't know that he's going to be available to do it, but I need to discuss with him because I haven't looked at the details of their results. I just listened to the summary and was delighted. Any other questions on, or any questions on Jenkins contributor summit. Oh, one more thing, right? Goof. Mark to send the retrospective. Survey to all. That registered. We had. We had. 68 register. 25 attended the opening. Additional two or three. Attended tracks. So. Worked well. Did we count how many viewed the meeting late? Because I didn't attend, but I did watch it. Have not. That's a good idea. So. Count. Video views. Okay. Anything else on contributor summit. I don't think so. Very interesting. Next topic is Google season of docs. And this one is a little more complicated and. Somewhat busy because the application deadline is March 26. So we are now less than a month away. Right. So we have a lot of time. We have a lot of time. Needing to submit our application. And so that one needs time from. 26. And I need to find out why our diversity people are. I would like to at least like send out some publicity mail. That would target some of the underserved groups to get them to try to apply for time for season of docs. Yeah. Well, and that's. We've got to get our materials. We've got to get project ideas into the, or into Google season of docs. I was just saying that as a side. I'm going to, I've got another. I'm going to go another way. Got it. Okay. That way they're blowing me off. Right. And in terms of. We need to assure that we can process the funds. From Google season of docs. Oh yeah. Yeah. Yeah. Yeah. Yeah. There are some, it's different this year in that they're having the organization, i.e. the Jenkins project pay the writer instead of having Google pay the writer. I remember that. Yeah. Okay. So Mark Jonathan. Hello. Jonathan. Hi. Hi. So. There is no ideas for projects in the Google season. Of docs this year. And they've got three weeks to get their proposals. Then we need to get to work, don't we? No, no, no, no. This is not, not the authors that have three weeks. The organization has three organizations. Okay. Because if the organization doesn't send the project, there is no project this year. I thought it was, I see, I haven't looked to be sure. I was, it was assuming that. Yeah. So let's see if we've got. The project proposal page list of key needs. Goals or problems documentation solutions and possible metrics, a public page. So, so this is our intro page that we've already got. And we publicize that. And then for, yeah, so this looks like. It's using a similar format to Google summer of code in that each, each documentation ID is a separate idea. And a different format of code for each application. Again, statements of interest are received from technical writers that are interested in working on one or more of the project ideas. Oh, so there is no. Exclusion. So if we don't send any. Prototype of ideas. The writers can send their own for us. Whether or not. proposed project ideas, the writers can propose alternatives or different project ideas they are welcome to. Oh, okay. So it's not a requirement to participate, to Jenkins participate in this year? Well, it may not strictly be, but the reality is, if we don't do this, the likelihood of them accepting us as a project is much lower. Right? Google season of docs will look at what we're doing and they say, if you don't have good ideas, it's not as likely you'll be successful as if you have a bunch of good ideas that people can choose. Probably, yeah. So what is your plan for this edition? Over the course of the next three weeks, we'll prepare the, what we'll do is we'll put, we'll basically go here and follow the same machinery we used last year with the Docs SIG, where we had documentation is here. And if we look at Google season of docs, it's here. And we'll extend this to include 2021 using this Google season of docs page extended with a 2021 and this, that's the same pattern we've used with Google summer of code. No, I see. And then project ideas go here. So here are the current list of project ideas we had suggested in the past. And I think these, all of them actually are still valid and still useful. We need more Kubernetes documentation. We certainly need many more plugins migrated. The Jenkins user documentation re-arg may not be ready yet because we should, we need to do the inventory and placement of pages, but new solution pages, absolutely. We could do one for Kubernetes, one for GITI, one for GitLab. Yeah. Okay, okay. So there, and so I believe these four topics, five topics, it's good enough. So there is something I can do to help with something. Or we're seeing other control. Good. Well, so there are certainly if what we need to do is read through the instructions here in terms of the organization application process and identify issues that may need to be raised to attention. For instance, the complicated one is this one right here. They, they Google last year paid the contributors directly. This year, they're going to use this thing called open collective where they'll pay the money to our organization. But that means Jenkins has to establish an open collective account that is able to receive the funds. It's starting May 8th again. Going. Right. Sorry, what was that? So, I was being a smartass. Go ahead. No, no. Okay. So it's up to Google sent the money for Jenkins organization and Jenkins just to pick the winner by his own and just pay it. Let's, let's see how that works. So I think the way it's decided is choose the most promising idea each organization. Okay. So create the proposal. Okay. Submit by the applicant. Okay. So we choose one project idea, one, one proposal to submit. We submit it by March 26. And then apparently if we're selected, we launched the project with the chosen technical writer. We announced the selection of the writer and then we start the project. So Jonathan, did that answer your question? I'm not sure it answered my questions. There's some things about this that I'm not entirely clear on yet. So we may need to ask the Google people to give us some further clarification. Perfect. Because I assume somewhere in the middle here, let's look at the timeline somewhere there is a date where they announce which open source projects have been submitted or have been accepted. And where is the timeline? Oh, there it is. Okay. Yes, there we go. April 16, they published the list of accepted organizations and we can start writing then. But, and by May 17, we have to have completed onboarding a writer. Perfect. Okay. And one month later, monthly evaluations on the project status. And in November, submit the case study. So did that, did, did everybody's questions get answered with regard to Google season of docs? Right. Now, do we have some project ideas from last week's meetings that can be folded into this? I don't recall any. That's, so see the, it's a good question. How about we just put an action in there, review the notes from the contributor summit for other ideas? Well, maybe any of us who want to, I have some big ideas that need to be refined by somebody else, but I could make up a little list. Okay. Fair talk. Did we talk about there's, on each page of the Jenkins IO doc, there's a place they can click to report problems or something. But did we talk about making a click that would take them right to the GitHub site and let them edit online and submit a PR? We did. That's in the context of this pipeline steps doc generator project idea. That's more a Google summer of code than season of docs project because it's, it's really about the code that needs to change there. Then it is, it's much more the code to change than, than the content, right? Mark, why don't I, I'll send you my list and then you can refine it and pare it down. Some of it's probably really stupid or inappropriate. Okay. Great. Fine. Just a minute, whole timeline. All right. So back to Google season of docs. Any other topics there? Okay. Next topic then. Google summer of code. Here we've got, so we've got a project idea that was just merged proposing improvements to the pipeline step documentation generator. This is, this is the, the classic, wow, that's, that's barely usable experience for the documentation. So when I open pipeline and look at pipeline steps and then search for checkout, watch this page as it loads. So still loading, still load. Oh, it's loaded. Good. Fast internet today. Notice the number of expandable things there are here. Yep. And now if I click one, just one of those get SCM, it expands into this other huge thing with still more expandable things. So this, and this is already a dramatic improvement over the first thing that we release, we delivered with this kind of layout then. And this is apparently not even the worst example. There's been a connection. He noted that properties, let's see if I can find it. He said that there's another page that's even worse, this one. Properties, set job properties. So wait for it to load, spinning, spinning, spinning, still spinning, still spinning, still spinning, still spinning. Patience is a virtue, Mark. Yeah, well, still, still, still spinning. And, and apparently this spinning continues for quite a while. What it's doing is what has happened is it, okay, there we go. Page has finished loading. But notice just how long this page is with each of its expandable items. And so, so it's huge. So begging for someone to split it into individual pages instead of having this huge single page. Right. We need a map of pages for steps. This page, it was created for a human being or it's a script to generate the content. So the, there's a program that generates this page and all the pages of the pipeline steps reference. That's this pipeline step doc generator program. And what that program does is it iterates over every Jenkins plugin, loads the plugin, and then uses a reflection to see, is there a pipeline implementation inside it? If so, extract the documentation and writes it to static HTML files, which then are used here. So this page is actually static HTML, but it's static HTML that is generated by this pipeline step doc generator. And it is really useful use that documentation. The people, you know, the people are using that. There is some way to check using the Google analytics or something. There, there is. And we have, we have quite strong evidence that people are using it because here is the result that comes in from, let's go to this page. So if I go to a page like this one and scroll to the bottom. There is this link right here. Was this page helpful? Yeah. If someone clicks that, it asks for an answer. That answer is placed into this sheet. Now, where did the rest of my content on this page go? Because I'm missing. Oh, that's not helpful. Jenkins docs. Oh, feedback details. Sorry, I was looking at the wrong page. There, this is the one. So what this is, is this is a Google sheet that contains all the comments. So first comment started being collected in November of 2017. Most recent comment of 1,000, over 1,050 comments was today. Today, yeah. And, and it says, hey, I've got a syntax error on the build a multi-branch pipeline tutorial. Or here's the pipeline steps workflow. Yeah, but this links, it's from another page, not from the auto-generated page. Oh, no, no, that is actually from the auto-generated page. Oh, so here is this is that page. As linked there, and this is an auto-generated page. And a very common complaint is like this one right here. Please present examples. Or here is one where if we look, if we look at work, this one, it's not written or even formatted well, just seems lazily written. So there are all kinds of harsh comments that come into these things. But they can help us if we're willing to ignore the profanity and ignore the irritation of the we, we can actually still get, get better as a result of reading them. So for example, there was some feedback about six months ago about the get plugin. And that feedback motivated me to rewrite the documentation to be more useful. And it turns out that those kind of harsh comments have reduced now for that particular set of documentation. So it seems to have helped. How much do other plugin owners get this feedback periodically? Do we just send them a link and say you might want to check what they're saying about your docs? They do not. I've not been promoting this because, because some of it is so indelicate that I might get people saying, hey, that that is crassly offensive, please delete that sheet entirely. And there are some comments that are very, very offensive, right? There are comments that if I'd said those in my mother's presence, there have been serious consequences. We could go through and delete those or make a, you know, we could make a keep a copy of the real one and make a scrubbed copy and send it out to the pipeline maintainers. We certainly could. I think that's worth considering if we're willing to teach them how to do documentation for their plugin. One of the, I think one of the common outcomes here is, is for instance, it's very frequent to ask for an example. And the reality is they don't need an example. They need a pointer to the pipeline snippet generator. And telling them just use the pipeline snippet generator is better than giving them an example. Right. And we haven't written up anything about how you should document these. And we talked last week about RequireM. They have to create the HTML files that should be there. They can be stubs. They can be content free, but they have to create the files. Right. Well, and that's actually a good candidate for the pipeline. I wonder if we could consider that for the pipeline step doc generator or something else that would say, hey, we're going to propose empty spaces for your syntax. Now, I'm probably not because that won't be much better. My guess is unless the maintainers are interested in improving their documentation, which they probably are not by default, then giving them empty stubs may not help. Could we instead of automatically doing that for everything, would it be possible for us to create a script that for my plugin, I can go through and this will set up all the files I need and then give me instructions for filling them in and then give me a test suite that tests for whatever they can, but just would be for just my plugin. I suspect that it's a simple matter of programming and the basic outline is right here. Yes, inside this, the pipeline steps doc generator already knows how to load the plugin and detect pipeline steps and arguments to those steps. Therefore, I think what you're suggesting must be eminently doable. It's loaded the plugin, okay, therefore it knows the plugin. Inside the plugins palm is the URL to the plugin repository. So it knows where to find the source code and those kind of things just keep going. But I would assume that would be a month or more for a student to code something like that. Right, especially if we add a test suite into it. Yeah, okay. Sounds to me like an interesting, the right person would find that fun though, right? It might, yeah, I certainly found it interesting to discover what it means to write help for a plugin that's useful in the pipeline editor. Right. Okay, so let's see. We were talking Google Summer of Code. I don't remember why we got onto this example. Jonathan, help me. I've gotten lost a little bit. Oh, yeah, it's because I asked if you have some stats about the useful, if that page is used for everyone. Oh, right, right. Yeah. Actually, but that's an, oh, listen to me. No, no, go ahead. So you're just saying it's useful and the season, the Google season of code, it's about to improve how the documentation is just generated. But you say the pipeline documentation generator, it's based on reflection to get the data about the each pipeline. That's correct. Yeah, what it does is it uses the same techniques that are used by the pipeline help generator that runs inside Jenkins. And the pipeline help generator, what it does is it looks at all the classes that are loaded and identifies which ones have pipeline compatible classes in them. And then it can ask those classes for their information. Yeah, so everything comes through reflection. It's really complex way to get information. There is no some templates inside the template to generate the plugin where developers should put the documentation there to use instead of the reflection. There is no thing. Certainly, certainly there are standard ways of where you place documentation. There's this thing called the Jenkins, the Jenkins archetype. Jenkins plugin archetypes. Let's get this. And here on the creating a new plugin page, it talks about how you use Maven to generate a skeleton plugin for yourself. I haven't checked to see if that skeleton plugin has a pipeline help included in it or not. I don't remember if there is one that is just trying it now to see. I think that's how you do it. And it will prompt for which type. Oh, no, it did. Our filter doesn't match any archetype. That's too many. I don't need a thousand of them. I don't need a thousand of them. I don't need a thousand of them. That's too many. I don't need a thousand of them. Just a minute. That is odd. Maybe the filter needs a wildcard. I ask on that because in our last job, just to update into the documentation, we update some reading files from GitHub. It's really more simple than use reflection to create content. Well, so now I need to be more precise in my phrasing. The content creation, the file names are readily knowable and readily understood. Hang on just a minute. Let's do this and we'll look at it and see if it's got it. Okay, so let's call this my scripted pipeline plugin. Yeah, there we go. And so here is, oh, that's fun. This is actually a pipeline definition. Interesting. Okay, so that's not what I thought it was. This is how to use pipeline unit to write tests. But there is this concept of a Jenkins archetype and it will generate an empty plugin for you. And then there are places in that where when you create a new pipeline step, you place the documentation for that step in that location. So for instance, if I look at, I think it's called index.html, no help.html, we can see in the git plugin where its help is. So the help for the git step is in a file named git step slash help.html. The help for the git scm step is in a file git scm slash help.html. So the names of the files are pretty simple, but a very, very easily known pattern, but not created as far as I understand it by default. My ID, for instance, doesn't create those. I had to realize, oh, I could add help here and add the files myself. So did that, did that address your question, Jonathan? Yes, yes. So everything comes through, comes from the help.html file. Correct. Right. So if we look at that at this specific example, let's look at this one. Here is the one for the git step. It is just HTML and this text git step, it performs a clone from the specified repository is exactly what we see in this page. Git step, it performs a clone from the specified repository. So the content is extracted from the plugin, source code, and placed onto this web page. Oh. So when the documentations get the content inside the HTML file, there is purge and clean every HTML tag and create an others, or sort of just put everything together in one big size HTML file. You have that information? Yeah, I believe the static site is actually structured so that there is a page per plugin. So if I look at the pipeline steps reference, .NET SDK support here is a single plugin and inside it are several steps. And so I think it's static page per plugin. Perfect. Yeah. And so yes, we have data and yes, we get feedback and yes, the feedback is often, please give me examples. And that's why in order to address the please give me examples, I've done something quite different with the git plugin. No, let's go back to the pipeline steps. I started changing how I approach it and started sort of nagging the user to do things differently. So instead of giving them the example first and telling them this is how you do it, I said, use the snippet generator. And every time there is something about an example, use the snippet generator. And it gets naggy about that. The snippet generator generates this. And again, naggy, it gets very over and over again repeating, here's what the snippet generator would do for you, hoping that on one of them, they will see that and realize, oh, I ought to click that and see what that thing is. Maybe an interface, that button, it's just a button with means for us that the right user. Maybe a description side of the button, just saying how the proposal to use it. To tell you more. Yeah, because for example, I just imagine people using the system. They get in the system and see the text field in blank and a green button there. So maybe if we propose for people who develop the interface just to change the user experience. So remove the blank field and force the people to hit the button. Once they hit the button, ask them. You want to use the snippet generator or use a blank field. Maybe you force people to use the generator instead of search for help. Ah, interesting idea, so what you're saying. Yeah, it's because maybe it's a user interface problem. And not the, you know, for example, go back for that screenshot you just showed. So this one? Some minutes ago. Yeah, where is the green button? Oh, this one. Is that what you're thinking? Yeah, exactly. So for example, the people has a blank field and the green button. So the people see the blank field and oh, I have no idea how to put inside this field. So they go to documentation or go to Google to ask for help. So maybe if the people force it to hit the button and choose in between use the blank field or use the pipeline generator. So maybe we help them to decide to use the pipeline as a recommended functionality feature. Yeah, so the there's already something quite similar to that here where if I go into any one of these pipeline, pipeline jobs here on the left is pipeline syntax. But people because of the number of things that are on this left side and how attached they are to certain of them and ignore others, they don't see it. And so when they click it that this is now the snippet generator. And this is how they do. So the thing that I was describing earlier is this, right. And now when I click that button, there is my pipeline snippet. And if I say, oh, no, I would like to not include the change log. I would like something different. Those are all, yeah, all can be included in the change log or in the pipeline snippet that it creates. Yeah, it's really hide an option for people. Right, right. There are people that don't know where is the option. Exactly. And that's why the idea was, hey, start just shamelessly promoting in many different places, use the generator. I did something similar here in the in a plugin documentation page. And it's it's received. So I did something here where this, this image pipeline syntax with the get plug in is actually a link to a video on YouTube. And oddly enough, that video on YouTube has now received over 450 views since it was created just under a month ago. Wow. Wow. Sorry. What was that, Jonathan? You are in YouTube right now. 500 views. Yeah. So so obviously this is this is there are people who are willing to click it and watch it. And the the analytics on the thing are quite quite interesting. Actually, that's a that's a thing to learn here. I I've been impressed at how how helpful how helpful the the syntax is or the the analytics. So if when I click the analytics here, it shows me things about who's watching the video and how they're doing it that are just amazing. Things like, hey, guess what? The first 30 seconds get the most views and average. They they leave by about 50 seconds. So I could have done this in a minute and covered most of the viewers. So it's only 90 seconds and yet most of them are gone by 60 seconds or no, not most. Yeah, I think that is it. Average view duration is 50 seconds. And so by 60 over half of them have left. So yeah, it really is. It's it's a hint that, oh, there are better ways to get our message to people. And this this kind of data is is fascinating. It's a good indicator to that. Yeah, yep. So sorry for the long, long drawn out discussion there. Other topics that we should discuss in the last few minutes before we end. I'm good. One, I guess was on the Docs Roadmap Docs Roadmap review or inventory and review. And I don't have anything to do to anything to offer today and proposed doc structure, right? So where to put the existing content? This is the process that you had started and done so well for us prior to Hacktoberfest last year, Jonathan. From Wiki into. You want to create another inventory. Basically, yes, because the inventory that we did before was incomplete. It didn't include all the pages on the on the site. We've got more and we've got more data about those pages now. But about the the old week or we need to restruct our Genkzayo site. Well, what the proposal is, is that we we propose a place for every page from all doc sources. So including and go ahead and that topic about the use another tool to create documentation. Yeah, and you new platform to write down every the documentations that idea. It's not going on. It's topic. It's topic. You mean. Are you use another platform in our, yeah. A different doc generator. Yeah, is that what you're asking? So it's exactly. It's not that it's not going. Well, it's not on the roadmap for this year's focus. Do you have one in mind, Jonathan? Oh, there is several Meg and with yeah, and with new features, you know, for example, that could help us to to offer a better experience to readers. So for example, you have we can use tabs or previews to the pipeline generators, everything, but think some things that the our structure don't offer us. So I ask that because, for example, if now we create another organization for our documentation and move the page for the new place, we keep with the usability problems. So we just move things around, but the problems keep the same. And you're correct. For now, this this is not attempting to address site usability. It's it's not offering versioned support, right? It's still saying we only have a single version of the docs. It's not offering historical rousing of the docs. It's it's just intended on, hey, we've got this large body of knowledge on the wiki. As we're transforming it, where should it go? That was that was the idea for this inventory. That doesn't preclude that doesn't stop us from switching to another doc generator or another site generator. So a modern one. Yeah, I certainly know. I know organizations that have switched to Antora. I've had requests from people. Hey, would you consider I think it was Hugo others like that? So yeah, there are certainly multiple site generators available. And they seem to generally support ASCII doc. So we could retain the content in the adoc format that we've got and just switch which thing does the generation. Yeah, because if you choose a good one that accept ASCII doc, for example, we can solve two problems with the one action. So we can, for example, just planning, which is the better place for each page. And once we just map everything, we can. Okay, this is the new version of documentation. It's a new site generation. So instead of create everything, the old platform, let's create and move everything for the new one. So maybe it's a strategy to work with. And it's a good project for Google season of docs, for example, maybe in 2022. Yes, I'm used to season of docs being about the actual writing. Summer of code would be, I think, a good candidate because I think what you're describing a site generator is more programming than it is writing. Yeah, it's more programming to create the instance and put everything to work. But once we have the instance working, create the content, it's part of documentation in my point of view. Agreed. I was assuming that even if we switch to a different site generator that the existing content must be usable in that new site generator. Did I misunderstand? Yeah, because maybe you are syncing and migrating everything by script. So because of that, you are saying it's just about to do the summer of code. Right. Go ahead, Meg. Oh, if we were going to do this, first we'd have to decide which one we wanted to go to. How do we do that in an open source project? Do we have to let everybody vote? No, we just, we get to make those kind of decisions by whoever's going to do the work. And then in this case, I know I do not have the capacity to do the work because I think this is enormous. Switching site generator is huge because of how much code exists inside our site generator now and how dependent we are on it. I mean, I suppose an interesting thing would be to try a couple of, I would consider that actually something. We had three that were really close in the end result and one converted a lot easier. It'd be interesting to set up the main candidates and just take our existing content and throw it into it and see how bad it is. Yeah, that sounds like a very good evaluation. Yeah. And if, you know, that I guess, well, somehow we'd have to do whatever determines what order the files are printed in and stuff that's going to have to be a conversion, right, but yeah, I'm just going through the Antora conversion. And there's a lot of things that I'm fixing up because it looks nicer and Antora if I do it this way, but the old stuff was there. The information was there. It was readable. I just didn't like it as well. So, right. So are we saying we'd like to put this onto the roadmap for 2021 or 2021? I'm not ready to put it on the roadmap because I don't think I don't see where we would get enough capacity to do it during 2021. I'm open to if others say, ooh, it's going to be mine and I'm going to run this project for the multiple months to do it. I won't stop that. But for me, it's it's I've got I'm already feeling like I've got more on my roadmap plate than I have time to do. Yeah. So the most challenging thing in your opinion, Mark, it's just not to move only the documentation. It's because there is several things attached on the documentation side. For simple to create a generate content, automatic generate content, and several other routines, automatic, it's automatic that with this. Right. It's that the problem. Yeah. So, so for instance, change log upgrade guide, security advisories. And several others are all our data data driven portions of the current site. Yeah, and there is no chance to create for simple a separate instance just for the commutation and keep everything old chain old things keep going on instance and we have another new instance to the new documentation. So I think there's certainly a possibility. I just have a hard time believing that that would get us what we want because then we would have two old locations instead of we got one old location today. Yeah, and one that we maintain that the thing you're describing we now have two old locations and and something I would much rather make the change in place on www.jankins.io. Yeah, you're sure you are exactly correct. All right, I apologize we've hit an end and I've got to, I've got to write an upgrade guide for 2.277.1 and I've got to write a change log for tomorrow's release. Anything else before we close. No, and I was about to say that I had to go so. I don't need anything from me tonight mark. Thanks Meg. Thanks Jonathan. Thank you bye bye bye bye bye bye.