 Hi everyone, welcome to the second meeting for the building Jackens with alternative tools project and Today's agenda. We're gonna talk about the project plan and That's basically the only item in the agenda for now unless we have some issues we want to talk about so let's see Let me share the document screen Share screen Okay Let's see Okay, oh we haven't did do you have like I'm gonna ask did you share with us the project plans or do you want to talk about it? Regarding to the project plan Chris, I was thinking that I have tried to Put the things that I had on my proposal that I was that were like good enough in my opinion And I was thinking can't just we use my proposal as the project plan for now because it is really a You know How you'll say it It is like a time-taking process of Writing that same project plan on the wiki. So can we just for now use my proposal? We can put the link to my proposal on the wiki for now And use that as a project plan. I can I can update my proposal with that And when like on some weekend when I'll have the energy to actually do that I'll just put everything to the wiki Would that be fine with you? Yeah, but do you want to walk us through what you have? And let me let me just show the screen first. So would you like to walk us through what you already have So Chris, I think Vandit, I believe Chris's question was do you want to walk us through What we've already what you've got because I think I discussion amongst the four of us of the existing plan is a really good idea Yeah Should I just share my proposal for that? Yeah, just share your screen and let's let's use that as a discussion All right I Can you see can you guys see my screen? Yep Awesome So What the first the first phase for the project would be restructuring the content because Entora uses a complete file structure Then Ostrac So I have already on on the on the Jenkins doc on the Jenkins hyphen doc Repository I have already like started the file structure like that we can add more modules and just Import the import the docs That would that would that would Take maybe Around Two weeks, I guess because some file some files would need to be changed according to the Entora structure like In Ostrac we we define some things in the ad hoc file that is Is not very really necessary in entora. I've written that here somewhere. Yeah conversion of files according to entora So Bundy do you want do you want questions while we're here or would you like to delay questions until later? No, you can interrupt me. Okay, so so I see If you could scroll back up to the list of sections that you've got enumerated there so user guide I understand that's the What the thing calls the handbook Developer guide and that's the one that I could see absolutely needs to be versioned right so that's the one that's entora fully versioned Developer guide would be unversion mark. Oh, it would be unversion. Okay. Yeah user guide will be version Okay, and then contributor guide is one. I don't recognize that one. Is that a It was it was It shouldn't be here. It shouldn't be here. Okay. Perfect. That's it is just like to show what will be the structure. Okay solutions and tutorials I recognize And and I'm assuming tutorials We won't version and the solutions pages. We definitely won't version is that is that assumption a safe assumption It was not written on the project pages how if there will be versions on a version or not, but I think they should be Because tutorials must be versioned according to the version you will be used for Jenkins and solution should be also Okay, so alright. Okay. Good good to know I'm Given the low rate. I guess that's good to know because the solutions pages are quite low rate of change But you're right. Conceptually they could be very much version dependent. Good. Okay. Thank you. Thanks for the clarification We can start we can start the versioning from now on because like what you said the solutions page are not that bulky But they should be versioned or conceptually they should be versioned according to the Jenkins Version you will you the users are using So so then then maybe I should ask a different question should the developer guide be versioned as well that way everything you've got here every guy every item you have here except root is version then A developer guide shouldn't be versioned because When a developer or you can say a developer contributor who will start contributing to Jenkins or who just want to use Jenkins API He won't have access to the old versions of the API. I think he he would obviously use the API the latest API is that we are using so I don't think that should be versioned Okay, my opinion. Yeah, thank you. That seems reasonable to me. Thank you Moving on Yeah I don't think that this file this conversion of files according to enter is the is a tedious task but I don't think it will I just have to remove some things from like from the top part of the page and it would be good to go I I know this was we you in our structure we use dot HTML dot HTML files as the template and And as a template to for other dot a dog files in entora we we you and in entora we we use something similar that is called handle bar js which is a templating engine So we I'll create I'll create a template file in handle bar js and we'll use that replacing dot HTML dot HTML and this this this will reside in the Jenkins UI project repository Is that is that clear to you, Mark? Yes. Sorry Chris Chris is as lead on this I should be a little more quiet You can have questions If you'll ask questions then I we can get to things that maybe I could have done wrong or like assumed wrong Coming to the main problem that I faced was that entora does not really provides anything for dot yml files in our that are in our code base which are road maps and change logs So I but Gatsby does we can use Gatsby we can use a Gatsby plugin that will use the dot ml files as content source and generate that roadmap and change logs for us I have provided the I think I should share my complete screen just a minute I have provided the link to the plugin We will just use the you'll use the content of the yml and the plugin will do most of the work we don't have to do much for this they have like written a really great instructions for that Coming to yeah header and photo from Jenkins dot IO components this was something I figured out during the application period so the Jenkins Jenkins hyphen you Jenkins dash UI project already has header and photo from Jenkins Jenkins dash IO components repository so that would be easy to implement because I've already done so but what I what I noticed was using header and photo from another repository might take some time from On a unstable internet connection but I don't I don't think we take that in account but I was thinking it would be awesome if we could like create create the header and put up from the you from the entora UI itself but that is just like We can do that but we don't have to So the challenge if you create the header and photo from something other than Jenkins IO components is they will drift apart right because plugins dot Jenkins dot IO and stories dot Jenkins dot IO and several other X dot Jenkins dot IO prop locations use those components and you'll suffer drift so yeah but you say that you did implement something in entora that would use the Jenkins components I implement I just use the header and photo from Jenkins IO components repository so we can do that But yeah like I said it is something we can do but it was open to what the mentors would say so that's like yeah I think I think after using that I didn't put it from Jenkins dot IO components would be nice for now because plugins and stories already use that Great. Thank you Well and updates and there are several locations it's it's far beyond plugins Yeah accounts dot Jenkins or exactly yeah yeah this is just the instruction how I will use that how I implemented that we can ignore that this this explains the versioning in entora so entora uses entora dot yml files as if we go here yeah in a root folder or like any folder like this The inner structure would be like this we'll have an entora dot yml at the source root this will have this will decide if the this module would be versioned or not and this will be the entire file structure here the nav dot ad hoc is the sidebar nav that entora uses we'll have to we'll have to add hyper hyper links in here hx href links for to creating the nav bar. So that is also another tedious task work like I'll have to manually manually create that Is that clear to everyone It's too quiet So yeah great if Chris Chris my comprehension wasn't full but I'm okay accepting let's just keep going Yeah This is how we'll implement versioning in user docs because that's the first milestone So I will create we'll create different folders will use all the folders as components in a single repository this is a feature entora provides so our documentation would be divided in folders in directories and these directories would contain modules and entora dot yml so the entora dot yml of user docs will be versioned so it will some look something like it will look like something like this with the version and for the unversion part I'll just we'll just have to replace this with with this and it will be a nonversion Okay Also the versions would be on the versions can be on on tags or on different branches we can create we can create a branch we can create a branch namely version 2.0 v2.0 and we can create a branch version 2.1 and both will have different documentation but it will on our site it will the user can select the version he wants to He wants to read documentation Okay So okay to ask for a pause here in terms of versions Chris I'm assuming that we want the version numbers to be most likely the LTS versions and only the ones of the LTS versions so that we would have a new tag every three months and a new but Vandit had you thought no we'll be doing a tag every week and therefore the weekly releases will get documentation certainly get releases every three months and they version their documentation I'm not sure of anybody who versions documentation weekly what's your experience Nobody from what I have seen that nobody actually changes changes documentation to weekly and most of like the entora dogs entora dog site has has documentation only for for the LTS versions they released Oh good okay so there's a pattern that Yeah they already follow a pattern so we don't we don't clutter we Wait let me show you Yeah Yeah Yeah Yeah Yeah They or they or they have they versioned they where they versioned entora dogs from 3.0 and 3.1 But if we if you had to do it on a weekly basis it would be so clustered it would be hard to use it would like spoil user experience in a way Yeah So I prefer that we only only provide documentation for the LTS versions Well and for for even more precision the dot one of the LTS you're okay with that so it's every three months every 12 weeks not every four weeks As long as we can see that these are different versions Yeah Right so it'd be 2.387.1 and next would be 2.401.1 Okay got it You can use the 2.2.3 and 2.4 Yeah Coming this this was how will we implement an inversion nonversion dogs with the tilde sign I guess we call it tilde Okay Yeah Entora works on a feature on a concept called start path start paths are basically where will entora start finding the dogs from so the start paths are written in the entora.yml Like this this is this is how you will write the you will write the sources the content sources of our documentation the URL of our repository Let's start path start path since we have multiple since we have multiple documentation so we'll have to write multiple start paths here so this was this will how it will look This was an example path to the entora.yml and then the branches the branches is where I will write the versions like we can write version 2.1 version 2.2 This will this will then all these will have the option that you can switch from version 2.1 and version 2.2 Okay This was this was the this was the screen like what I've created using Jenkins UI that it uses the Jenkins IO component footer Yeah, this that was for phase one and customizing you as which is like the which is like the most important part of this project since we'll have to Jenkins by everything So like I said entora uses handlebars just for UI and it in the day days which I'll show you comment Yeah This is the Jenkins this is the entora UI project it contains these it contains these partials these partials have this these partials already have the base to start from So I think I'll first start I'll first see that what will be the files that I would have to change what would I would actually have to change or would the default or the out of the box code would be fine or not that would I would see that and After that after that I will I will start changing the CSS for each of the component to Jenkins fire it to Jenkins fire it yeah The JS is not much it it is it provides basic functionality that we don't have to change much in this from what I what I have seen changing If you have if you have to add a new functionality we can just to the JavaScript of the site we can do that we can add a new file to here But the the these files are great out of the box we can modify we can we can definitely modify them according to our needs if they change yeah Our customizing the layout is all about the CSS part so yeah I just showed you will have to I'll have to change the CSS in the CSS folder for each of each of the I tried you I tried using the existing CSS but you can say it is kind of a mess on different screen sizes on different screen sizes it does not work really well So I think I think we can we can you we can use this as a base as it is awesomely responsive responsive responsive and work build on build on that But we may we may want like to put a lot more time into like doing this properly like this is yeah this is the most important part and this will take the most time Okay Okay and that's and so the idea there is that the net benefit of this is we will have a much more responsive experience for users at different sizes it will certainly certainly cause changes right there will be changes as a result of that But the ultimate goal is a much more responsive layout as screen sizes change Yeah I'll try I'll try to I'll try that the things that are already there don't break while change while Jenkins fire while Jenkins find the site so yeah That we'll build upon that we'll see I hope I don't break many things Okay This this is this is this is this is how handlebars.js file looks these are the you can you can consider them as a partial as partials So it's just template library I think I've used it before Oh that's awesome then I think I have Yeah Yeah well these are partial and the these these partials will be in the partials represent These partials would be here in the partials repository and I'll change these to change the structure the layout of the the page Okay Yeah but Antora by Antora by default the structure Antora by default uses is much similar to of our Jenkins since they have their nav bar on the side And table of contents on the right side of the screen and the main content on the in the middle so I think it I'll just have to think around with CSS a lot This is the styling according to CSS a CS I think I haven't like explained most of the stuff Yeah Yeah I have a question though I have a question for you but you said like for for for like the Jenkins stock repo you take two weeks to do But how about the the Jenkins dash UI dash project So how do you plan to spend on Yeah I can't actually like if we if we will if I have to say a number I will say maybe around three weeks considering if some if I get stuck somewhere It will take like three weeks to like completely completely customize the UI But yeah if things go well it would it would take three weeks Okay So three to four weeks Yeah Yeah I think we should I should add some buffer so if things go wrong Yeah Okay moving on to the next part Jenkins or IO uses Algolia doc search for as a search engine on the on our site So they enter up enter up provides the instructions on how to how to implement how to integrate Algolia to it so it would be just me for following the instructions the tutorial they provided Yeah I would I would like to know how they they have provided the Docker solution but I but I have I have read Algolia docs there are other ways ways to but I would send this to the Gitter channel so maybe the mentors can review it first before I implement it yeah I'll send I'll send it now I can add it to the meeting minutes Yeah I'll just add it here for now Chris Yeah sure Yeah These are the putter and the header scripts that will that will that will be used while integrating Algolia These were all provided here and from what I have seen on other repositories Yeah Phase 3 is migrating blogs to Gatsby so by default Gatsby is normally used for dot m dot mdx files but we we we have plugins that are you that we can use for dot ad hoc files for our skydog We can I thought we could like create another report for blogs so since it is an expanding topic and blogs expand so it would be nice for to create another report only for blogs but that was like one of that was like we can do that but I would like to know your opinion Maybe put like put everything together for now unless we need to split off we can do it later Yeah, yeah we can because that I have what I have structured the directly like that so we could easily split it off if you in if in future we had to Okay Yeah, we Gatsby Gatsby provides awesome starters so I I start I you start I use this to create that to create if from if you run if you run the project in the Gatsby in the Gatsby block test directory on Jenkins talk It would some it would look something like this No, not this I guess They have changed it would look it would look something like Just a second It gives a block somewhere remember I guess up top go back up top like on the way inside See a block Gatsby start yeah Gatsby start yeah yeah I try I try and start I've got I have created for my POC was the default default starter that I that I created from the CLI so it looks different I send it if I'll find it here It is in it is in the documentation I guess it is like the default starter yeah it is here Yeah, it looks it will look something like this for now With Jenkins logo here what I have created in my POC so it will we can have card we can have blogs as cards that we already have on Jenkins.io Yeah, so just want to confirm with you so we'll use Gatsby for the blog and also for change your log anything else No, no, we only with dot dot dot yeah by ML files would be the only problem for now. Yeah, from what I have seen I don't think there is anything else that would want to work with and Torah Okay, I mean guess me Yeah So the just just to confirm then Vandy that means that the security advisories will be will be done with and Torah because they're a doc No if yeah if they're a dog if if if something is a dog it will be done with and Torah but it's something is dot yml it we can't act we can't do it with and Torah from now because they don't even provide any plug in for dot Okay, so that's we would be the way for that. Thank you. The steps I have written here uses the uses the existing blog that that I can tweak with like I can delete for remove the unnecessary files that won't be necessary for Gatsby but while I was doing that while I was actually doing that many things were many things were unnecessarily breaking and I couldn't figure it out. So I think I'll just copy paste the dot yml files. Yeah Modifying won't work. So that Gatsby is so easy to use we can just we can just lay out the lay out we can just customize the layout from the source layouts index.js that is here. Yeah, this is the layout of this will be the layout of our blog. I'm not I'm not very handy with react but I think I'll be able I'll be able to I'll be able to learn it on the go. So do we use classes or do is functional components react in this case. Normally, normally they are using components. Okay. So what would be your preference Chris. And nowadays, like most people use functional components that that's why I'm asking, because I see like this one. Yeah, okay. Yeah, they're using components. Yeah. Yeah, this is this is this is this is if we were like, if we were planning to use Gatsby for more ask a doctor. More ask a dog but I don't but I think that's off the table so this would be a necessary now. Yeah, the integrate the integration parts of the blog site if they both of them will be in the same repository. I will have to create will have to create a setup file that will install the prerequisites install into run Gatsby locally on someone system and changing changing into correct repositories will build it. Okay. Makefile uses tasks based tasks from I have worked a little bit on on make files while contributing so I'll just set up I'll just have said I'll set up tasks for that. Okay. Yeah. That was all that was all Okay, so if there are any like doubts or cracks you guys saw through these tell me plan looks great to me. Thank you. Great. I have one question like so you have like Gatsby and one is entora. So how you're syncing the design I mean we have like entora site or some CSS handle but this and Gatsby we are making using some I mean react components. So are we going to use the different designs for both I mean fonts and all the so how you're syncing it. I'll have I'll have to I'll have to create components that that follow the current design of the blog site if you if we go here. Just a minute. Yeah. Yeah, it is. Yeah, we will follow this design for now. Since since since I will also will also will also see if we could increase the user experience in any way. This Yeah, we'll see if we can modify the user experience in any way but this will be the like the most urgent design will be this. And the search will also be there for blog using Algolia. Yeah, yeah. Okay. So you're going to make a component out of it. Okay. One more question like so you are using that entora thing and we have docs versioning thing so we have like some 3.0 and 3.1 and 3.1 is the latest. The user we are going to genkins, they Google Jenkins docs. So will the 3.1 comes in the Google indexes like the latest version should I want to I want latest version to come to Google index so No, no, no, no, no, no, the, the, if someone searches for Jenkins dot IO, like the main site, the main site will pull up and the user can see the user will see a drop down here somewhere here. I'll have to see where we'll put the drop down. Most of the sites have it right, have it on the right side of the search bar. He could, he would be able to, he would end up on the latest, latest documentation site. He would be able to, if we, if we have 3.0 and 3.1 and 3.2, he will see 3.2 out of the box and he can switch. But from, from on Google, it won't say on Google or any browser, it won't like he won't be able to see the versions. Okay, so on the results. Yeah. So if he search like some user search Jenkins GitHub plugin, a GitLab plugin, so some docs will come as a starting or maybe a second time or so when he clicked that link is going to show the latest version of that. Yeah. Yeah. Yeah. Yeah. You will always get the latest version first. Okay. And anything you are so I say shared about and Torah ML file, where we are going passing that configuration. So are you passing any, anything like SEO related stuff like in front matter. So maybe like, if I, if I have a doc, so I want that description, I want to put description of that doc so that it increases SEO of that doc so where you're passing that in front matter like in MDX and all we pass in front matter something. Like, I don't, I don't, I'm not very like handy with the front matter thing, but when I was, I was, I don't think so in Torah like provides any documentation related, I would, I would, I would, I would study about it and maybe then I would have I could answer your question like, I don't know much about front matter now. Right now. Yeah. Yeah. Yeah. So, Rajiv's question is excellent minds a different question is everybody settled on on the answer to Rajiv's question. Yep. Okay, then then mine is, Vandit, could you open under the documentation link here, go to Jenkins pipeline. There's, there's a piece of this. Now, in the bottom left hand corner there's the pipeline steps reference. Yeah. Open that. Okay, so this is, is seems like a natural, well, it, it's, it should be non versioned, I think, but it's a doc. And, and this is where I guess I have to ask you the, do you have a, were you aware of this if not let's make you aware so that you understand how it's. So what this thing is, is there's a program that reads all the Jenkins plugins and extracts the help from them, and then paste them places them available as a doc source files that we use here. But these it seems to me it would be misleading to the user if these were versioned, because the version number we would assign doesn't correlate with the plugin version from which we extracted the documentation. So Chris, could you pick one of those, one, any one of those, or no sorry Vandit you're driving the screen so pick any one of those. Perfect, that's great. So when you click that it takes us to this page that describes this pipeline step, but this pipeline step is not associated with a Jenkins version it's with a plugin version. And so we, I don't think we want this page to be associated to a Jenkins version, because, because we don't know what version the user has running. So if you'll underneath the heading one password secrets there's a view this plugin on the plugin site. And on the plugin site you'll see, oh, here's the here is the actual version number of this plugin. I don't think we need to complicate that page by showing it to the showing them one dot zero to the user. It seemed it would seem poor experience if we misled them to thinking oh that plugin documentation is associated with 2.401.1 because that's not what it's associated with it's associated with version one dot zero. Is it feasible for you to do that as a non versioned page. Because we can like I said we can create we can create a different directly for that and that will be non versioned. Great. Okay, thank you that answered my question and thanks very much. I was not aware of this. I'll just save it somewhere. There's there's another generated page in the search could you look for the word in extensions in extensions. Oh yeah, that's perfect in extensions is great as well. You see there it is click that extensions at the very top. And now on this page there's a link second paragraph from the bottom the extensions index. This thing that we're going to see is another generated thing. And now now okay now Chris you may have to help me with this one this one is. So click on the top most of an extension points defined in Jenkins core this one actually is tied to a Jenkins version but it's always the current version. So at this point it's always weekly. And I'm not sure that we want to version this it isn't it isn't developer it isn't it is like in the developer dog so it won't be worse. Okay, good. All right, so already covered. Thank you. Excellent. Very good. I'll just see if the previous thing was no it was no it was in user handbook. I'll have to create a different actor for that. Yeah, it is already nonversion mark. Excellent. Thank you. Thanks very much. Yeah, any more questions. Like throw them on me. That's all for me. Thank you. Do you have any questions about the pipeline stabs documentation. Or you do know how it works. Since markets are going to ask him like questions. Do you have like some doubt. Because like this, this is quite like. The content that you're that we see on screen right now that content the pipeline content or the is just part of the book and it should be part of the handbook and it should be versioned. So this is a version page, and it is correctly a version page. In steps reference, if I remember correctly the current generation process copies a big zip file in from another location unpacks that zip file and uses it in the generation process. Now, we could, I guess we could change that to do it some other way version branches and versioning but but right now it's just a big zip file of a docs that are generated by a separate process. The only solution I can think of is we'll just create a different, we'll create a different directly only for this. Okay. Right. Yeah. We also will have to create a partial for this so like for this page, because as it unzips from a different location, it will be like, it won't it won't be the normal year it would won't be a normal template, it will I'll have I'll write it. And you should be aware of a of a go back to that page because you need to be aware of a very, very important feature of this page. Very important because we added it last year in Google Summer of Code 2022. In that filter steps field at the very top type in the word checkout. So, so we can't lose what you just saw happen. That shrinking. Don't, don't lose that. Yeah, that is something important for the user experience and yeah, you are. Yeah, I well when when the contributor last year did it, I was so delighted. It's hard for me to express how happy I was with this change because prior to this it was a positively terrible experience to use this page, because I would have to search with the web browser and jump all over. This is a much, much better experience than we had 15 months ago. Awesome. I remember that. Okay. So, I got a proposal. So it seems like we have 10 minutes left. Do you guys want to go through what also has replied to email. Because we got some feedback. Yes, yes, I think reading Basel's comments would be really good. Yeah, I wanted to add something to that. I think from the, the mail missed something really important. I didn't mention that we'll use Gatsby for Gatsby for blogs in there. So, so should we like reply to that with that information. Oh, it should be okay but it's like do you want to take a look at the email first together. Yes. Yeah, let's let's use the 10 minutes we have to look at that email together in case there are other things the Gatsby for blogs. That's it seems like a pretty easy response but other other parts of Basel's comments may may be worth a conversation here. Yeah, should I open it. Yes, please. Yeah, it's okay. Yeah, you can you don't even have to open it in mail if you want you can open in the Jenkins developers list of perfect. This is great. Yeah. So she goes through paragraph by paragraph. Yeah. Yep. Well and and his first paragraph I think they're matches with what you were saying. Right. His, his first paragraph says. Documentation and dev documentation we use and Torah for other things for for blog change logs and other static content. We can use a different thing. Yeah. Okay. For the documentation portion of the site and Torah seems like a perfect fit because it is specific specifically designed for documentation sites and features first class support. Documentation. It's been working on Java platform support. Yeah, because and Torah is a well maintained project so migrating to to that work like is like the great plan. Well and and and Torah intentionally supports version documentation sets right whereas Gatsby does not seem to support it immediately out of the box so yeah again I think this is he's agreeing with with the direction your project plan is leading. Even with the even with the Roxy Docs team as also similar get the offer less support. Yeah. The only part the only thing I was I thought was missing is that I didn't like explicitly mentioned that we will use Gatsby for the blogs. Yeah but he got it. Trust and Torah was not designed for blogs. Yep. And the ratio makes it clear that maintenance. Yeah they are and the Dan Allen explicitly said and Torah is only for version docs not for blogs. Right. Logs don't need to be I don't need to be virgin. Using enter up and Torah for anything other than a documentation site seems as this is not interesting to use case yeah. I'm maintaining Gatsby if we if we add plug in over plug in the build time increases exponentially. Like I read I read in a blog that someone was using Gatsby and for like for two years and he added so many plugins his build time was around 12 minutes which is a lot so he migrated from it. I think I think we should reply with the Gatsby will be used for blogs and for dot by ML files. So Chris would you do that or do should I write. Oh yeah you should reply even you should be a person reply. Okay, I have to reply to all right. Yes. Yeah or just use the web page to reply inside the email message you'll find a link to the Jenkins. To the posting on this course. Yeah, that one yeah. After this meeting I'll reply to him. Okay, yeah. Also my exams are here so I won't be able to do much work this week. Exams are first priority they are number one. I like what Mark said. Yeah. So we'll, so we'll start we'll start from when the coding period starts we'll start since my exams end on 27 and coding community morning ends on 28, I think. Yeah, it ends on 28. I wanted to ask something from Rajiv. Yeah. Hi Rajiv I want like for your question was like really interesting I read about friend meta somewhere when I when I was on gas we blog so like, could you explain your question in like in more simple terms so I can search it up and so I can answer you later. Yeah yeah so we have like a dog file right and in that we put all our contents so it's starting up that content we write some metadata right name. Yeah, basically meta data is a front matter. So are we going to pass the SEO related meta data for that dog. Or a dog files. Yeah I don't feel like tags or description of that adult file and those things, or maybe cover images like the like adding cover adding cover images on documentation. I don't think that is like feasible since Like just adding some metadata. I what I what I think if like currently we don't actually add anything anything in the friend meta for SEO like and Torah removes these things like from what I showed here. And like the file structure, the file is how the file looks. It just provides a description and the author according to what our ask a dog file should look like. If you are using in Torah so and also since the sky dog files are so large in number adding SEO for each and every will be like humongous task. When the bargaining will be there right then they're not telling you have a description and author would be there. Okay, got it. Yeah, I'll read I'll read something more I'll read more about front matter so like I can understand it much correctly. Yeah, I got my answer like this is good. Yeah, should we talk about like maybe not not today but later should we talk about SEO related matters. Yeah, I think we should have that conversation. Yeah, maybe in the next week not not this week. Yeah. I'll read I'll read something I'll learn something about SEO tell them. Yeah, because like we have to make plans about how to do things like how to continue the way things are done, but using different tooling. If using and Torah things can be configured differently from what they are now. Yeah, I'll check in their documentations if they have written something about SEO really SEO there. Okay. And this is like open ended like the design and the things are like open ended it will will never come to like we will be again again revising those things and improving. Yeah, yeah. Yeah, that's all from my side. Okay, anything from you you mean. Oh, I do have one question so in this project will we make big changes in user interface. Because I see in phase two we will like customizing the UI or styling. Personally, I like more I like I like more than you a modern user experience and the qi but I think the it will be correct if we start on that if we first configure things and customize things how they are in Jenkins dot IO. And then maybe then maybe not maybe then we then if we have time and I hope we have time we can work on user experience and UI. Yeah, I understand. Yeah, that would be the correct course so yeah. Yeah, so so my question is. So based on my understanding this project is like the migration of the current Jenkins IO, because so most of the parts will focus on will will be focused on the migration instead of the customizing the user interface. So it is just my personal experience. Yeah. Yeah, I think migrating first and then configuring the user experience will be the correct course. So like, we don't end up in a mess while if I'm proving things and migrating. But that's my personal experience, personal opinion. So any questions move and end. No, I think everything is clear. But what I was thinking since what today happened, I think we should like change our meetings to Saturday, if that is possible for everyone because from from where I commute from my college. There is so much traffic. Yeah, what's on Saturday. Oh, what about Sunday. What's home on Saturday. 8 a 20 to 20 IST on Saturday. Right. Work for me about you guys. That would work for me so roughly the same time of 24 hours later. Yeah. That that would work for me. Just 25 hours later. Okay. That would work for me. Awesome. Works for me. Okay, good. So let's change it then. Update invite later. Okay, so thank you everyone. So we'll see you next week or maybe next Thursday. Yeah. Last question, will we will we receive the updated your the time updating your email after this meeting. Yep. Yep. Sure. Sure. Okay. Thanks everyone. Bye everyone.