 Welcome, everyone. This is the Jenkins documentation special interest group. Let's get started. I'm going to share my screen and we can look at the agenda and talk through it and then go through the material. So on today's agenda, we've got report of previous action items. And I've put in a documentation progress status report, including a couple of demos and some discussion. Then developer meetups are a topic for this time. And then we'll look at some statistics on contributors and contributions to close out the session if we have time. Let's capture those statistics on contributors and contributions just in case we need them. And that's it. Oleg, anything else you'd like to be sure we include on the agenda? No, nothing specific. Well, one topic would be about Google Season of Dogs. But yeah, maybe we need more people to discuss it. And it's not timed pressure. Okay, well, but that's a that's a very good one. Let me put that. I'm going to put that down to the end right before the data report, because as we consider participation in Google Season of Docs. It needs a lot more preparation. Good. Okay. All right, thank you. Okay, so report on previous action items. I had created a poll request, but it was empty for Docs project ideas. I've closed that rather than spent waste time in the poll request queue with it. The idea that I've got is I'm going to map the pages and concepts from the wiki to Jenkins.io, then create tickets for those concepts so that we can then have anybody pick up a ticket as a newbie friendly ticket. And use that as a way to make progress on this. My apologies that I haven't done this yet. It's coming. Yeah, one thing I don't understand here is so for me newbie friendly documentation tickets and Docs project ideas were quite orthogonal. Because newbie friendly tickets are small tasks for those who want to just start and documentation project ideas were rather for Google Season of Docs and other bigger programs like community bridge. So they would have been rather about major projects. So both activities make sense, but I don't think that newbie friendly ticket. Yes. The thinking I had on that was that newbie friendly made sense for some of the tasks because they may be purely a transposition of content from one place to another and small tasks like that could easily be newbie friendly. It is a separate as a separate topic. It just for me it fit with if there's something on the wiki that is in fact easy to transform that justifies being newbie friendly. There are other things which are not easy and really are a major idea that won't be newbie friendly. Yeah, to understand that, but what I was trying to say that newbie friendly tasks are not Docs project ideas. Ah, okay. You're saying that those are too small to justify being a project idea should be a major effort. Yeah, so well, it still makes sense. It's probably just another action item because we need newbie friendly tickets. That's for sure. Yeah, so, but if we have a documentation project, for example on community bridge, then while we could take 100 plugins and say we are going to make a documentation project, but to be honest, I don't expect it to be exciting for whomever works on that. So I would rather not plan such project. Right, right. I agree. I think I think the concept I had for newbie friendly is fair for you to your observation. Your observation is accurate that, hey, that may not belong in a project idea. We just put up as part of our newcomer package. If they would like to contribute a documentation, they click through to the newbie friendly and they can get them. That's good. Yeah, I like that. Okay, so other gaps. Okay, thank you. So then as a regular action item and ongoing action item, I have a I need to I send out a summary of the doc SIG to highlight that for the governance. I assume that's still okay Oleg that I don't need to report those. The JEP we had agreement is okay or the governance board is okay just receiving a summary by email. So I think that it would be nice to have, for example, summary as a death list. That's for sure. I mean, for example, quarterly summary or monthly summary doesn't matter. But if you talk about bigger scope, for example, if you wanted to highlight all the work which happened since the beginning of the SIG, it might make sense to have a blog post. In my new year blog post, I just added some stats. But if you want to write, let's say a separate blog post about documentation SIG, I think it's a great opportunity. Okay, good. All right. And then we've we had the idea that we want to do a developer meetup. And I think I've got an additional additional idea for developer meetup that we'll talk about later on here. Well, correctly, Oleg, this the developer meetup, this one probably won't happen in January. It seems more likely a February or maybe a March topic. Yeah, it looks so. Great. All right. We have some regressions which are not related to documentation SIG, but right now we are not ready to deliver on that. Right. Okay, great. All right, then on to the documentation progress report. So I wanted to show a demonstration of the plugins.io static site. I am thoroughly impressed with how how much good and solid work Gavin Mogan has done. And what a wonderful piece of work this is to show to people. So, instead of a dynamically generated site, it's now static. So if I click here, here's the plugins index. And it was the page opens quickly. Now, if I choose some plugin, let's say mailer. There it found it and bang, it's up and running no generation process. This came from GitHub. It's been extracted from the read me as code. Likewise, we get the same thing with their plugins now that are allowed to have a table of contents. Like the get plugin now has this automatically maintained table of contents here. Thanks to it being an ASCII doc. So with config with documentation is code. We've got a much better set of documentation for plugins and the plugin pages load much faster. As far as I can tell our search rankings seem to be improving. We've got got good results happening. If we look at things like configuration is code. It shows a really elegant use of badges to highlight the progress of various pieces of the of the code so it's got a link to its code quality pages. It's got all sorts of helps for users. Now there's still more to be done. There's active discussion. Should we collapse these dependencies. How should we present but Gavin has done simply an amazing job on this. Any things that you wanted to be sure we highlighted here. All right, so then in addition to the progress that's been made on the plugin site. We've also we're in progress on migrating documentation for plugins from the wiki to GitHub so that instead of maintaining documentation separate from a plugin it's inside the plugin source code. A really nice plugin migration progress report that Gavin provided for us as well and that is now hosted on Jenkins.io. And delighted to see that we have over 200 plugins that have completed their migration to documentation as code. And several even in this top list have pull request pending that are ready to ready to go for the next release of that version of that particular plugin. To be specific we have around five or sorry around 50 plugins which have pending pull request opening releases. But we have some implementation issues which still need to be delivered. So I'll talk about it later. So the next topic by the way. Oh, great. Yeah, but right now there is much more than 90 plugins waiting. Excellent. Well, and I think that's good to talk to the next one. Why don't we go on to that next topic. Oh, like, oh, right. Oh, like, let's have you take on the documentation migration topic. Okay, just a second. I can't hear you like my back online. You are back online. Very good. Okay, so. Okay, let's keep our fingers crossed that this network is better. Okay. Okay. So I just wanted to add a few things to what Mark presented. I'll just share my screen. See, I think I have to stop sharing. There you go. I've stopped. So now you should be able to share. Okay. This my screen. Yes. So by the way, one thing Mark forgot to talk about to say about plugin site that the plugin site is also now mobile friendly because before that in the previous implementation, we had some issues with styles, etc. But now it was updated and it looks much better on mobile screens, which is important because now we can just reference links in social media and they don't look like crap. Yeah. And I am, I am delighted with the mobile layout. I think he's done a brilliant job with it. Yeah. So thanks a lot. Okay. Now let's go to the immigration status. So, as I said, what we have on the, the reason for that is that we basically, am I still online? You are. Yeah. No. Yeah, because in my case, it works just makes everywhere. Okay. So our problem is weak exporter that it pulls information from just from her code at the least of pain and cold requests. And for us, it's a moving target. So I spent some time this week to adjust the query GitHub and to find all the pending call requests. So what I can say that we have 24 plugins, which already have merged the documentation migration to GitHub, but which haven't been released yet. And 19 plugins, which have been a request and if you're maintaining one of these plugins, probably you would like to take a look. So, okay. So, and the status of those pull requests is reflected in the column that they occur in. So it's automatically updated when someone merges it moves that move something from left to right. I cannot automatically automate that because automation. Well, I will need to update it a bit. The default automation on GitHub for Kanban horse is to down. Oh, it does. Okay. Yes. So I will need to update it. But right now, automation is disabled for this book. So you have to look at this. More than a month of requests, which emerged. So I cannot. Okay. And I, I admit that the, the crucial thing here is when a change for wiki doc for to convert GitHub documentation from to to get a documentation from wiki happens. The merge is necessary, but it's not sufficient because we need to release of the plugin. And that's not a column that's represented here. Oh, well, there is done, which basically means release. For us, it's not a problem for moving from merged to done because wiki exporter. If you go here. It's for released plugins, it posts information from the update center. So when you take a look at this status, oh, basically this information comes from the update center. So it has some luck. But once you release a plugin in a few hours, it will be moved to bring status here. So you do not rely on this board. But it's rather for our information as documentation seeker. So that we can look here. See. We need some nice. Because. Yeah, that's what we have. And yes, we probably can start this migration, but yeah, the status for the most used plugins becomes better and better. And we know that all pipeline plugins have been migrated. They just need to release. So, oh, so we've got a and now are the pipeline plugins that have been migrated but need to release. Do they appear in your project board they do. Because I captured some requests. Maybe not all of them. Yeah, for example, here, change your roles for each plugin to point to GitHub. So it's for pipeline model. We finished declarative. For other pipeline plugins, I might have missed the pull request to be honest. So I need to double check because again, there is no automatic creation of this column. Because plugin maintenance just create whatever they want. We need to capture that somehow. And if I want to add things to this board, is there something particular or some propitious permission I need to be granted or as a contributor to Jenkins, can I already do it. As contributor to Jenkins, you can do that. So how I configured the board. Just so settings. No, I just edit documentation. I stick members. Yeah. It's not everybody. Oh, okay. Well, I can basically open the floodgates if somebody wants. But yeah, This is great. The people who are doing the work are listed there and can record it. That's, that's wonderful. Yeah. Okay, so let's go back. Okay. Yeah, so this board, well, basically is better than the implementation we had before, but it's still far from the video. Here you can just query things. For example, so how I do that, for example, GitHub. Yeah, I killed that. You can find some cool requests. For example, here there is a Google auth plugin, which is not listed. So we can just drag and drop it to this column. Yeah, so you can use more advanced queries to capture these plugins, but yeah, it's still a lot of missing, missing plugins. Yeah, moving docs from wiki security. So here, for example, we can see that the status is merged. So I just go to the pool request. I can see that it's moved. I can check the commit. Here I can see that this request has been actually released. So just has already been released yesterday. I just put it to them. So I don't need to worry. And yeah, you can see that, for example, there is pipeline support plugin. So one was referencing, which is missing. And here we can see that it was rated, but it wasn't released. It was released. So that's again, when you would drag into the done column. Nice. Yeah, right. So it's mostly clean up, but you can see that there is a bunch of such plugins. So whomever wants to maintain that basically what you need to do for automation purposes, you just drag and drop them to this column. Because the rest doesn't matter. It's just a history cleanup. Unfortunately, there is no good automation for that. So it was released. So they can. But yeah, it's not all process. Not the deal. But it gives us it gives us a very visual visual picture. Now, I assume that the wiki exporter report once they've released, they should also appear in wiki exporter. Okay. So Oleg, I think we may have lost you again. They released. For example, we know when support. We cannot release. You're breaking you're breaking up. So you said something about a support plugin released. I just said, yeah, I just said that we had the pull request, which we reviewed on the board. And if you go to the status, you can see that the status is green. Okay, good. So the so the wiki exporter is showing the correct, correct status as well when it's all the way to release. Good. Yes. So it doesn't hit any kind of dashboards on my directions. Eventually it will be there. So this board is rather for in progress pull request. Well, it's up to you whether you want to spend time on that or not. Right. Excellent. Okay. So that's what I wanted to say. And in parallel, I'm also doing some migration for non-plugging documentation to Jenkins. You said you were doing your back. You said you were doing migration of non-plugging documentation. Exactly. Because we still have a lot of other docs on wiki. I moved a team jack, I moved a bunch of governance docs and moving the remaining docs gradually. Sometimes we had to use advanced migration, for example, for governance board meetings, because it was just not sustainable to keep the agenda on the plugin side, et cetera. So we improved the tooling there. Okay. I can just show it to you. So here's for example, governance meeting. So now we use combination of static website and Google doc. But Google doc is embedded. So even if you don't have permissions to this Google doc, you can just go and suggest changes directly from the Jenkins IO page. So you don't really need to worry where this Google doc is located. You can find it here. So there are more such things, but it requires additional steps for the migration. So the work is in progress. Excellent. Thank you. And I know how much I've enjoyed interacting with that style of page. That's been a great improvement. Thank you. Okay. So before we move on, I'll just move it here. I'm not sure whether I'm able to show the next demo. So I can definitely show it, but with network stability, it makes sense to show it right now. I can try. Yeah. Okay. That'd be great. Yeah. I would love it. I put it in there specifically because of how pleased I was with what I've seen and how much it's made my job easier doing work on chainzlogs. Okay. So let's just spend some time on that. Okay. I can just do the demo from my laptop. Okay. So for those ones who is watching this meeting, there is a change log for Jenkins IEA. It's hosted here, but this change log actually has a machine readable format. So it's a change log YAML, which is hosted on Jenkins IEA. So I will just find it here. So there is, so yeah, there is a weak YAML file. This YAML file, it has fixed structure. So this structure includes references to issues, public requests, messages to be displayed, references to your fees. And actually there is additional, there are additional features. For example, we can put multiple references so that users can see additional information referenced. And you can see an example here. For example, we have removed and changed logs using this mechanism. And we're also working on referencing contributors. So if you scroll down to the recent change logs, you can see that the format expanded because here we inject authors to changes. And there will be more changes before it's really visualized on the Jenkins program interface. But at least there are some changes that every time you cut a release in the case of Jenkins, it's at least to be clear. Somebody has to create the full request and to submit this change log. So at the moment, it's Mark Wait who is doing that. Before that, it was Daniel Beck. Sometimes I was doing it in emergency cases because nobody likes my change logs. But the problem that somebody has to do that every release. And we also wanted to do some kind of automation for that because it sucks maintenance time, which could be spent on better things. Like the rating can be even full request. So in order to do that, there was a tool which was originally created by Daniel Beck, which is called the Jenkins change log generator. Basically it's a tool which was able to draft these YAMLs for particular versions. And it also supports LTS change logs because our LTS change logs are slightly different. And the most of users use them. So yeah, these two can also generate this kind of change logs. I won't be showing it today because it requires access to Jenkins Jira to pull additional information. And I don't want to expose password there. So yeah, no demo for stable change logs, but I will show weekly. So this tool was created by Daniel Beck, but historically it was quite difficult to use because it was a bunch of Ruby scripts, which wasn't running, for example, on my machine. I'm a heavy user of Windows and they were not running on modern machines, which were not using Bash as a default interpreter, et cetera. These scripts were still working, but they also had issues with the format because they were not representing the change log format strictly. So they required a lot of minor elections. And yeah, in November and later I spent some time in order to make that. So you can see that there are some releases. And now the tool operates in Docker and it also generates change logs, which are much closer to the final format than they used to be before. There is still a lot of things to be done, but at least everybody can take these change logs and just generate them. So let me show it to you. I am using official Docker container. So we have Chinese delivery configured for this repository. And if you need to cut a change log, you basically run it with your Bit Hub credentials, with Bit Hub in order to access the REST API to pull information about the request. And if you generate stable change logs, you also need access to Jira because our important metadata is actually in Jira, not in Bit Hub. It's something we could improve, but yeah, that's the current state. So I run this tool. I didn't pass version parameter and it will be just generating change log for the incoming weekly release. So basically based on all pull requests, which we have integrated, and the tool can also generate divs between versions if you need that or generate a change log for particular version. And here you can get this change log. So it's generated automatically. Here you can see that, well, basically there is a pull request. Fixed by JC, which was merged recently. It's a bug fix, references pull request issues, and it includes a draft of the message. So currently the draft includes pull request title. So similar like we do in release the draft of pipelines. And it also includes proposed change logs because Jenkins pull request template for Jenkins code also includes proposed change logs. So Jenkins CI Jenkins CI Jenkins. So we can just take a pull request. I haven't seen what's this request, but it's from Daniel and he followed the template. So here you can see that there is proposed a change log, which is the text which will be added in addition to that. So then when Mark or somebody who is a change log copy editor, he will just take this text and process it to the final change log. We can improve it later, but at least generate some stops. And it can also break down the change logs if needed, because the main purpose of this format is to actually supply multiple change log countries if needed. And it's a problem with release drafter because for release drafter you have to go to the peer title, modify it to include all the text, et cetera. Here we resolve it in a different way. It could be supported by release drafter, but it's just not supported at the moment. So that's how it works, but it wasn't enough for us because we also wanted to make it a part of a continuous delivery pipeline so that there is no automation, no even need for running that. And it will build the ideal to provide users for change log of incoming changes so that users can see what's going to land. Maybe on Jenkins.io or at least on GitHub repository. For that purpose, we don't have a tool at the moment. We didn't have a tool, and now we have a hook. The most of our repositories use release drafter. And for Jenkins, you can see that there was release drafter, which was again generating a YAML stuff, which is similar to what the core change log automation tool does. But yeah, it was generated by release drafter with a lot of hooks. Starting from the next weekly release, it will be reverted and now we generate user readable change logs. So there is a glitch and the change log gets duplicated. I still need to figure out why, but yeah, we'll fix that. Well, it's likely because of inheritance from the master file. But at least now there will be a markdown change log, which is released immediately after the weekly release. So you don't need a full request towards the master change log to be merged. And now it's also possible to see incoming changes. What we do, I spent some time to make this Docker container actually compatible with GitHub actions. It's not documented, but you can use it from GitHub actions and I will show it to you. So yesterday, Mark was grumbling about the Travis demo during the Jenkins seed meeting. Today I'm doing GitHub actions demo. Yeah, what we have, we have a simple pipeline here. It's called workflow. And it actually involves multiple steps. So it invokes a step for GitHub release draft. The one I wish you've already seen, it also invokes our change log generator. And then it invokes publishing. And for publishing, I first started publishing to release draft. It costs some issues. So it's not something I'm going to use at the moment. But we also have change log demo. So here I just inject the change log draft, which is generated by this tool in the artifact being generated by GitHub action. So what it means, if you go to actions, you can see that there is change log draft action, which has been triggered on every push at the moment. Later, I will implement support for tech pushes so that we can easily access change log for particular tech. But right now you can just see that there is a bunch of full requests. And here, for example, we have full requests for the last week here because it's a change triggered by KK. So for example, we can just go here and see change log draft generated for the previous release. So there is a bunch of actions and there is generate YAML change log. So what you've seen in my console, you can also see it here. But for real change log, here's a draft being generated on the GitHub actions. And after that, this draft is being uploaded. So I'm not sure whether it's available for this. Oh, like I think this one you picked was not the release from KK. This is one of yours. I think you picked one line below. Yeah, one line below because release from KK basically cuts the release and the change log for incoming release will be empty. Oh, I see. So you had to do it. Show this. Yeah, right. So that's why I want to implement support of text so that it will become more trivial. But yeah, I haven't gone to it and got to it. And here there is change log YAML. So again, it's generated by two. We can just download it. Unfortunately, it will be the same, but just in archive. So you can upload, download YAML, take it in, submit a full request to Jenkins.io website. So this is what we have now, what we can do later. We can automate creation of full requests. We can improve this formatting so that there is pipeline which basically delivers full requests to Jenkins.io. We also can add support of text so that it will be explicit where to look. And yeah, this is just one of my next steps for this generation. In addition to that, what we want to what we need to do for the next releases is to automatically generate update guidelines. We started doing some changes on that front. For example, now there is a new pull request template which requires people to specify update guidelines if it's applicable. So for example, here it's not applicable, but we can take full request. Here we have labels for that. Label, and here we have, we have too many labels. But yeah, great guideline needed. So there is a tag here, and you can see that there are seven pull requests stuck. And the last one is for example from Jeff Thompson for removal of agent protocol. The change that we announced for the previous speaker. And here you can see that we have a text of these proposed change logs. So we updated our review guidelines and now we expect submitters with breaking changes to propose update guidelines right here. So we can use the change log generator tools to generate upgrade guidelines. Well, not final ones, but at least drafts. So that we can have a page here and again mark this page. Oleg, your audio is breaking up unfortunately. Could you take that last, since you arrived at this page we've lost a bunch of your audio. Could you describe it again? Yeah, so what I was saying is that these guidelines are structured. So if you open this change log you can see that there are multiple entries. And these entries again, they're using machine readable format. So this guideline is generated. And it means that we can also generate templates for that. So let's take a look. I'm just planning to show one example. So... Yes, Oleg. Somewhere here. So my network breaks again. Okay. My plan is to start generating this as key dogs so that we can consume them later. This is just amazing. Excellent work. I am so pleased. Thank you very much. This is really great. Yeah. So we can call this to set out to Daniel Beck or something like that later. But basically it automates the work which Daniel was doing for years and thanks a lot to him. And now Mark is doing that. So yeah. Let's try to automate it a bit. Thank you very, very much. It's exceptional. I know how much I enjoyed. How much it has improved since I started doing it and how nice this tooling is. Looking forward to the tooling improvements that are coming. That's even better. Thank you very, very much, Oleg. What a great experience it is. Thank you, John. So I guess that's it with my demo. There is no people to ask questions. But if needed, you can ask in Gitter. Right. So the DocsIG has its Gitter channel available as well. So it's just quite active thanks to Gavin and team. It is. It's been very active. That's really great. Thank you. So next topic that I had on the agenda was Janka's Developer Meetups 2020. And one of the ideas that came to mind as I was looking at the configuration as code plug-in, I submitted a pull request to it for a minor change and saw a very impressive array of tooling that they automatically invoked that I had never used before. So yeah, I know how to use dependabot and I know how to use release drafter, but I've never used Codesy. I just started using Sonar source, but they also have an LGTM.com that appears to do security checks. And I assume there are other services like that. And my thought was it might be good for a developer meetup to bring the configuration as code team or others together to say, hey, here are some things that are available in the community, in the open source world that could help you do better at your plug-in development. Oleg, your comments, what do you think? Is that viable? Is that a reasonable thing? Are there other tools I should add here? Well, there is a lot of tools we could integrate because if you take a look at Jink's organization, there are around 20 different need hub applications which are connected mostly for different static analysis use cases or code style checks. So Codesy, Sonar and other tools that are just examples of these tools. And if somebody wants to come to the meeting and change information, it would be nice. Or especially if somebody wants to document guidelines about how to use these tools with Jink's plugins. Because here we have guidelines for these drafters, we have guidelines for dependable, well, in some sense, Google Doc, but not for other tools. So why not? Good. So good point. Can I assume there's a way for me to query and see what the applications are that are used and which plugins are using those applications, then I could potentially reach out to the authors, the maintainers of those plugins and say, hey, would you like to join us for this session and tell us how you're benefiting from this? Well, in order to get to the list, you have to be a GitHub organization admin. I'm not sure what you have. Okay. So I do not. I'm not an org admin. Yeah. I can provide some links. Actually, it's even more than 20. So yeah, if you just create an action item for me, I can provide this mapping. All right. So the plugins that use them. Great. Thank you. That feels like to me a very interesting, and I'm not sure we could assemble it in the roughly one week that we have prior to me going offline for about a week to do FOSDM. So I assume this will be a February or later developer meetup. But I would like that, and I'm happy to convene it. I would, I would love to moderate it and gather the people together. Well, if you need to meet up in one week, I could do a review of Dependabot because I have everything to run it if needed. So it will be likely a shorter meetup, maybe 30 to 40 minutes with all of the review of discussion, but I can do it next week. Yeah. And for the rest of the tools here, we can just start doing it in the background. This is after something we already presented. Right. That was done in a previous, in a previous developers meetup. So do you have a, do you have a, you would be okay if I scheduled something for next week? Yes. Great. All right. I will do that. First day of Friday. I guess Friday will be the best reason, the best day. Great. I will do that. Thank you. Okay. Thank you, John. All right. And then we had a topic on the Jenkins palm and bomb. And you had indicated there's probably some additional work there. It needs to happen development side before we host a meetup. So that when we let wait for a few weeks and let it continue revolving. Yep. Excellent. So yeah, then we do topic for dependabot. And yeah, probably I'll try to get somebody else to cover the JavaScript part because originally I didn't want to cover that, but we have some examples. So yeah, we can just announce one thing. So yeah, also I will cover Docker. That's for sure. Oh, okay. Good. All right. So, and that's one that I know how to use the Java one. I've never used the Docker one. So that's good. Java one works better. But Docker kind of works. All right. Great. Excellent. Thank you. Okay. Thank you too. All right. So Google season of docs. We are, we are, we are actually past time. Oh, like I'm prone to say that's shift Google season of docs till next week's meeting. We can talk further about it then. I did want to go over a brief look at the data from the contributors and contributions. Yeah. Really elegant. Thanks for your work on the time from pull request to engagement. We are averaging under 85% of our. Pull requests get some acknowledgement. Well within one day. And we just went on the latest bump to slightly over one day. But our, our. Output is really good. And the data from the whole clientile is very nicely in the one hour that the pull request backlog on Jenkins. I. Is looking really good time from PR open to merge. Likewise is looking good. We've merged six over 60 pull requests in the last month. And we've only got 11 open pull requests at this moment with 27 over 2700. That have been merged over the life of the project. really good. Let's keep doing it. Anything else you wanted to note there, Oleg? I think from my side. So yeah, one interesting start, which I posted in the New Year blog post in that we had 187 documentation contributors just during the last quarter. So it includes basically everybody who modified Markodon or SkiDoc files within JKSI organization and also within JKSI. So it's not an accurate number, but it provides some approximation. Excellent. Yeah, just for your thoughts. Thanks very much. Thank you. Thank you. All right. I'm going to go ahead. I think we're done. I'm going to go ahead and call this as a done session. Thanks very, very much for your time, Oleg. And notes are here. The recording will be posted to the YouTube playlist for the Documentation Special Interest Group. Thanks, everybody. Thank you too.