 application that I submitted and shared with Oleg and you and other members of Mantras for Google Citizen of Docs team. I also was trying to first of all understand following discussion how our terminology is related to URLs. Because this is not, well, completely clear to me. For instance, if, well, in case of adult complex term for master, let's say, Jenkins server, how URLs will be dependent on this. This is something that, well, I don't understand and would be interested in understanding more. Can you describe a little further the places where you have a question? So I'm trying to understand, so do you mean URLs as in how do we refer to a URL textually? Tell me more. Well, it was part of our threaded discussion in Git channel for documentation when we discussed about different terms for master, for instance, and there was proposals to use something like Jenkins server, for instance, as a replacement for the master term. And there was not objection, but somebody mentioned it would mean that there will be complex term in URL, like Jenkins server, and this complexity is not easily implemented in the current infrastructure, I guess. And this is something that I don't quite understand and it would be interesting to understand how terminology is mapped and why it is mapped to URLs. OK. Yeah, so in that particular case, I think the concern was related to the ambiguity of the word server because oftentimes we refer to server as the computer hosting the process, or we might use server as the Kubernetes cluster hosting the process, or we might use server as the Docker container hosting the process. And those are relatively common uses of the word server in that case, and therefore saying Jenkins server becomes the way, and I think the respondent there was James Nord, the way he described it was, hey, that's quite ambiguous. It's not clear what this thing is, and so now we have to put a lot of extra words into every time we use the phrase Jenkins server because we would say Jenkins server and by this we mean the Jenkins process. Or Jenkins server and by this we mean the host name of the computer hosting the Jenkins process. Or Jenkins server and by this we mean the Java executable that's running. Therefore, his concern was, hey, that's just not precise enough. And what I think is a cool and a very positive idea from the terminology discussions is what if part of this made our terminology more exact, more precise? So Daniel Beck noted that if instead we consider two different contexts, one context is the thing that we called master, which was the Jenkins process executing somewhere. And the other thing that we called master is the node that is automatically allocated by Jenkins on the root server. So the root node is called the master node. And Daniel's note was, those are two different concepts. And we don't want people using the master node to execute much. We guide them specifically, do work on agents, not on the master node. But when we need to refer to the top level process, we call it the master process. Or we just call it the master. And so in both cases, it's a good chance to drop the word master and replace it with something more precise. Thanks for clarifying. And I would vote for more precision and terminology. I've got a few more candidates. I think this is a good trend. Yeah, and it's clarity. Clarity is helped, right? Particularly for, for instance, for non-native speakers. When we use ambiguous terms, it makes it even more difficult for someone to comprehend as they're crossing the language barrier, as they're making the transformation from English to whatever their common language is. So the Chinese, I don't know how they deal with some of our phrasal verbs. I don't know how they ever handle the fact that we speak so freely. We use the word get so often with an extra word over, under, get by, get through. And each one of those is an entirely different verb. So yes, there are lots of places like that where we, we can be much more precise and benefit not just, not just the local language people, but everybody with more precision. Did that answer it, Vlad? Is that? Yes, absolutely. Okay. Now, now you, you mentioned earlier that you had shared your proposal only with the admins. And I think one of the, one of the goals had been to encourage people to share it publicly so others can see it. Was it intentional that you only shared it with a narrow set of people rather than making it publicly visible or is it publicly visible? Well, I, no, I don't think it is publicly visible. I followed advice from a leg to dump it into Google Docs versus forms. And so now it is in Google Docs and I just shared with them like, yeah, with the team which is mentioned on our side as mentors and org admins. Great, I guess you included also. But just main intention is to get some reviews, comments and just suggestions to start discussion on this or to continue. Excellent. I also, well, wanted to mention in case this forum is appropriate, couple of weeks ago during similar office hours you introduced the spreadsheet which you put up together some time ago about different feedbacks to our issues in documentation. And there was long list of different issues. And I put together the two to transfer these issues from the spreadsheet into the GitHub, which is using not API, but Hub, something that you shared also. Okay. So, well, and I'm just trying to test this and not sure if it doesn't make sense to continue working on this. Is it advisable to create the tool which will batch create the entire list of issues? I would avoid batch creating them because many of those feedback items have long ago been addressed. So if you batch create an issue for something that was reported a year ago on one of the tutorials as an example, we saw that feedback, we acted on the feedback, we corrected the problem. So now if you raise an issue in GitHub with a tool, with a script, we will just go in and fairly quickly then close it out and be annoyed that you raised an issue that was already resolved. Now, if the tool helps someone to say, hey, I've looked at this and I want to submit this particular row as an issue, that might be quite interesting then. And good evening. And there is another problem with that sheet because some users use a bad vocabulary, let's say, it's not so beautiful. Beautiful is a very polite term for it. Some of the comments are laced with profanity and I would close them instantaneously if I saw them in a GitHub issue. Because as much as we talked earlier about master slave terminology, potentially offending others, I'm personally quite offended by certain English words that are used commonly in places where I find them disconcerting, right? So profanity is not acceptable to me and therefore I get involved very quickly on things like that. Maybe I overreact, but it's one of those where I get offended by profane language in my tongue. So yes, definitely if someone drops the F-bomb in a, or uses a profane word in a bug report, I will take all sorts of steps to fix that, including asking to ban them, those sorts of things. It's just, it's not acceptable. The community is very gracious in terms of its style of communication, its conversation and the contributor covenant actually covers that kind of thing. So we can't expect each other to be politely phrased. Sometimes you're right, Jonathan, the feedback comments are not politely phrased. They are not, they're filled with things that they shouldn't be. And so we intentionally discard or change them. Now, Jonathan, I believe you had done some processing of that sheet as well. Did you want to share some of the things that you had learned as you had gone through it? Because it's good that both of you have been looking at that. That's a great way for us to find out what users are thinking. Do you want to share more about what you had learned? Yeah, yesterday I shared my proposal at the group, our groups too. And there I put the links to a dashboard that I import all feedbacks. So in that dashboard, we can see by category, each one unhelpful to help me in media evaluations. And in the most of case, the user are asking for samples, yeah, video samples. And for more elaborate explanations about how to use the comments or to resolve some ambiguous terms, like you said, about the server one. And in a big picture, it's about that. More samples, videos and tutorials to help them to understand how the feature works. Thank you, would you be willing to share? Do you have the, is the dashboard available that you'd be willing to share the screen and show it to us? I think it'd be elegant to have a tour of it. I'm gonna let you share. Oh, let me, I might have that open just a moment. Because I thought it was an interesting idea, but the concept that we might get, for instance, I think you had done some data analysis to see what portion of the feedback was not helpful versus somewhat helpful versus, and I forget even the terms, but there's data there that I think would be good for us to see and consider. Yeah, it's very helpful seeing all in dashboard because you can use filters to show exactly how to see, just a moment, it's open. And just to push the button, share screen. Mm-hmm, right. And it should, if you've got a multi-screen environment, it will ask you which of your screens you want to share and you have to use a thumbnail to choose which one. Yeah, so I see the, yep, great. You're seeing? Yes. Okay, so can you describe the general areas of the page for us and some of the things that you learned while you were doing the analysis? Okay, the first one here, it's a account about the page that received more requests for help or more feedbacks, okay? So pipeline build steps, it's the winner with 18.6. So 10% of the requests were for one page and if you look at the top. No, it's not about the percent. It's about the units. We have all these requests. Yeah, you're right, it's percent. It's percent. Well, I was just fascinated to see that if we take just the top five that you've listed there, we've already covered about 20% of the feedback on five pages. So, great. There is another point that you, it's about the one kind of feedbacks from users. They not like to long page with the commentations. They prefer small sections, okay? Because we don't have a search bar. So it's not so easy find things in long texts. Yeah. And one of my proposal is find a solution for a search bar in a week to help them. So the most you can click here to apply a filter about the not that helpful questions. It's our account here. And every change here when I selected this option, you can see here to a, just a point. So here we can see all the suggestions, requests, provide the full options for each field, provide which kind of returns and move on. Here we can see a timeframe. Which a period receive more and low requests. So our more activity, it was this month, April 19, and that space here, and you can, for example, click on them just a moment. You can see which requests. So I saw it on the step gauge, indicate it supports H2P or SSH, that's it. You need to waste some time here to read each evaluation about the users. You can use the filter to get the most important one. So you can click here, here, here and here and get the top five requests for users and work on it. So for example, .NET sample, all the sample here, it's the feedback asking. Maybe we can find the bad words here. Yeah, probably will and that's, yeah. Okay, so it's a open one. I put the password and user to, you can access the desk board and use for you. You won't use, have no problem. It's open. Excellent. Thank you. Very nice. Thanks very much, Jonathan. Yeah, that's quite, so it looks like there are some high-frequency areas and they seem to be, okay, pipeline build steps. So pipeline, three of the tours. And that truly amazes me because three of those, I'll have to double-check, but I think those three tours are now all functioning, but they were still high feedback points. And then the get plug in, okay, I've tried my very best to fix that one. So that was one that was laced with profanity. Absolutely, there are lots of things where people said, I want this, give me examples, give me, and so I wrote examples and they've been posted and they're now part of the documentation. Now, actually for my benefit, could you zoom in on git? I'd like to see if, look at the timeline on feedback on the git page. Feedback on the git page, just a moment. Git page, there's one? That one, exactly. So when you click that row and hit the green check mark, that narrows the result? Yeah, yeah, narrows the results. Okay, and so what that shows is the rate of feedback over time has decreased compared to, so we were getting, it looks like, two or three per time period for quite a while and for the last four or five months, we've been down to one, except for one time when we got two. Okay. Exactly, and our AVG, it's about two feedbacks per month. Okay, so now can we, and you can see the individual suggestions. Yeah, it's here, you can just open here. Now we have two fields about the suggestions. It's all here. More descriptions, it's like the same. Excellent, okay, great, thank you. Yeah. I have a generic question. Oh, go ahead, Hunter. Another important point, and I believe that our docs, it's right for more experienced users. So we need to write in a new way to embrace the new ones. For example, it's here, it's a exactly example, good example. For a beginner would be good if they're at least small samples. Maybe because we have a lot of experience in our career, it's easy to read and understand the topics or the main concept about the genks, okay? Maybe we need more beginner samples, maybe. Good, thank you. Meg, you had a question, I believe, go ahead. Yes, I'm just curious that these, I remember when we put in the ability to add feedback, do we ever respond to those so that if there's a comment in there and then we go in and change the stuff, do we make a comment that we think this has been fixed? We really can't because the sheet is right only. So the process that maintains the sheet appends to the sheet and no one but that process has permission to write to the sheet. And we intentionally do not show the contents of the sheet to anyone because the content is completely unfiltered and has no safeguards on it, right? Okay, so anybody posting a comment does not know what other comments have been posted. That is correct, right? There is no hint, there's no maintained public display of the contents, comments for a specific page other than in this sheet. So the sheet itself, and there's no, and I think that's a healthy thing because I don't really want Jenkins.io to become Stack Overflow of the site or a moderated chat system. That's not what it's for, it's a documentation side. Maybe it's something in the back end though, it would be as I can see like five years from now, the comments that were received and are no longer relevant are gonna show on the same list. We don't have a way to fill their out with these even internally. That is correct, but I think long-term and it's already, the transition has already actively started. Long-term we will switch more and more people to give us GitHub issue reports for their problems or the page rather than submitting to this feedback. So, Jonathan, I'm gonna stop your sharing and I'm gonna bring up the share of mine so that we can look at what one of the pages look like and see the different ways that people can give feedback. Okay, so do you see my screen that has a pretty background, the Jenkins page? Yes. Okay, great. All right, so on these pages now, so let's go to, let's see, it was pipeline build steps, wasn't it? Was the high noise page. So let's see if we can find pipeline build steps. There it is, and oh, it's glory. Oh, where is it? Let's see, so. It's here, smart. Yeah, exactly, build steps. Actually, and it may be that I have to go here. Oh, under resources, there's a link to steps reference, I think that's it. Down at the bottom on the left. Oh, there we go. Yes, is this, well, but Jonathan, could you look it up again for us? Tell us what the page was that was the most, it wasn't steps, I think it was. It was pipeline build steps. Build, okay, so pipeline build. So let's, okay, so I am showing clearly that. I will put the link to you in our chat. Oh, that'd be great. Thank you. Just a moment. Here is the most requested one. And it should be in my chat system, which I can find shortly. Where is the chat? At the bottom, it has a high icon, middle bottom. Yes, I think I have to stop share so I can find it there. Okay, all right, there we go. Now I got it. Oh, yes, yes, okay. And this one is a good one to give feedback on. Well, yeah, let's, okay, I'll bring it back sharing coming soon, just a minute. So share screen, share this screen, go. Okay, so you should see pipeline build step. Yeah. Okay, so, and the elegant and really positive thing here is that this page is assembled from a whole set of, from the entire pool of Jenkins plugins that contribute to this step. So what we see is things like list get branches, which is completely unrelated to matrix combination parameter value. And therefore, yes, it's this thing is complicated and dependent on each plugin having good documentation that then gets contributed to this thing. So this is a step which generates a build. And now each plugin that can contribute to it has some piece. So for instance, the clear case UCM baseline parameter value has that or Boolean param. Yeah, so I can understand why their feedback on this page would be, but now what are the? The wiener. Yeah, yes. Now what are the things, the places where they can give feedback to us was this page helpful that opens up the form that takes them to the data entry form for the spreadsheet. So this will put data into the spreadsheet and this should open the sheet to show me, okay, here it is. Yeah, it does. Now, what we've got instead on pages that are not generated like on, let's go to installing Jenkins. So on installing Jenkins at the very bottom, you'll see was this page helpful, but we've also got improve this page and report a problem. And if I click improve this page, it will take me to GitHub and I'm right in the source code of the page. So that's, if you wanna help us improve the page, here's your chance. Now, if I instead click the report a problem, it takes me into GitHub issues and now I'm ready to report a bug. The reason that the build step does not do that is because in order to fix a bug in the build step page, in order to fix a bug in actually any one of these. So, but in the build step page, we had it here. In order to fix a problem in these descriptions, I have to go to the plugin that's contributing each of these sections. So if I wanted to fix package choice parameter value, I have to find the plugin that contributes this, this description and then take you into the missing help file that would tell you what that is. That was a long description for the three feedback techniques. Sorry about that. Okay, stop here. I wonder if at the very least this page should have a brief, it's sort of implied that up at the very top, but to say that this is generated from these. Well, but see, my worry is I don't, I wouldn't want to distract the reader from the this is generated rather the thing that does the generating, it would be best if it could create links somehow inside the page that say, go here to fix this page. So here's the link to the plugin on the plugin site. And so this tells me which plugin repositories contributing the root description. It's just contributing this, but the tooling iterates over all the plugins and gathers from them, the places where they contribute things like deploy metadata parameter value. Right, but this is really a page for experts. And up at the top of the page, it does reference them to the other steps, reference page, the first one you had, but that's really buried. I have to really go looking for that. And I'm thinking that a lot of these that want more examples and stuff, it's like you shouldn't be on this page, you should be on that page. All right, right. I see your point is, is that if we could somehow guide them, you're in too deep. You are reading the reference page for a minute technical detail. What you need is this other thing. Good, yeah. And the information is there, it just doesn't pop out at me. Right, right. Ballad, yeah, good point. And to solve this problem, I like to learn with others projects. So for example, we have another groups that build the commentations that is useful for beginners and you are dipping dive into, dipping into and the big more complex, but just if you want, we not start complex. We not start with complex samples. For example, you see, you saw the website, hugefi.com, you can open it. Sorry, what was the website again? It was? I will put in the shot. Oh, good. All right. Just a moment. It's a good sample of the docs. Well, Jonathan is looking for this. Yeah. Okay, it is. Okay, so... Click and at the button, get started. Okay, get started. Okay. Uh-huh. So it's the documentation page that you can use the search bar. For example, I put a grid, grid, you'll see the suggestions. Click on the first one, please. No, we start with the search bar. Please. No, we start to show the basic sample for the more complex one. So, have some links and history about them. And more, you can see, preview step by step. It's a modern way to show recommendations. You can show to the user a playground section. Oh, you say there is a... There's a playground section on this page. Yeah, yeah. Oh. Yeah. So for example, change the options. You can, it's responsible. Yeah, the dropbox, okay. It's just a sample. So for example, you can create small labs, use Docker and guide the user to use our containers to try our suggestions. Interesting idea. Yeah. Yeah, you put our image, build the images in Docker Hub and point the user to there. They Docker pool the images and use our labs, just for learn how things work. Yeah, that looks very interesting. I like ideas like that. That sounds cool. Yeah, you may not reinvent the real, it's a common term. We can learn with others. So, and is this site a static site or is this being generated dynamically? Is it possible to do this kind of thing in a static site? Yeah, it's a stacked site. Use a NUXJS or if you were going to active NUXJS and you can use GIFs or another kind of interaction with the user. But it takes time to develop it. They develop it. Yeah, this looks like a really cool idea. So it looks like we can see their source code on GitHub. Yeah. And you can use the Github and you can use the Github and go back to page, please. Come, go. And the first icon. That one? Yeah, the next one. Oh, okay. Yeah, you can use another options to see the code to interact sometime. And so what this is providing is some sort of online editor that lets me actually do editing right here live. Yeah. So if Jenkins has some kind of functionality like this, we can use too. You guess it is similar idea to W3 schools. What they have on the website. It's similar. Interesting. That's fascinating. And you click on the button of pre-grout but if go back on the page and scroll down some sections. First of all, use the bar search tool again and find for cards. Yeah, click the first one. Use a section. It's another kind of playground. You can roll out. So you say the usage section is another, is a place for it? Playgrounds, you can see. Oh, okay. So if I look, whoops. Yeah. Yeah. So you can use, you can stop it. Oh, okay. Okay. That's one. So you can use the GitHub icon to see the code on GitHub. And the last one is to see the code in the same page. Mm, okay. So you just only see if you want it. So do you envision that this might be a, this kind of technique might allow the reader to then experiment with different ideas for pipeline execution on something we're hosting? Yeah. Yeah. So it's just an idea to work with more options. You offer our use more samples, more interaction and a modern way to learn about things. For the pipeline stuff, I don't know how you'd make this work, but into the, oh, the snippet generator or what's the declarative, something or other. Yeah. But those tools that we already have, you know, this would, if you could, if you're looking at this step to click and see what, because there's a certain amount built into those to help you create the step you want, right? There is, but the challenge with those is, those are truly on an executing Jenkins instance. And my hunch was that the project is probably not ready to fund an unlimited number of Jenkins instances, even small ones running for purposes of teaching. So it's, but I'm fascinated by the idea. So this really is showing static pages that are highlighting different capabilities. And then the question is, could we do something similar with static pages for the Jenkins documentation? Interesting. Maybe some intermediate idea maybe instead of like doing this very significant development efforts, allow users to know how to search within page because my understanding based on Jonathan's feedback that many users don't know how to use control F for instance to search. Right, right exactly. And so a search, putting a search box onto our pages already might be, might be very, very well received. Yeah, it's the control F options, just looking there in that page, not entire documentation. So that's the main difference. When we are reading the documentation, we don't know yet in what phase it's that information to look in part. And talking to Mark, your previous page, which you addressed with all which is generated from all different plugins, in case it is possible to not collapse but expand all these different steps. I'm not sure how significant this effort is. And the use control F, the users will be able to switch within this large dynamically generated. Well, and to note that, the page originally started with everything expanded and the users were quite vocal that this page is unacceptably long. And this page is actually a small page compared to, if we look at, I'm gonna terrify everyone now by loading this page, the checkout step. Let's do it in a separate tab because it takes a while. If we load the checkout step, it's, oops, let's find the right page steps, but it's huge. It makes the build step look tiny. It's so big. Check out, check out. All right, so here's the general SCM and while we're sitting in this meeting, just wait, we'll watch and eventually this will collapse itself. It will collapse itself when the page has finished loading. The page will finish loading two or more megabytes of data into it. So it's, and you see the list, the list of SCM providers is probably 50% longer than the list of build targets. And each of these things has, let's expand this one, has a huge page of more expandable things. So absolutely, there's gotta be a way to do this better. And Jonathan's idea of making it somehow more interactive, more searchable, more comfortable feels like a big win. So Jonathan, using that concept from Viewtify, for instance, seems like they've got shorter pages, let's leave it as a grid, although they aren't terribly short because as I look at them, the scroll bar is, there's plenty of content about grid there, but then they allow people to search and find a page focused on the exact thing that they're seeking. So I might type get SCM and find just the get SCM page. Yeah, a lot of projects I use these templates to out the documentations. For example, Laravel.com, it's the other example, Flutter.com, it's another Google sample, Flutter.com, yeah. No, maybe not that Flutter Google. Oh, okay. Maybe in Google, you can find the... Oh, I see what you're saying. So I see, so if I do a Google search for Flutter, beautiful native, oh, Flutter.dev, okay, got it. .dev or ..com, okay. So you'll see the link docs at the top. You'll have showcase shoe, it's another sample. Yeah, that we starts to click on the small links to get complex, the API docs, it's another, in the middle of page, the last options, all right. Oh, here we go, got it, okay. Yeah, yeah, all right. So the Mac complex sample, you can use the search, I add docs to search bar. And the, oh, search is up here. So if I look for import. And there it talks about import or... We'll receive suggestions. There, under the API, there is no installations, but in the previous sections, you can find the installation type. Okay. Get started, person, the middle of the, yeah, get started. So you can choose your operation system. Which operating system I am and down. Yeah. And so move on and get your information. It's different, but use the same way, pathway, to get your information. It's similar. Excellent, thank you. Okay, and I'm gonna stop sharing. So are there other topics that either of you would like to address or other topics for discussion? Well, just I wanted to, oh, go ahead. Please, Vlad, continue. Oh, thank you. Well, thank you Jonathan for sharing this. I just, I wanted to ask you a period about doing something general for the entire documentation related to frequently asked questions. We have FAQ for specific sections, but during our discussions online in chat rooms, for instance, Mark is very often answering very interesting questions, providing answers. And I thought maybe it makes sense to collect all these different topics, answers, questions, and start creating general FAQ section for entire using of Jenkins overall. And so I'm not sure yet how to organize this, but maybe it will start to cover in the entire, all different aspects of using this system tool and so. And I think the questions that are asked are an interesting source of data for us to gather and consider what should we put into the material. I don't think we would want to become a stack overflow, but I see no reason why we could not mine or gather for good questions from stack overflow and say, hey, look, here are these questions, collect the questions, group, sort, shuffle, categorize them and say, hey, if we had wanted to answer that question on Jenkins.io instead of stack overflow, where would we have put the documentation and let's do that? Because there are excellent question and answer sites already out there that are impressively populated with Jenkins answers. If you look at the stack overflow, Jenkins tag and the Jenkins pipeline tag, it's amazing the number of questions that are there. And at many times it's a question without an answer or a question with a very deep and involved, very, very thorough answer. So good point. I'm not sure that FAQ is the way I would frame it personally. I was thinking that it would be more of, hey, look, here are these questions that are asked. I think our goal should be to make the answers already be available in Jenkins.io so that we could point them to the answer in that page and say, here's where it answers this. That's what color this. Right. And there are plenty of things where we don't yet have an answer, right? So there's lots of research that would be needed or lots of find the most interesting, the highest, most popular questions on these Q&A sites like stack overflow and then from there, apply, provide the answer in our documentation. It's a good idea or anything there. And do you think, Mark, we should put reference to our site or on the site where this question is asked? Like for instance, in case if question is asked on stack overflow, we should point them to Jenkins.io. I think that's perfectly reasonable. Absolutely saying, hey, here's this. One of the dreams I had was that the day would come when most answers in the Gitter channels would be links to documentation. We're a long ways away from that, right? Now, we're a very long ways away from that, but many questions come into the Gitter channel, particularly from brand new users where I just started using Jenkins and if they're already having to ask a question in Gitter, it may indicate something's missing from the documentation, either in its search ability or its content. Mm-hmm, and Jenkins, mm-hmm, go ahead. And Mark, what do you suggest to us and the next actions? For example, we share our proposal now. It's open to receive suggestions. Thank you, Vlad. I saw your corrections there. You send the, thank you. Oh, just like, yeah, I reviewed them, and just then provided simple suggestions about. I appreciate it, thank you. And, but in the next week, so what do you suggest we do? Just keeping studying that issues or improve some text, what do you suggest? So for me, I think continue contributing to the project so that you get a sense for how does the project work? What are the things that will help it? You might now, because we're tending to run out of the initial set of tickets that we had created for transformation, it may be time to go into the triage page, the triage spreadsheet and start looking at those things and doing some triage. So check out a page, look at a page, decide where do I think this might go, create a GitHub issue which says, transform this page to this location, and then you could assign that to yourself or put a comment there that says, hey, I'm working on this and start to work on it. I hope I'll get some time this week to triage a few more pages in so that by the end of the week we'll have some additional material that you could do the triage almost as well as I could, particularly given that you've both had time looking through the documentation. So you've got a sense now of where things are described and where they're not described. So I'd suggest take triage, triage one or two of the existing Wiki pages that haven't yet been transformed and choose one that's interesting to you and start transforming that by creating a GitHub issue, then comment on the GitHub issue, I'm working on this and then start the transformation. Okay. Well, thank you very much. I think we've nearly hit our end. If there's any final question before we close this hour out, the next office hours will be Thursday about eight hours or nine hours prior to this session. So it's Thursday late afternoon European time with Oleg Nanashiv. Okay. All right, thanks everybody. Thank you very much. Thank you. See you.