 Alright. Okay, so welcome to the Jenkins contributor summit October 9 this is the unconference session focused on Jenkins docs without the wiki. And what I was thinking we should do first is let's talk about the current state of things, what we've got today. And this will be, there'll be some parts that will be sad parts that will be depressing parts that will be positive, but we at least understand and talk to each other, make notes in this section about hey here are the challenges that are ahead of us. The things that we have right now where there are issues. And then we could talk briefly about what's in progress. So we know, hey things are already improving and then what are the alternatives and next steps. Levi does that sound reasonable to you or is there some other way you'd like to think you'd like to see it approach. Yeah, that makes sense. Okay, great. So, so then let's on the what we have today side. Jenkins.io www Jenkins.io is the primary documentation site and it's, it's doing reasonable job of having that it's got sections on installation sections on managing and on securing it's got sections focused on development and on developer guide and on tutorials. So those that that is at least it's a gathering place it's got syntax references and upgrade guides and all sorts of things like that. So, so in that case, however, it also has many broken links to the wiki dot Jenkins.io. So when we look at places like in the developer guides, it's quite common for something to say, Hey, let's look at one here's the architecture page prior to, prior to work that's happening in October Fist now big section it says work in progress, and, and, oh, and here's a link to the architecture wiki page that when we click it it will blissfully 404 because there is no server wiki dot Jenkins.io anymore. So, so those are the kinds of things where we've got lots of pages that have links to now that that page is actually we can find its HTML representation now we've saved its HTML representation but it's not, not directly linked to that location any longer So, so page they're incomplete pages, and that page that I just referenced is actually stored on this confluence data site now as static HTML under Jenkins slash. Let's go get it should have just kept it that way, because it it helps at least for me to describe this process so that we people can see. The information is not completely lost, but right now, it's not in a format that is usable or beneficial to the to the reader, we've, we've lost lost access to a convenient access to it because of the the attack that was that happened to our Jenkins wiki. So if I open that link and the page it links to is Jenkins slash architecture so here if we go to Jenkins and we look keep going down and then architecture. Right here, architecture so notice that it's architecture underscore 753 some some number. And if I view this page. What's the easy way to view an HTML page from. I know there's a way to present that to me in how sad I don't know my GitHub driving nearly well enough obviously to show show this page as in the browser. How can I see the raw content. Oh raw. No, that will not help me because that really is raw. Sorry, so there is this the content is here, and we could use it. And it's it's actually readable. It presents, not not terribly badly. What it doesn't give us is a convenient location to reach it so problem. One of one very early problem is we've got them stored but we don't have them rendering. So it's a massive problem plugins Jenkins that I owe is is a really strong place for our for our locate for our, our plugin documentation, and it's it's working great. Gavin Morgan has done a wonderful job of making this thing very effective very useful and very usable. He and spin it connection he have made great progress here. And even old old plugins like let's see what's a good one schedule builds is an old plug in that the schedule builds plug in, even though it's up for adoption, even though its documentation is not been converted yet it presents some very useful and workable documentation because of their efforts. There are many plugins that need to migrate their documentation there, or that use content from this conversion site plug in dash dash wiki dash docs, where what we find is the converted pages from the wiki that have been placed here as Markdown. We have the Markdown source ready here, we have the HTML source ready here, we just have to have to get them into their right location. Any questions on what we have today, dirage anything you wanted to specifically make note of here things that that I may have missed in terms of our weaknesses flaws or problems. I would like to know, Mark, where is the steps reference. There's like a big long list of every pipeline step. What part what type of documentation is that good good question okay so pipeline steps reference. And that's, that's actually a very good point for us to highlight as a what we have today specifically to highlight some of the weaknesses from what we have today. So the pipeline step references on www dot Jenkins.io. And is generated by extracting information from all the plugins and their online help. And that's, that's really cool that so let's let me put a link to that into the notes here that's an excellent one. So documentation if we go to the top level page. Let's go to yeah let's let's see if we can get here we go so pipeline steps reference here. And this is the enumeration of every plugin that provides a pipeline step. Notice that this is not a terribly comfortable navigation experience right. This is an enormous page. No grouping, no, no hints of which things belong where it's just a great big collection of, but it does have the steps so now if we look for the, let's see one that I have to commonly look for is get. So if we look for get we continue here and we'll find here are a bunch of get related plugins, and here's the get plugin. So it's description then has the for the one step provided by the get plugin called get. Now, wait a sec but where is the checkout step. Oh, it's not provided by the get plugin it's provided by something else so we'd have to go looking to find that something else. Levi was that the kind of the kind of question you had. I was just wondering also where that would end up at or if it had been mind rated I wasn't sure if it was on the wiki, or if it was part of the main steps. So yeah, yeah that covers it. And let me let me take some notes here because that's an important thing dirage and I have had a good, good exercise with this during the docs office hours as we went through various, various descriptions to understand how's that thing generated. How do we improve it we even did a she code Africa one month project to try to improve that. And some of the things we we learned from that improvement project could could help us make much better progress on it so so there's a what there is is there's a program pipeline steps doc generator that reads all plugins, extracts their documentation so their pipeline step documentation and publishes that pipeline step documentation to www.jankins.io, which is really cool. However, most steps have very little documentation. And if we look at, it's a pretty common pretty common complaint on the feedback forms to read from users saying hey could you please tell me what the default values are. What are the default values for arguments. What, what are the, what are the, the expected values or allowed values. How is the argument used, and all of those things are weaknesses tied to well tied to the same strength that this is extracted from the plug in online help. And what what that really means is most plugins don't have enough online help for their pipeline steps. And so, how do we help. Well, I guess maybe this is just, we'll talk about the what's in what's next, because that's another good thing that's in progress. We did a, the she code Africa pipeline steps improvement project. And that thing identified some issues, issues for maintainers and for contributors. Right. So there's there's a bunch that we can note there. Excellent. Thanks for a great question. Oh, and let's put a link to the pipeline steps reference into the document, so that we've got it. Yeah, so, so on the plus side, it's not coming from the wiki, because it's not coming from the wiki was unharmed by the wiki attack. So that's, that's great. We're not the fact that wiki dot Jenkins that I always offline doesn't damage the pipeline steps reference. Any other observations on the what we have today. No, always. Okay, great. Thanks. So the syntax reference is, is, yeah, there are, there, there've been comments about the syntax reference people wanting more, almost always it's hey give me more examples. And usually what the, the, the voices really saying is, please, I need, I would prefer a solution to the exact problem I'm trying to solve. Great, great thing it's just it's, it's very difficult to create solutions for everybody's exact problem. Okay, so let's go ahead with, with next dirage anything that you wanted to comment on in terms of where we're at today. Anything that I missed. Okay, I'm going to assume not super. All right. So now let's talk about what's in progress then, because this these are the places we've chosen to work. So we've got an active Hectoberfest project right now on migrating more plugin documentation to GitHub. So we did a recording. Hello. Oh, hey, yes, do you rise you there. Oh, I'm so sorry actually I was speaking previously and I just realized I was not audible. Oh no go ahead so please go ahead what we're going to say. I'm just saying that from my side I just wanted to contribute that one point that you already discussed that is transferring everything from Vicky Jenkins to individual data repository so that is the important thing that we're doing. And that's exactly what I wanted to do. So nothing else. Great. All right. Thanks very very much. Excellent. Okay. And then the record the migration of plug in docs to GitHub, we've got a recording from October 2nd that that shows how it's done. However, there are complications hiding even in that. For instance, I mark, I transferred, I migrated the the Ansible plugin documentation a few weeks ago. And there's been no review from the maintainers since then. So it's, it's not terribly motivating to a contributor to contribute a change that doesn't get any reviews so as part of our effort on that. We have a list of about 35 plugins that the maintainers have committed to review pull requests to review docs pull requests. And that commitment means, okay, we've got October Fest that can help that so that sheet that tracks it is right here and let me put a link to it into our notes. The idea here is that we really want our October Fest contributors to know that their contribution is valued and if it never gets reviewed as a pull request. It's, they will not perceive it as valuable. So here are the plugins and we've got commitment from the, the maintainers. And yeah, in total, I'm delighted to say almost 40. So this is a good task for somebody who is a brand new contributor. It's a fairly straightforward task because you take the markdown from the wiki docs page page. And you may combine it with the HTML from the old wiki page, and the two of them together give you something that is quite usable. And that's another point I should make about this one. The, the markdown translation of the Ansible page lost table tables, and so need to extract the tables from HTML. And so it's this isn't always a trivial activity to do this migration. Thankfully, most plugins don't use tables in the documentation. Also, I think we received response from the reviewer of Ansible plugin, right? I did we? Oh, I had not, I had not seen one. So maybe, maybe I'm mistaken. That's great. So let's, that's a fun one to check because here's the PR. Yes. Yeah, so this person as far as I know is not a is not a maintainer. Oh, I don't think so anyway. Okay. I mean, I'm glad that I'm glad to get response from anybody, but, but I didn't think that that person had authority to release the plugin. The change that you did right you're updating their read me so it automatically updates on the plugin page. Exactly. That's, that's what I did is I, I shifted content from the wiki into their read me so that it's right inside their repository. And I make a one line change to their palm file to inform that on the next release documentation should come from here, or no documentation should come from here. Instead of trying to be read from here. That's that's it's really that simple. That way it's their read me and inside their plug in their editing their read me whenever they make an enhancement to it or change to it and that will then be published to plugins dot Jenkins. Yeah, that's nice. It's obviously a much better architecture when you can like dynamically populate the docs page, you know from the source. And, you know, obviously it was always been kind of a complaint around Jenkins documentation, not necessarily that there isn't documentation that it has always been scattered between all these different pages that you reference the steps reference the plugin page the wiki, the read me. And so to kind of point everything to the Jenkins like plug in marketplace, where the read me is automatically displayed. You know there's automatic linking to existing Jira issues, which was always my complaint because I would know a plugin that I wanted to fix something. And I didn't know where when I filled the ticket out and Jira, what do I put. And so what I found is if I go to the plug in page and click the existing Jira issues. It gives me a template like Oh, this is what I need to put when I create my issue. Exactly right and and and what what you're highlighting is just what a great job Gavin and spin it connection you have done Gavin Morgan and just been like I've done on making the plug in site, useful by steady. And so with a link to the pipeline steps reference for that exact plug in right and, and it's Java doc so the Java doc looks like this one needs work interesting. But, but I think you're right that it's brilliant that we make documentation navigation much much better for people by doing those kinds of things. Yeah, so you're, or even the report an issue when okay now it takes me to a. I'd like to say something is broken go here. And yes it really put me into a Jira ticket so so absolutely. Yes amazing work. For me at least the there's a there's real power in us getting plug in maintainers to review these documentation pull requests that shift strategically shift information into the plug in repository, instead of having them expecting them to edit in a wiki page somewhere. So I think this is exactly the right step to take. And now there are more steps to be taken right things like this where the change log, we can automate the change log generation now as well and we can put it in a separate location so it's right in up and all sorts of improvements that can help with these instead of these releases being shown just as a shot one we can have them shown with real descriptions of of what changed in the release like shows up here. And all the and this is actually maintained automatically for us by GitHub through the release drafter process so so there are all sorts of improvements that plugins can make. We just have to get them to do code review and merge and release. All right, so that that sort of talks about them. What's in progress for plug in docs migration and now 35 plugins we've got, we've got. We have over 700 migrated so far. And that's that's really wonderful. And that means no plug in with, let's see how would you phrase it no plug in with more than 10% installation. Plug ins with 10% plus install penetration have been migrated. So, big positive, but while that's great 10% Ansible's an interesting and very useful plug in and it for example is not migrated, it's only got 20,000 installations, but 20,000 installations is a lot of installation still. So, so we've got work to do there. Next, the next story that's happening actually is the Jenkins architecture description that's happening thanks to work by Angelique job. And what she's done is she submitted to pull requests that provide architecture diagrams and the architecture diagrams are are much more understandable for most people to talk about how does one is a network flow and I believe the other network flow diagram. And the other one is a, a block diagram of let's see of, I think it's architectural or component interactions, and would love to have more on that but it's already great and then Jenkins developer documentation this effort is around. Hey, making things clear and more understandable. Do you ask anything you wanted to highlight on any of those topics in terms of what we've what we've got going on with October Fest. I think also is working on securing Jenkins. Oh, that's right Jenkins security right. Yes. Right. Very good. Okay. Thanks for joining us. If there are any topics you'd like to bring you're certainly welcome to just just chime in, go right ahead. We are being recorded so so don't don't say anything indelicate. The other piece of this is that we've got wiki migration for non plug in wiki docs. And this for me feels like it's largely stalled. In part because there is so much to do elsewhere in the active projects. And in part because also because there is much more structure. There's a lot of thought that's needed before we do it. So for example, there are times when there's there is a page on the old wiki that that has some outdated but useful information, but intermingled in the outdated but useful information is a bunch of information that's just no longer accurate. So we need to bring it forward on to www.jankins.io we actually make things worse. So, so we need need structure checks. And it needs accuracy checks and that's not well suited to someone who's a first time contributor. We can't just give this to somebody who's never used Jenkins before and say do this transformation. It really needs someone who is isn't experienced with Jenkins and can say oh yeah that's false. That's true etc. So for me right now, I'm considering this largely paused. And we'll we'll discuss what that might mean in the next steps. Now then the next piece is that there was an effort in the Sheikot Africa initiative that we did in March or April. And there we've got a pipeline steps improvement technique let me see if I can find a link for it. Sheikot Africa. There we go. Here's the contribute on so I'll just link to this. And the next thing is, is about 20 pages of notes that we took as working through helping these five Sheikot Africa contributors, as they tried to help us do better pipeline documentation. And, and the the exercise taught us a bunch of things about what we can do better. And so what we will probably do will likely run another Sheikot Africa project next year in 2022 with the same technique. Now one of the challenges we had there is finding people are willing to mentor these new contributors. It was much harder to find that actually then it was to find the funding to pay them. And what we did is we paid them, they were paid I think us 500 for a month of writing on Jenkins writing and and and coding in this case because there's some some compilation that you have to do any questions so far. So what are the requirements of the mentors in this project. Good question yeah so mentor requirements. We need people who are, you need to be confident in written English available during Africa, what you might call working hours hours and just after working hours, because usually these are students that are accepted or they are new workers in some area and willing to meet about, let's see it's one to two times per week for one hour. Did that address your question dear Raj. Yes, definitely. And also interested to know what are, how do the students are interested in this program from Africa, see this as an opportunity. So what are the views on this. Do we have some good response. Oh yeah good question so how, how are the applicants, etc. Yeah so so let's last year's they had 150 plus applicants to the program. They only had meant enough mentors for, I think, less than 20. And the big barrier was mentors right they had funds that they could have paid more, they, they couldn't put them into a program because we didn't have mentors. And so the Jenkins project mentored five and two other projects provided the other remaining mentoring. That's that's a very good number, what do people say. Well it was it was an interest, it was a challenging experience actually an interesting a very positive experience but a challenging experience for us, we'd never attempted to do mentoring for a group at once. We had Google Summer of Code for many years and we're quite good at Google Summer of Code and we're really expert at it. We know how to make that mentoring work how to be effective but this mentoring a team of five people at once, when they were in fact in several different countries of Africa, and, and they were a team assembled by choosing what was selected as best candidates necessarily people were physically near each other and with COVID it wouldn't have mattered anyway. Right, they physical nearness wouldn't have helped but, but it meant they had different experiences they had different backgrounds different access to an internet bandwidth, all sorts of things like that. That makes sense. Okay. Any other questions or comments with regard to the, the what are our current projects. So the, again, the theme was, what's in progress right now. And we've got October fast wiki migration that is largely stalled, and the she code Africa pipeline steps project that completed earlier and we intend to do it again. Now this, this, this last one this pipeline steps improvement could be used for October fast as well. It's just a little more complicated than the, the docs migration effort that we chose for October fast. And it really intends to put people into the code and let them compile it, run Jenkins with it, see that it works at and see their changes so we were, we had a broader objective with the she code Africa project and we did with with October fast. Okay. So we're going to talk about alternatives and next steps then and open to suggestions and different different ideas and alternatives so the challenge we've got for docs without the wiki is, let's remind ourselves there is what we have as we have HTML source code for all the pages that were on the wiki. And not the HTML source code is not at the same location as the original wiki page it at a minimum includes a serial number or an ID number in the page. In the GitHub repository. We also have the markdown translation of the plug in docs from the way that we're on the wiki. And that's, that's the markdown source is in the plug in dash wiki dash docs repository. Okay, so, so this is a good source of information for someone who wants to do a translation, do the migration to GitHub. However, if something's missing from that they can always go to the HTML source code in the markdown translation. And if there are any questions on that so far that that's for me is a little complicated to describe, and I worry that the description may not be as clear. Alright, so there's with with two facets to that that talks about maybe what we should list that as is plug in docs alternatives, and then what we've really got is those choices plug in docs it's pretty easy right we want them. In the plug in GitHub repository. We don't want to keep separate pages around we don't want to keep them anywhere else other than inside the plugins own GitHub repository. So that is for me is a very clear direction and I like that direction, and the project is running well that will make that transition. The challenging one is non plug in docs, and this is where I'd love, love your insights on and suggestions on alternatives we might consider. So when I say non plug in docs I mean things like. Well if we go to documentation developer guide, the one we looked at earlier in the session was in architecture there's this architecture wiki page. That's not tied to a specific plug in so it really doesn't belong in a plug in document, it probably belongs right in this page or in a page link from this page. But that means we've got to get that content here, or we need to bring it back in a way that this hyperlink could be modified to point to that new destination. Was there a comment there. No, okay. So, so my great is the first question or host at current at a new location post static pages at a new location, and then possibly redirect from the old location to the new. That kind of thing. So Gavin Morgan had proposed a poll request. Let's go look at that here where what he's suggesting and it's still I believe he considers it's still a work in progress. So what he's suggested is instead of pointing to wiki dot Jenkins.io we would point to a different static page that has the same content. So he hosted a temporarily on this other location, like this, and that would then give us a page. We could do this with GitHub pages we could do it with our own static hosting on on a site on the cloud provider etc. So let me put that in the notes comments or questions so far. Yeah, great. We had, and just to just a counter we had attempted this migrate step. And I think the reality is migration really is, is the ultimate preferred way, but it requires skilled skilled. experienced people to review and correct while we're migrating, whereas if we just link. Then, okay if this is imperfect or flawed it's still better than no information. So the thought was alright we could do a migrate eventually and host static pages immediately. The first part talks about the plugin documents that were previously hosted on wiki dot Jenkins style. And the second part, you're talking about non plugin docs. So it includes like logs and technical documentation. Exactly architecture docs developer docs guides tutorials, all sorts of things that really aren't specific to a single plugin. Right. So, for tutorial we do have a section in Jenkins to die over. We do have some logs or some kinds of artists in there. Yes, yes we do. Yeah, so we've got, we've got sections and Jenkins that I owe for each of these topics. But what we don't have is transition from from the wiki wiki page that was, where was it here, this reference that as an example or their examples like that on developer tutorials as well that are on the wiki and not anywhere else. So I think the sense I have is, this is likely our preferred path, where we first host the static pages, either as GitHub pages, or as, as some other some other static web server ourselves, and then eventually migrate. Now, now that the hosting is GitHub pages has the benefit that we don't pay the hosting costs. Right, and they have what seems like almost unlimited bandwidth. For me that one is, is very interesting but it would need, need, need some work to make that transition. Because if I understand correctly I'm not sure GitHub pages can be used to host direct HTML pages. And to those of you who are on the call, if any of you have experience with GitHub pages my experience is quite limited. So I believe GitHub pages will host any static site content. So whether it's like Jekyll or Hugo. It's static, I believe it will. Okay, thanks Levi so. So, even even something as sophisticated as Jekyll or Hugo. Great. Okay, good then then that gives hope that if we can, if we can identify. the transition names identify the destination page names, then GitHub pages might be, might be more than good enough as a destination for the documentation. Excellent, thank you. Yeah, and once you guys have done the work to make it static, I mean, there's so many free offerings these days cloud player has free static site hosting Netlify has free static site hosting. Oh, okay. Might put you out of the free tier in some situations but I mean again with static content that being being so cashable. I don't know if we're worried about. Excellent okay good so so that that's that's also been very interesting that we could. We could that would give us another alternative said hey we don't want to do with for me GitHub pages is interesting because it allows us to use the pull request workflow if we need to make changes to it. But but cloud flare with a with a site we published sounds interesting as well. Good. All right. Yeah and they both also would work with the full request right so you make you change the code and then you just deploy it right. Okay, so it's it's cloud fair flare Netlify are not blocking us from using using get based deployment techniques. Nope. Okay, excellent thank you. You know and I think you've summed up like the next steps pretty well with the wiki going away it makes sense to try to replace it or you know, preserve as much of the important stuff and get it back online as possible. But looking forward even further down the, you know, the path. It seems like you guys in this process of being forced to do with the wiki have relearned or rediscovered a bunch of things about documentation and how documentation is created and generated on through all these side projects like she code Africa. It seems like there was a bunch of good learnings from that. But we don't lose it again lose sight of side of this. And I don't know what you guys are doing in Jira, you guys are using, you know, like, epics to track things. But I think something to track long term is, can we get, when you click on the documentation on Jenkins.io, you know, can we get a docs dot Jenkins that holds everything, and we don't have necessarily so many places basically getting the documentation off Jenkins.io and maybe getting it into a docs dot Jenkins.io, a documentation site, just for documentation. And then there is no question about, you know, all I'm looking for documentation where do I go docs dot Jenkins.io you'll see that in a lot of other tooling terraform and AWS and things like that. And that's the question. Yeah, so should I, I think that the original vision for WW Jenkins.io was that it would be the equivalent of docs dot Jenkins.io but it's not there yet so so maybe what you're saying is really centralization is the thing. And, and we should, we plan to continue the centralization. Then if we now I guess a docs dot style hosting. I've seen other sites that use that to host versioned historical, you know the Python docs for instance where I can navigate to 373635. So that's good, continue centralization. As part of this transition, right so. Good. Very good. Now as you think about docs dot Jenkins.io as a concept. What are some of the things you would envision would would best fit there Levi so is is is that a, the, compared to what we have today it would be. All right, everything's there rather than no no links to the wiki just no links to wiki everything is is self contained. I think when I look at Jenkins.io, you know, it's, it seems like it's been updated and modernized over the last year or two. And it looks really good, and it has a lot of different good content on it it's got the blog. You know, and things like that the about how to contact right those kind of things. And then it's got the documentation which is a bunch of sub pages on itself. And just for me I feel like having a separate site a docs dot Jenkins.io, where I can go and anything documentation related is either there or as a gateway to it so like, I wouldn't get rid of your guys as plugins page especially with all the great work that's been done to it. I feel like, if I click documentation, it should take me to a site, and then that site should say Oh plugin documentation and I click it, and you know it either has its own search bar or it redirects me to the plugins site. Okay, just more self contained and I guess more. I think that guiding architecture right where it guides you to the documentation. Instead of right now like getting rid of wiki has helped a lot, though we still have kind of this, like you said there's some stuff on the wiki that needs to be migrated and hasn't been so where where do we put it. And Jenkins.io to be like, kind of like marketing right isn't that what most like Terraform uses their main site for you know you go to Terraform and it's like, this is the Jenkins foundation and this is what we do and this is Jenkins, and having docs live someplace else. Interesting. Good, good suggestion thanks okay. I like the idea. Interesting. Okay, yeah so, so for me that feels like a massive project but fascinating. Okay, yeah, along long term long term. Right, right exactly that's that's there in long term, maybe what we do is put it there is long term ideas slash vision. And we've got that on our notes it says hey, this is where we could go and use www Jenkins.io as the front page, and the marketing and project promotion, right, and then use docs Jenkins.io for reference docs documentation. Let's just be focused on reference. Interesting. Okay. Yeah. And I guess along that same long term thing. Kind of something that's been on my mind is the splitting of declarative and scripted pipeline documentation. Before we pointed at scripted and the declarative was hidden. That's been reversed in the last year or so where by default we're showing declarative and we're showing scripted as advanced. But I think sometimes that can be confusing even for me that has, you know, I've used Jenkins for, you know, probably over five years and written lots of pipelines and sometimes at a glance scripted and declarative can look awful similar to where you really got to look like, okay, this is declarative. And so, having that kind of separation. And I don't care what you guys call it I don't care if we call one beginner and one advanced or one easy and one difficult. Right. But maybe in long term having like this, because I think feel like there's this hierarchy of where there's plugins and plugin documentation is focused a lot on users. Right. Users of pipelines, want to find out how to do things in their, in their builds. And then you have the second form of documentation, which is very similar which is like your scripted your declarative syntax. And then there's this whole another segment, like you said of like developer docs. And that's where you're like, I want to develop a plugin, but I kind of need to know some of the architecture of Jenkins, and I need to know how do I do this. And so, yeah, having, I think we already got that kind of well if I look at the Jenkins.io that's kind of split up the document yeah so there's like the developer guide the contributor and tutorials. Yeah, just going down that path and still making sure the documentation has kind of like a table of contents almost like a flow and a guided path if you will. Right, right. And by, by audience right so it's, you know that there are specific audiences for for different things right there are, there are people who are not the least bit interested in creating a specific plugin but they rather need to get the pipeline tasks complete. And so, oh no I'm creating a new plugin I need this and it there those are different layers. Yeah, good insight. Thank you. Any other topics we should discuss we've only got about five minutes left and I would love to have a five minute break, considering how middle of the night it is for me. Are there other things that we should be discussing here in this last few minutes. Excuse me, I have a question. Yes. Thank you so much for all the information and this is my first time joining the Jenkins Summit. And I just like to ask because there's so much information to digest here, because I would really like to join or participate in the future. Who do I reach out to have questions regarding the documentation or contributing in any way. Great. Yeah, so we have a, we have a getter chat channel. So let's let's put that separately here. What if I want to help and connect on getter. There's the link. That's one we also have the Jenkins Community Forum. d.jankensio.io where you can ask questions and get get help and encouragement. Those two are great places for for good interaction. If you'd like to contribute as part of the Hacktoberfest Hacktoberfest itself. We've also got. So Hacktoberfest has. There we go. Oh, yes. Thanks, Deraj. Very good. Deraj notes office hours as well. Right. So every, particularly if you're, if you're available during either, well, let's let's note office hours. Very good. Yeah. So office hours are, I didn't remember them being listed in events. Deraj, I'm going to grab the link to that because here the docs special interest group is right here. And it includes notes about when we meet. And office hours specifically for documentation. Well, I wasn't, I wasn't sure, Paul, were you asking about documentation or more generally. As a starter for documentation, but in the future, maybe also other. Okay, so, so let's do documentation first then. Thank you. Docs office hours are described there and they happen twice a week. Once. That's how it started. Sorry, what was that, Deraj? That's exactly how I started as well. I start joining Docs office hours and then I continued each week. Yeah, so we have once during India standard time. And that is on Tuesday. And once during what I'd call European hours, European slash US East hours. And that's on Thursday. So thank you, Mark. Well, yeah, great question. Thank you very much, Paul. And we would love to have, have you you assist you can see it in that that location. Those are great places. Short term, October Fest is a great excuse to get involved because it will also give you a T shirt. Yes, definitely. Well, so I think, I think we achieved what I had hoped to do. I propose we exit from the session here and let's go back to the main room. Thanks everybody I'm going to end the recording now and I will post the recording later.