 So, recording has started. This is Office Hours for September 28th, Jenkins documentation. Let's take a look at the agenda first. Jonathan, thanks so much for your marvelous preparation for it. We keep conversion progress summary top item. This is going to be a great topic to discuss. And then I've got a brief topic on terminology updates with proposal for how we approach it. So, anything else that should be on the agenda? Mark, just wanted to, like, verify October 1st participation. Can we participate before September 30th or just on September 30th? We need to join. Ah, so, good question. So, let's put it as what are the rules, rules and how do they apply? So, that's good question. So, let's put that on the question list, Vlad, and we'll get to it. Good. Okay. Any other topics? Okay, let's take those then. So, let's look at wiki conversion progress summary. Jonathan, you want to take us through it? No, okay. That's my one. Well, I guess we have finished the Work Migration Issues Register. Okay. So, in summary, most of the issues from the spreadsheet were registered as an issue. So, it's near about 100 issues there, I guess, maybe 40, I don't remember. Yeah, 57. So, now we have a lot of issues to work on. Just about 31 issues, I can figure out the destination page. So, I put a link to map them. So, maybe someday you can help me to figure out. And so, these are flagged as waiters? Yeah, waiting is 3A, 3A is an issue. Okay. So, waiting... It's a red set, the filter. Oh, it is. Okay. So, the filter... On the state status column, it's saying waiting 3A is an issue. Yeah. Got it. Okay. All right. So, some issues are really old, and I can't figure out the destination, I showed the broken link to plugins, for example. So, for example, Line 130, all SWAPs depend on the check plugin. If you visit the page, the link is broken, and I can't find them on the plugin research page. Okay. Interesting. Yeah. So, shall we take a look at that one? Just I'm curious, because OWASP is very much used, but I don't know if this particular plugin may be a dead plugin that they've removed and replaced with something else. Maybe. Okay. So, you say that this link is just broken? No, there's OWASP. I swear, it was broken yesterday. Well, and it may be that the plugin site was having some issues. So, this looks like it's a redirect, and looks like the content is largely there. Good. Okay. Let's double check. Maybe they've already implemented documentation as code. Okay. Maybe another page is broken. I can't visit them again. Yeah. And they definitely have made the transition to documentation as code. So, this is a redirect. Nice. Okay. Good. Okay. So, let's back to agenda, please. All right. Okay. So, the next topic is we have, and the list below shows, I put the link there. So, we have 49 issues eligible to go to the first issue. So, I put the link for all of them. Excellent. And I've started through this list assigning the good first issue label. I'm doing my own triage checks as I've gone through. So, I'm right now, I think I've completed the first five, and I'll continue working on those later today. Exactly. So, there is a lot of issues to work on October 5th. Well, let's move to the next topic, just show what it is. Okay. So, and okay, here's the difference now between when we start to register and then August. And now, yesterday, I put another graph. So, now we have 30% of work done, and almost 40 available issues to work on. And then we can start another, follow another strategy to work with documentation. Excellent. So, describe again for me the distinctions that we're seeing between these two graphs. So, in the old case, there was waiting for an issue that was almost two thirds of the things, that large yellow two thirds. And that has now been reduced to just less than 15%. Exactly. And at the beginning, all issues was marked, but don't receive triage. So, no one can help us. But now we have the issues in the first triage and registered to another volunteers with us. Excellent. This is really exceptional, Jonathan. Thank you very, very much for what you've done. This is marvelous. Okay, so then this is a place where anyone else, so me or Vlad or Meg could consider working through these lists that you've already assigned, that you've already identified as good first issue, do another triage, yep, ready for the good first issue label. I'll work through them. Others are welcome to assist if they'd like. That's really great. This is brilliant. So, this feels like a great, a great thing for us to highlight if we were to do a Jenkins online meetup fairly early in October, to highlight how people can contribute to Jenkins documentation during Hacktoberfest. We could show, hey, look, here are the things that are ready for you. All sorts of great things that are here. We've guess we've got some few left that we need a triage still, but we have 100 and it's 157, right, wasn't it? Exactly. That's really marvelous. And now if I look at ones that we've already got labeled good first issue, this is not having processed all 49 of the ones that you had identified. So, this only includes five of those. Therefore, we'll add another 40 or more to this list of good first issues. Yeah. It's all the 49 issues. It's about a direct operation, but it's a good start for newcomers. Right. We need that work done. It's work to do. It's a valid poll request. Exactly. And the people have become happy when they help. So, it's a simple question issue. It's a simple problem to solve, but they can taste the, how it's valuable help others and community. Right. Oh, that's, that is really exceptional. Very good. Thank you. Okay. Anything else you want to highlight there? Any other, any other things we should be aware? No, just be aware to revisit the all the 49 issues, maybe it's like some exceptional content or, or modificate, modify the text as we wish. Mm hmm. So, I think that's a good question. As you wish. Mm hmm. Yeah, well, and just, just to give a, my, my, my technique as I work through the triage process. So, I opened this one and said, oh, okay, I'm going to change the description. Oh, no, this one, this one I checked and it's already done. So, I, when I click this link, it opens up to the same page that this one does. So, the redirect, I assume you or somebody else has implemented. So, I just closed the issue very nicely done. Yeah. Yesterday a, a, a, let's take the number here. Someone sent me a, a mail. Oh, yes. It should be, it should be connected in, I believe it's in Croatia. Yeah, I can't, I don't know how to say his name, but it's, it's speaking about the A-plugging. He was a work on, so he already sent the full request to redirect it. Excellent. Yeah, and that is, what a great outcome. That is a marvelous result. Thank you, thank you. And now, the, the Spinnock had also, had also pointed to the, see, there, there is a GitHub issue, isn't there, that tracks, tracks some of these things as in a different way. So, so that's, we've got additional opportunities for people to help there where even if it didn't reach yet into our list of pages to migrate, there are still plenty of plugins that need documentation migrated to GitHub from wherever. Hmm, nice. So, so you saw, you said to, to write the, readme.md file from plugins? Yeah, basically. Yeah, no, these are just, these are just plugin documentation as readme.md or readme.a.doc. Yeah. Well, but how exactly works the, the plugins, for example, the volunteer who wrote the plugin is responsible to documentation or not, the community need to stay there, document everything. Actually, it's, it's either. So that's a good topic. How about, let me put that one at the, towards the end of our session here, plugin documentation transition, because we may want to, may want to include that in the October meetup in the October Jenkins online meetup to remind people just how easy it is and how they can help anything else on, on our, on the marvelous progress you've made on wiki conversion. No, I guess I would, I would speak about that. Okay. Excellent. Thank you. Thank you. Wow. That is, that is an amazing piece of work. Great work. So I've got a concept on the next topic for terminology updates. So terminology updates. This is the conversion from master to controller, slave agent, blacklist to deny list or a better phrasing. Oftentimes we don't need to use denialist. We just need to say what we're, what we're blocking and white list to allow list or a better phrasing. What I did was I looked at, I looked for the word master in the, in the Jenkins.io repository and realized there are some references in the style guide and in contributing that we need to be sure that those instructions are ready before we point people to them. Likewise, there are sensitive documents like in the roadmap where there are references that we may need to, we may need to also correct those. We want to be sure that it's using correct terminology there, but those are not good first time issues and they're not places where we want somebody who's an experienced coming in to, to do, to make a change. But then there are some spots that would be good for a first time contributor. The multi branch pipeline project tutorial was high on the count of places where we use the word master. Likewise, creating a pipeline in blue ocean and the, and two architecting pages and then a number of pipeline pages. So my thought was each of these bullets would be a bug and it would be a huge issue in GitHub and then I'll list the file that they're to edit to, to, to make that change. This one had, I think it was on the order of 10 references. And so it's, it's enough of a change that it's not a trivial operation. It's not changing one word. And this one I think likewise. So now to, to the rest of you as a group, does that seem like a reasonable approach to attack this without to attack this? How do we do the terminology changes? So basically a USP it's not that just finding your place. It's smart. It's more than it as far as I can tell it is more than that because there are times, for instance, one of the things when I did my initial search, I just looked for the word master. And of course the word master occurs in a GitHub repository URL that refers to the master branch. And if they do a find and replace on that, they will break the hyperlink completely. I guess. I heard about the news. I speak in GitHub in the next days will change the master technology to domain. And, and I look forward to that change, but I suspect they won't take the, they won't do the very dangerous and risky thing of altering existing repositories. And if they did, I would be outraged. So, so if, if they did, I would immediately go change it back. Because there are just too many hyperlinks that depend on that that word master. So, but I can see them saying that for new repositories for new repositories instead of master will remain. Yeah, or ease some transition. Great. Good for them. But, but this is a place where. If we are very delicate, right? If we do wholesale replacement, we will spend more time. If we do mechanical replacement without thinking, we will spend more time for reviewers to fix problems than we gained by having people help us. Actually, it's a good point. I need to be sure that we teach them. And Jonathan, you were the good, the good example of this. The issue needs to clearly state. At the. They must not. Break existing hyperlinks. It's just not, not, not acceptable. We can't. We can't do that. We will throw. We will discard pull requests if they, if they do a wholesale search and replace without thinking, because it will probably break hyperlinks. Yeah, maybe it's a nice approach. Just the issues. And a road. Write something. Warning about the danger of changes. You are out. And so. Do a nice. Yeah, I'll review faster. So reject if you find something wrong or just. Ask for adjustment. Right. We need to try. Maybe a man in there can do everything. And they go down. With a good hand. Yeah, actually with, with those of you who are. I didn't touch settings with those of you in this meeting be willing to review a draft. Of that. Of that issue. You willing to review a draft of that issue. Proposing what the text should be. To text. And to others for review. To review text. And I guess you are absolutely right. Mark that it should not be mechanical or. Automated in any way because. There is, we need to say there is distinction between updating documentation or terminology inside the documentation and inside the code. So probably we should make a note somewhere. Saying that all the documentation has changed the new terminology. The code is. Right. More complex effort. Right. Yeah, I will. And there. It's, it's a point of conflict that was noted earlier. There are times when. The documentation is describing the current text. In the UI. And so the first challenge then is we need to go fix the current text in the UI. And then we can change the documentation. We don't want to confuse users by presenting. Documentation of something that hasn't yet changed in the UI. Good. Okay. So. Yeah. Besides UI when we are referring to. Let's see. Docker. Images sometimes were referring to them. They are named still. Some images are named. With all terminology. So it may be not. I don't know why, but you're all right. You I may be. Like. That's a very good point. That's one that. Inside a tutorial, for instance, if we name. If we name the volume. Jenkins master volume that we can probably safely change. But if they, if there's a risk that they persisted that volume and kept it for long term. Then I suspect we have to warn them. They may have to change the volume. They may have to change the volume. They may have to name this. Because they may have to do a transition for themselves. If they have that volume. They created a year ago and they're still using it. Now we've changed the instructions. Good insight. Okay. Any other comments or concerns on terminology updates? Okay. Next topic. Hacktoberfest. So Vlad, you had asked. Can we. Can hacktoberfest can treat contributions. For one October. I think that was your question. Yes. Yeah. Should we wait for October 1st? Or it's. And so contributions prior to October 1. Do not count. Towards. Hacktoberfest criteria. So. There they require. They were digital ocean. Only considers. Over one through October 31. It doesn't stop us from preparing. But, but they, they will. They will count. So. Four pull requests. From between. One October and 31 October. Did that answer your question? Yes. Absolutely. Mark. And related to this one. About. Specifically. Registration for digital. Ocean. A digital ocean. It's when they. Digital ocean. They mentioned this. Hacktoberfest. It's not clear enough. Should we do registration. After. September 31st. Be starting from October 1. Or we can register with digital ocean. Before. And that's, that's another good question. I thought that their rules allowed us to register before. Let's find out. Yeah. Because maybe some people already registered. Before. Should they register or use another. Right. And I thought. Let's see. So. Let's take a look here. Okay. To get a shirt. You must make four pull requests between October 1 and 31 in any time zone. Okay. To any public repo. So that we qualify. And now. Let's see. Now where was the. Maybe. Registration. Maybe in the same article. Oh, here it is. So it was, I think it is. We just click the start hacking. It will then ask me, okay, who am I logging in as. I am. A maintainer. In the US. I have read and understood the rules and values. I know those rules and values. Good. Okay. I don't mind receiving updates from. Okay, so it looks like it's allowing me to register now. So I would assume that they'll preserve that registration. Good. Good. And we've got. So they've got a facility now to help us promote. We've got to submit our request for. An online meetup to. To the Jenkins advocacy team. That's one I should put on this list. Sorry that I missed getting that into the agenda. Okay. So I'm going to start with. Hector over fast meetup scheduling. Was there more that you wanted to just address on this topic. Glad on Hector over fast and contribution schedule. No actually, Mark, you'll completely answered my questions. And thank you very much for clarifying all this is great. Okay. So we've got. And I hadn't seen this login thing. So that's. and they've got a counter. That'll be fun to watch. That's nice. I'm not sure how they know that I've done pull requests to arbitrary public repository. That's great. Okay. So does it mean that after four pull requests everybody can stop doing pull requests? Well, after four pull requests you qualify. I think a pull request to a public repository, at least for me, was almost infectious. It was so fun. It was, oh, wow, I just contributed something to somebody because I felt like doing it. And I got addicted to it and couldn't stop. And I think we hope the same thing for other people that they'll just become attached to the idea that they should help open source projects. Well, there is also a possibility, for instance, for somebody creating their own repository, not connected or related to any common project or Jenkins or whatever. And they can create different branches inside those repositories and create pull requests on their own and merge. Sure. And if you're that sophisticated and you don't want to contribute to open source, I think you probably deserve a t-shirt. Congratulations. You've shown a level of sophistication that's far beyond. Did you know they will send the issue by post posts? Yes. As far as I understand, they mail the shirt by post. Oh, nice. Yeah. And I think that's why it's been so crucial to them that they've got it presented by DigitalOcean and Intel and Dev. So they've got DigitalOcean as a hosting sponsor and Intel, the processor giant. And I assume it's very expensive for them to do this, but we're very grateful that they do. Yeah, really expensive because just four PR is so simple to do. So maybe everyone in the world gets a t-shirt. Well, I think they may have set an upper bound on how many shirts they're willing to deliver. But it was a very large number, if I recall correctly, thinking 100,000 or something. So at least if I recall past years, they had set some upper bound so that everybody in the world did not get a t-shirt. But this is, it's a very positive thing. Absolutely. All right. So since we covered that one, I've got one more topic here, Hacktoberfest Meetup Proposal. So Mark to submit to draft a proposal early October. And I say early October, it would be after October 8, because that's when CD-Con ends of the, the idea was we'll have Mark, Vlad, Jonathan present how to contribute to Jenkins Docs. Meg, do you want to begin on that presentation? Well, I don't know if my English is good enough for a large presentation. Oh, I think, I think your English is marvelous. And I think we should have you show some, at least show the graphs and the charts and the data that we've got. Yeah, you show how to create documentation and some VRs, some like that. No, I was thinking we will have you actually show how our process worked with these things. Because I think this is interesting and fun for people to know. I can do the part about, hey, this is how you do a pull request for documentation. Here's the demonstration. But I think it would be really great to have slides that say, look, contributing, I can, I'm Jonathan, I contributed to open source by helping prepare for this event. And here are the things that I prepared. No, I like a 668. Of course. Yes. Yes, that's what I was thinking. Anyways, you would say, look, this is what I did, not a demonstration, just I contributed by preparing these issues by reviewing them, by thinking about them. And that's a valid and helpful way to contribute to open source. Okay, so if I wrote a proposal, I need to send before each October. Each day of time, less opportunity to send a proposal. So what we will do is I will send, I will send, let's outline this. So Mark will send a draft today or tomorrow to Jenkins Advocacy. An outline. So an outline. And that will propose Mark, how to, let's see, let's do it this way. Mark, intro, Jonathan pairing the issues for Hacktoberfest. And then maybe we have Vlad creating a redirect or something else. Vlad, you tell me what you would like and then Mark transferring docs from the wiki. Or maybe Vlad, do you want to do a terminology update? That would be another good one. If you'd like to do it, hey, I'm going to do a terminology update and show a live terminology update. Yeah, you are talking about this meetup, which was scheduled. Well, I was thinking about showing the process of actually building and running Jenkins IOS site, starting doing make run, make build, starting your local machine, verifying that everything works. And after that, I'm doing like checking if your local fix will work and submitting this issue and pull request, this kind of the entire process. So people who may be new to the quantization may figure out how to do this. I like that. The reason for that is like some time ago, I guess earlier, summer or spring timeframe, I created the list of broken links inside Jenkins IOS documentation. Kind of simple, but it likes several hundreds, I guess. And somebody started working on that. And after that, another person wanted to work. But eventually, nobody continued working on this. And my guess, they didn't know the entire process, how to... It looks simple, like broken link, how to fix, but maybe they should be educated about the entire process, how to approach something that you taught me and everybody else at the beginning. Like one of the first sessions and it was marvelous job. I like that. That's really great. I like that a lot. Well, do you know when the time of the presentation, because I need to align my off time to be available? We can do the presentation at whatever time works for us. So if this time works for us, we could just do it during this time. It doesn't have to be convenient for the European. They can watch a recording of it. We can do it any time that works for us. Okay. End time, end day? Yes, absolutely. So if I look at calendar, I think my calendar says the 8th of October is a Thursday. So it would probably be the typical, we typically prefer things Tuesday, Wednesday, Tuesday, Wednesday, Thursday. But again, we could say this at this hour of the day and allow people to watch a recording later. Or we could push it earlier in the day and try to get people live. I'm open to either. Okay. It would likely be the week of October 12, because or we could do it the ninth, Friday the ninth. If we did it morning, it's not typically we get great attendance on a Friday afternoon at a Jenkins online meetup. That would surprise me. Most people want to be doing something different on their Friday afternoon. But so Jonathan. So maybe 13 or 14. It's a good day to you. Those would be very good dates for me. I'm thinking about it. I suspect the advocacy team will say, hey, if you could do it in the in the European afternoon, North and South America earlier morning, that would be better. Would that work for you, Jonathan? And Vlad, could it work for you on the 13th, 14th, or 15th to do an earlier in the day? Okay, I can handle it. Okay. So let's let me put a note on that. So October 13, October 13, 14 or 15, early, earlier in the end of European day would be okay. Part of America's day. Are there other topics we'd like to include there? I think we could remind people and I don't know who wants to do it, but terminology updates how to do it, how to. And what are some of the pitfalls, some of the problems and things to avoid. So maybe this topic is a good one to Vlad too, because after the assembly, the local jinx site, maybe you show how to do in the next day or the next session. That's a very good idea. Vlad, would you be willing to after you've shown them how to build locally and use it locally then say, and now we're going to do a terminology update? Yeah. They want to do this in two separate sessions or just one? I would prefer one myself, but go ahead Jonathan, sorry. I suggest separate because just maybe the first one, maybe long enough, maybe near to one hour to handle the house environment. Oh, good point. Yeah. Sometimes things go wrong, so you need to fix some on life. Yeah, very good. Okay. Very good. So first session, something like this, intro, preparing the issues for that for October fast, Jonathan that you present and then Vlad, building and running the Jenkins IO site locally. And then a second, a later session, another intro and welcome, terminology updates and transferring documentation from Wiki. Yeah, I like that. We as a member of Jenkins, we can participate and earn some shirts too or not? Oh, yes, absolutely. Yes, the pull requests you submit between October 1 and October 31 are absolutely eligible for the Hacktoberfest promotion. Yes. Oh, okay. Yeah, good question. And certainly I have my Hacktoberfest t-shirt from last year. I'm very proud of it. Yeah, I like shirt too. Okay. Okay. I think we covered that topic on the Hacktoberfest meetup proposal. So I will submit that today or tomorrow. Anything else on that topic before we go to the next? No. No. Okay. So last topic was plugin documentation transition. And this one, I think it's just a reminder that we need to remind people again, it's not hard to convert a plugin from Wiki hosted documentation to documentation hosted on GitHub. Anything else we need to discuss today? Just a moment. I look for a link here to ask a question for you. Just a moment. Okay. I sent the link of that on chat. Okay. On chat window. Oh, yes, right. And this one, this one, this page will take a while to load, but it's a fascinating way to highlight the progress. So it's going to load and show us progress towards the migration of over 1000 Jenkins plugins from Wiki documentation to hosting the documentation in GitHub. Yeah. I came across this page yesterday. So it's related to plugin migration or not? This is absolutely 100% related to plugin migration. This was the original page and process that started us on this. Gavin Mogan created this page and has been maintaining and improving it. And it's behind this page is the export tool that will let you input a Confluence Wiki URL and get back from it the converted page as either markdown or ASCII. It's a marvelous tool. Okay. So someone of them, it's okay and maybe means it's done. All right. So we need to work on it, too, or not? No. Another team at work. Nothing to be done. If it says to you that it's okay, then that means it's the documentation has been converted. The pull request has been, or the pull request was created. The documentation has been converted. The new release of the plugin has been delivered and is now visible on the plugin site. So for instance, if I click this, I think it will take me to, yes, here's the evidence that this page has been converted. So and to do this pattern, it's going to work available to do. To do? Correct. So let's go down the list here. So PR, this one says that the plugin has a pull request pending, which would correct it, but has not yet been released with that change. So if we look here, you can see the pull request has actually been merged, but there has not been a release since this pull request was merged. And therefore, it's not yet complete. And then if we scroll from... The plugin maintainers are the ones who decide if they'll merge a pull request. And Gavin is just extracting this information from the GitHub repositories. So here's actually a quite popular plugin, the X-Unit plugin, which apparently has not had even the pull request submitted yet. Yeah, but if you click on the link, it will write the points to the jinks that I know. So how do I need to be done? So what needs to be done here is if we look at this palm.xml for this plugin, we look inside of it and we'll see a URL. And that URL is pointing to the wiki documentation. That documentation is read only. It cannot be changed. And so that's not a place for us to keep documentation long term. So we need to transform this to instead use local documentation that's inside the plugin repository. Like, well, this one doesn't have a readme. So we would need to create a readme that contains this content that you see on this page. And the page content actually comes from, if I remember right, this page content couple mistake, comes from, let's go there, from this location. So if I copy that, open it. Yeah. Oh, whoops. Gavin's very smart. He's done the redirect. And so I have put an extra slash in there to get to the actual wiki page. But this content needs to be converted to be placed inside that. And a pull request then. And there may be one. That's what I know. Nope, there isn't one. Okay. This truly does not have a pull request yet submitted to correct the problem. Yeah, because I guess there's two ways to solve this problem. Change the phone XML or just point the redirect on page. And the both case you go to the right page. Actually, the there's no, there's no need to do the problem is not the redirect because the redirects already in place. Right, because if I take this, I take the slash away, it will take me to the plugins page. So the redirect is already there. It's that the maintainers that as a maintainers of this plugin cannot improve that documentation because they can't modify this page. So the pages document or the plugins documentation is stuck. It will never, never improve. Okay. And there is there some features that capture the content from Regime to Jenkins page? There is. That's that wiki exporter. So let's go look at that. So this one you see here, I'm going to copy. No, get from the GitHub. GitHub Regime. Oh, yes. That's, that's, that's a standard part of the, of the, that's a standard part of this plugins page. It uses GitHub's generation of the readme to create this page. Nice. It's because the X Unity has no readme, but to show the content in the same way. So someone put them and the hard codes, maybe it's the reason it's showing content. Close. What happened was that Gavin, this, this, the plugins Jenkins.io site for the longest time would copy content from the Jenkins wiki. Oh, what you're seeing here is it's copy from the Jenkins wiki. And so that at least presents to users something that's useful for the plugin documentation, even if it's not maintainable by the authors and by the maintainers. I see. Okay. So maybe it's a, a, a good next text to work after with migration finish. Always. Yes. Yes. Absolutely. There's still, there's still lots of work to be done on the transformation from here on this, right? There are still, well, 60%. Right. Gavin shows the nice data right up at the top, right? We've got 1000 to do and 500 complete. Yeah. Almost 60%. Right. And Mark, this list with Gavin preparing, I guess dynamically by browsing, retrieving information from GitHub. My understanding, this list of plugins includes both adoptive, already like maintainable, maintained plugins and plugins which are for adoption as well. That is correct. This includes all plugins. So it includes all, but relatively few plugins. So it includes plugins that are up for adoption, plugins that may have security issues, plugins, it may even include plugins that we're no longer distributing. I haven't checked for that. But, okay. And we have some statistics about the most important plugins to migrate in first or not. That's what this installs column is intended to help us with. Oops. And I just sorted to zero. So what it does is plugins with more installs are higher on the list and we rely on people to scroll down. And it's quite exciting actually to see how well we've done at progressing through these, right? The first time we reach a line that has no progress on it is at something with 21,000 installations and that is less than 10% of the Jenkins install base is using this plugin. So that's quite good. Yeah. Okay. Okay. Thank you for this donation. Thank you. Well, and that's a fun one to review. That is a really good one to review to show people, hey, there is a lot yet to be done and it's to be done in places that will help many, many people. Even a small usage, even one of these lower usage plugins is still installed at 18,000 locations. Right. Commercial software, 18,000 was about 17,000 more customers than I had. Exactly. So that's an awful lot that are, you can help by assisting with documenting these plugins. So yeah, that's great. All right. Well, we've reached our hour. Any other topics before we conclude? No. No. All right. Thanks, everybody. Okay. Thank you. Recording will be posted. Bye-bye. Bye-bye. Bye-bye.