 Welcome everyone. This is Jenkins documentation office hours. It's the first day of February 2021 Let's look at the agenda And here's what I've got for today as possible topics. So a Fixed for the meeting link in the calendar that I'll take care of later Jenkins contributor summit Tributor summit docs preparation track We keep migration plan and pull request progress and Encouraging new contributors And I would even change. Yeah, so any other topics you'd like to put on the agenda No, and I don't have anything on that. I don't know what's happened to our diversity people. They're not responding. So Back to that. I will ping them. So Kristen will to coach I know everybody's a critic. That's great Hello Jonathan Jonathan Hello, I'm back Are you guys? That's great. Thank you. Good to see you Good to see you too. Oh You said February and it is February exactly. I'm a man of work Yeah, but if you showed up on the last day of the month, you would still be a person of your word and that's you know How things often go? Well, it's Everything goes well. So now I'm obviously work for a company in Canada. So my plans just work ever too well as planet A new job or an additional job? Yeah, a new job. I just yeah I just stay back to put all my energy in that plan. So everything goes as planet Oh Relations Yeah, thank you Very very good Alright, so topic so we've got we've got Jonathan This is one that's a great one for you because we're coming We're approaching a an event that we would love to have you and Vlad and and Meg all involved in It's the Jenkins contributors summit Every two every year as part of the free and open source conference in Belgium We would hold the Jenkins contributor summit And we would do it in person there at the at the event so that everyone could get together in a room But this year that event is virtual Therefore we've decided to take the contributor summit and make it virtual as well And we're going to change how how it's done from A single day try to gather everybody together to a series of a starter and End and then tracks in between the start and the end that focus on specific topics So we're going to do day one where Oleg Manashev and others will present Present the various results how the Jenkins project is doing what it's done so far in the last year or so and highlight Topics of interest so for instance the Docs SIG will have about a five-minute presentation there Then we'll schedule a bunch of public sunk sessions within the within the next about 48 hours That will be at whatever times work for the contributors to talk about the topic that they want to address So sub teams so the Docs track is one that's on my mind and I put it together. I proposed it like this with a Topics including helping people get started contributor onboarding. What would it take to add site search? improvements to the doc generator and how to get more improvements How we do content review wiki migration plan pull request progress and this last one documentation roadmap, so Let's do it one more which have been discussed last week and two weeks ago is a documentation inventory and rework proposal based on the inventory So what what this one is? a Proposal that here will go back here to this document to look at it. It's a proposal. We discussed last week with with Megan with with actually with Megan then with Kristen Whetstone and Zina of Abu Bakar that what we'd like to do is look at the current content on www.jankins.io and wiki.jankins.io and Use that to assemble a list of topics that are available and try to slot the topics into places in the books So it's basically do more of what you had done for us for hacktoberfest That kind of technique or we say let's look at every page. That's out there. We may not have a capacity yet to to publish that page to to do the rework for it But that page if we publish it would be long here It would be long here and the idea is as a group We agree. Oh, these are the sort of sort of sections that belong in this document These are the the general ideas that might be inside that section We discuss and and sort of disagree adds necessary dispute with each other I think it should be this no I think it should be that so that we get a good Framework into which into which we all agree. Oh, these topics belong here, but these belong over here and And that way we get Okay Now we've got a plan that says when the material arrives for this we put it here when it arrives for this it goes here and And so this was a an exercise that That the parties that we were discussing with seemed very interested in hey, yes, we could We could do that and that would give us a chance to for instance correct What I had initially thought the original creators of the documentation. It said, let's do one book Like the freest free BSD handbook and about two years ago I started thinking oh, we should change it to two books user and admin But now I'm back to no no the original technique was really the right way to do it because I don't know how you Decide which thing is user in which is admin And and so now Meg noted that we might choose pipeline authoring as an entirely separate volume because it's a very different activity clearly distinct compared to compared to User work or admin work or UI work and like yeah, you know that that would be viable So the the thought was we'll use these docs office hours and the contributor Summit to review and discuss this tentative outline. So right now. I've got the action item to to begin the assembly of this of This this outline the assembly and I assume what we would do with it Is all assembled in a Google doc with one one line per topic link to the reference to the reference material for that topic and then we'll use then we'll use discussion and and Think about it Decide how to change that document how to change the location Now is it actually Document probably is the wrong way Maybe we really do want to Google sheet here because we need to know where it came from and where it's going So there's more data about this than just would fit into okay, so yeah, right I'm already saying if it should be like we had before right where it came from here. It goes to here Why don't we say I'm current material rather than reference That's gonna be ambiguous because there is reference doc versus guide doc. Oh, okay to Location of the material. Yeah, that works that better. Yes Mm-hmm. Yeah, so it is this is placing material well before it's converted Gives us gives us a destination And and gives us a a Chance to because we then have a tabular we have a chance to prioritize Which things we think are more useful topics Based on user interest So as an example To go back to Meg's Meg's point about the pipeline authoring pipeline authoring examples Continue to be a major request from users This plug-in doesn't have Examples this plug-in doesn't have examples could you give me more examples of how this works? and those Examples actually have to be written Let's be placed inside the plug-in source code at least in the way things are currently done right now So when we look at the online feedback form, let's let's let me grab the docs feedback Just because you I think you need to see this the time to and I I Shake my head some of the words that are set here are really kind of kind of harsh So don't don't be offended by the harshness of some of the things people say here about Hey, you're you're a terrible human being for not having written this documentation, but ah Here we go a brand new one. So pipeline build step Just got feedback today. No example. No weight default value Now a comment here. All right. So available arguments for each step of CMake builder Hey, what are the arguments of? Let's see Yeah, so here's one more on how do you use HTTP request and each of these give me an example is is That same caliber of awkward describe what only if successful really means and and Etc. Etc. So It's not enough, but do we have automated tests for all of the steps in all Only only if the pipeline author wrote those automated tests and so I mean the steps themselves Yeah, yeah, that's and that's why I'm saying the the only test of automated the only testing of Pipeline steps is done typically by plug-in authors who would then include those tests in their plug-in So that's another good topic Because because well what I was gonna say is it's not necessarily the best example But if you have nothing else if you put the code that you're using to test It gives something Right, right pipeline pipeline tests would be good examples to to Site in documentation If they're if when they exist maybe unit tests for the step, right? Have I got the terminology, right? If you do. Yeah, so for example Here I can bring up one that actually has some Here is a plug-in that I've been working on and You look at its test there are things here where it says Let's see if I can find some come on tests. Here we go things like this So here are pieces of the test automation that the get plug-in uses it has All sorts of sample samples from the get plug-in steps that can be used Okay, and and now So the idea is create a entire section and the week for just talk about pipelines That's that's one of the one of the and that's one of the ideas is should we have a Dedicated section that is all about offering pipelines and and it could be part of a single volume or a Dedicated volume all on its own either would be Okay, because you talk about add the documentation pipeline documentation inside the plug-in stops right, so There is a link in each repository pointing to To our week or we just duplicate the content It's it's not even that we duplicate it in the case of plugins We actually have to write the we don't write the instructions in the in the Jenkins Iosite at all we write them in the plug-in site in the plug-in github repositories And then there's a program that extracts that documentation. Oh Places it into the into the documentation site. So so this site if we do pipeline steps here Pipeline steps this page and it's a very very long page is Generated from a program that reads pipeline source code So if we look at This pipeline nodes and processes is a single plug-in that provides these six or seven steps and All this text is taken right from inside the plug-in source code Okay, and that section we have just to talk about tutorials Will be extinguished or will be a bullet I you have tutorials about To a specific language program as for example, ruby btp Java and others I think those would continue I would I think we would retain the tutorials and keep them because we've recently had more additions to the tutorials We just recently had IBM submitted a thing on how to do Jenkins on IBM cloud Vlad submitted how to do Jenkins on Google cloud And and so we've we've had new tutorials. So I would suspect we'll keep tutorials as a topic And then comes the ugly question of the structure of the pipeline reference pages Like that when you look at adding examples, it's gonna make I mean, it's already ugly It's hard to find stuff and when that's a good one to look at because it's got a whole lot of stuff We start adding examples that's going to become even harder to read but the basic pipeline Reference page these things need to be broken out into real reference pages or formatted in some way that I can find stuff Good point. So let there was I made a a feeble attempt to create Something for here. Let's let's look at let's look at a different page and And I'll show you the feeble attempt I made for one keyword Trying to trying to give more More opening material on the thing before getting into examples. So so the git plug-in actually has a Whole bunch of okay here are different things about the about how the step works And then a series of examples intentionally Stated as examples But This was this was an awful lot of work to construct these and I'm not sure this is the best place to do it, but but it It was a place that I had It's a logical place to do it I mean from a pure writing standpoint it'd be nice to pull it off in a tutorial But this is where because the normal thing is you're gonna read a tutorial once or twice to get the big picture And then you're gonna be in the reference materials all the time now Does it get just have the one step for it it? It has one step and then it has the more important piece is the thing called the checkout step right and the checkout step is Let's see. Yeah, so the checkout step Really should be linked here and if I if I as I look at it It's it's actually not so the checkout step and the checkout step is terrifying If we look at the checkout step on these pages You're going to have to wait patiently while the page loads because it is so large just a minute I've got to show it to you Because it highlights just alright, so I find SCM step has one step. I'm gonna click it Now we're going to wait. Alright, it has loaded the page notice How many different implementations of checkout there are and each of them is a valid implementation? So you see this now if I expand get SCM This one is the description of all the things related to the get plug-in and it's got an enormous amount of Options and settings and that's just one of these things that I've expanded Very if I expand them all this page is is just huge So certainly there is lots to improve In in this particular page checkout checkout should be the most popular one of the most popular pages there is but its content is is Quite a struggle to manage because of something. You know if you want to do subversion here's subversion If you want to do bitkeeper here's bitkeeper or Bazaar or or dimensions from CA technologies I mean each of each of these SCMs has their own subsection on this But it's hard to navigate this thing at the top and then there's no discussion that they had that says Find the SCM that you you know and look on and click on that That's not there because what I was gonna say back to yours was like I mean what you've got there It's not it's actually not bad. I kind of like it, but what I'm thinking of is if you had four steps for that plug-in You'd get buried in the first one, and it's like but you're looking for one of the other three, right? exactly Which yes, so I keep I don't know I keep coming back to man pages in my head It may just be that I did man pages for too long that I see the whole world through man pages but That sort of structure, you know not We don't have to go How to generate them how to how to how to make them more usable Make them more usable How to make them actually there's another one that's a good good maybe a good alignment with this one More yeah Is rest api Doc generation Because we have a Google summer of code project That's proposing to write the program to do extraction of the Jenkins REST API But but The student that's that's preparing for to set submit a proposal for that has had questions and Bumps and bruises along the way because right now we have no document. We have Only the online documentation. That's inside Jenkins itself. No separate documentation on the rest API Is that true for CLI as well? That's a good another good question I respect And open API spec So I think the CLI documentation is available and I think if we look here So let's go Jenkins CLI So here's a at least a page dedicated to it Jonathan actually I think had contributed a significant portion of this page if I remember right Jonathan Wasn't this one of the early pages you had worked on? Yeah, I guess loss. Yes loss. It's them that my pattern for takes questions. Oh nice nice So so so we've got the CLI What we what we and even even there a CLI has Has this interesting behavior that if I If I look at it like this It generates the commands dynamically based on my install set of plugins Right that I don't think dashboard right and I don't know that we tell anybody that hey the first place You should refer is inside your own Jenkins installation So so this is this is equivalent roughly equivalent to the pipeline syntax page Now if I want to know how to enable a plug-in or delete a build or right so Yeah, I think we refer to this but I don't remember where but Installation or after installation you can find reference to this page, but I don't say call where exactly Okay We actually need a whole section that pulls together everything on Administering Jenkins without the UI another session Yeah, and that's that's another right administering Jenkins as code right right without the UI That's code and there are things like Configuration is code plug-in right there's the job ESL plug-in there are stored XML files in a In a actually we should put it this way in the Jenkins REST API right Jenkins CLI tool And Stored XML files in a give repository Mark in all these years work with Jenkins and you already have or or get the information about what is the most Common cases in using Janks for example to With that with that information we can just work samples by that on the user experience So for example, we can use two case for just Write about it and give instructions about the most common uses in Jenkins Good question. Yeah, so we have that information in some studio or Farms or something like that. We have Let's let's take it this way what we what I see reports of periodically is one of the most frequently accessed pages Jonathan, I think what you're asking is how do we prioritize which which place we should focus first? Is that what you're asking or? Not pages users because we are writing for them. So for example We we know the most important for simple it's pipelines But which part of pipelines are more important? We can use page we can use page as reference because it's missing content there or it's just a pulverize inside the week So we need some user feedback Hopefully just saying look this part. It's important of for example We have partners and some events in some places then just Can't share the case of use for Jenkins So for example our pipeline here just work running sonar plug-in running Test this and integrations and access github and pull and push everything go from there into there So with that information, we can just put our focus to construct that More available user experience definitely, but we need to be careful because for instance We know that last I heard something like 54 percent of the jobs running in the Jenkins will be freestyle But we don't get called on but I think they're old stuff from people who've been doing them forever They're not looking for documentation on how to do freestyle jobs whereas pipelines are new So so we go for that and we also there's there's always going to be a split I'm going to think that novices most novices in a small installation are going to do most of their admin initially from the GUI But as the installation gets bigger and they get more sophisticated And if they aren't some people are just love a GUI and we'll put up with anything But they're going to want to get into the command line and they're going to want to automate and script it So there's some and for some of these there is a split. I mean within that there's prioritization to You know different But okay, but it would be good to take a slice at some of that It's not I don't think we can come up yet with an algorithm that makes it obvious that okay for this data This is higher priority than that but That's so so well Jonathan to give some I think Let's see. I let's see if I can try with some possible data sources and let's let me test with you to see if You think those data sources would be informative towards you the question. Did I get the questions correct? How do how do we prioritize where to focus our efforts first? Yeah in pipeline school Nothing so not be Yes, I Okay, so simply imagine example for sample If I'm just using Jenkins the first time. So I will just build small Process using freestyle pipelines, but what kind of process? So for example the first Time we just arrived in Jenkins wiki where you go if you are a fist user you are first company user about Jenkins So just for example, you can offer them a two essence. Look if your company are using Janks of their first time Start to just merging your brains for example, or just check out your brains Okay, so step by step go and involve your process moving your manual Manual process to Automatized process with Jenkins. So first Integrate your github second integrate your development server then your staging server then you last time less step of your integration just integration your Production server for simple so we can create a hold month for Guiding through the way or we for that one. I would say I don't Freestyle is never going to go away, but if somebody who isn't used to using freestyle, there's no sense starting them with it It's ugly and it's limited If they're brand new I would throw them into blue ocean Which will hook up the the SCM for them and They can do a basic, you know build test deploy pipeline with that And use those tools and then as they get and from that they can always pop out they've got an editor within that But I think that's a good. I think it's a good starting spot And they they miss all sorts of opportunities to shoot themselves in the foot Now as soon as they figure out what they're doing there, I think they're going to get bored with the graphical Interface want to get to a command line So would you envision that as I was thinking about that focus on the user activity? I assume that might be more tutorial than reference material. Am I understanding what you're envisioning Jonathan, or could you explain a little further? so What specific you want marks place my marks the nation? So so when I think I assume this would mean a tutorial Tutorials that guide them to success Yeah, just not one tutorial a bundle of tutorial Baset on step-by-step of become more experienced when while you are using Jenkins So not a a huge tutorial just step-by-step. So start here go to here So we because we are we already have a lot of tutorials So we need just to organize them in the way J. The user just could Could keep going through the tutorials Okay, so it's I see I think what you're seeing is like tutorial segments where they might be able to drop into a segment use that segment and Succeed with a segment so things like Compiling see a C program Exactly like it like and then start Terry start telling so for some reason you just go into the history That in the day journey So let me give some examples here to test to see if I if I'm understanding what you're suggesting running unit test running tests and seeing Seeing the coverage report Let's see running static analysis And so things like check style PMD fine bugs or spot bugs and seeing the report Yeah, for simple, but just to use in the right order sujection order trajectory order Okay, I didn't understand that say it again for me using Yeah, it's exactly why you are just Right and out. It's just for which suggests for the user read in this exactly order to give more sense for you reading and Exactly I see okay, so so learning paths If we did a learning path kind of thing it would probably be Technology as the uppermost or the the let's call it language language at the at the the outermost wrapper See Ruby Python PHP Because they each have their own their own unique things and then Common life cycle steps or common activities with that language Is that is that am I describing what you're what you're envisioning Jonathan? Yeah. Yeah, it's exactly that Because so when we when I think of C or C++ it's okay compiling That with Ruby there really isn't a compiling Python. There isn't a compile phase It's mostly take it and test it run the test automation. Yeah, but it's just a small difference Okay, so for example compiling it say a one step more step in your pipeline process So if you need to you see and you need to compile your build for example Just go to there. If not, just go through in the main path Because if you we can define a template to guide the writer we can use that template for other language So we just put there some difference between them technologies for some because The same sample you give to us for example, you have compiling program language program and other are just Interpreted but for example, if you I'm just check out for github It's one process if I'm check out for SVN. It's another process, but it's the same activity just the Actors are different Okay Yeah, I think I see your point. So the idea is that if if we have The concept of hey, here's a language if we have a framework that is language Independent or at least somewhat language independent as the as the structure and then when we implement For a specific language we just follow that structure. Is that sort of what you're saying? Exactly, exactly because using this template we can a whole each vision about the entire process Everything it's the same thing just the extra actors are different. I see. Thank you. Okay. Got it So template and then we got what makes me here is there is then So we need a matrix of that as to whether you're using maven or gradle or npm or Well and see for me, that's part of that's part of that's that's actually effectively a language because Okay, maven gradle, let's see CMake I mean there there are a number of npm. Oh, yes npm, right? Absolutely. Yep There's aunt. I don't know if we want to go there, but there's aunt. There is. Yes. Okay Use it all the time Language language or build tool Right because there's golang for instance, which is both language and build tool It's certainly very popular And then there's another direction where you start out This is declarative pipeline and you go into blue ocean and you have a step that echo says here We're going to build our code And here we're going to do unit tests and here we're going to you know, etc And that but that's I mean it's like there's this You know multifaceted matrix of where you get started. That's another piece. They have to get right Point right. It's it's this is pipeline pipeline offering is is a Is a different kind of thing than these right here Here, there are probably many many people who know the language in a team The pipeline learning path is not as commonly not as well known. Yeah, so steps pipeline authoring learning path Theoretically when they come to Jenkins, they already know how to build test and deploy their c app or ruby app or python app Theoretically the problem is of course, they don't always so then we then it gets nasty, but But yeah, the current documentation does just assume that you know all that and then here's how you put it into pipeline It actually for tools you have to think about Scrooge shell script and bat too Oh, yes, right, of course ms build Yeah and each of those has I might put this order because sh and bat are Closer to being stone knives than ms build is yeah, okay But then for prioritization too When we're looking at the reference materials that need to be fixed I mean, what are they like 1700 Pipelines and god knows how many steps that results in Some of them are clearly more popular than others and some of them are have probably been dead for five years So knowing where we put our energy to get good examples and good explanations stuff So that's a that's a another that's I think of that as a different topic on a different sort of question Because I think you're right there are There's so much work that could be done in in reference material In general right so pipeline steps for instance Are the most frequent most frequent requested most most frequent ask for For examples Right. Hey, give me an example of this, right? Clear descriptions of arguments Etc And but clearly some steps need that more than others is what I'm so yeah the commonality was how do we prioritize Yeah, and I think That was where I was initially thinking We could refer to Gavin Morgan's Report of most access plugin pages Great as one as one data point It's not the total answer But it is is is one the other we could we could ask for and I suspect it's in the log somewhere asked for The hit counts or other page statistics For Jenkins for Jenkins.io pages To see hey, which one are they looking at and if we get lots of hits on the github solutions page We should strengthen it if we get very few and we get a lot on installing on kubernetes. We should improve that And then there's the stuff we don't have if we had a good search engine We could track the search strings that were applied that didn't get a good hit Oh, yes. Okay. That's because there is something I mean once I you know for anything I work with it. I get to know this reference page is pretty good So I go there all the time, but I go there because it's good There's something else that I really don't understand, but I've looked there's nothing written about it So I have nothing to hit to for statistics Right. Yeah. Yes. Okay Well, just I just thought about when we were talking about reference materials we had somewhere link to the Priorities in contributing to plugins We have somewhere this link where which said which plugins are Requiring some contributors and don't have maintainers something like this And in general when we're talking about examples my goal is To have something similar to W3 schools when they provide some examples But at the same time in separate window iframe or whatever they organize these days They allow a user who is reading this to try their own version of Of Whatever topic is this Or in this little ways or whatever they are And we have somewhere I guess related to declarative Syntax inside our documentation, but not much allowing user the reader of our documentation to try on their own how It will be implemented. So I guess It's requires some thinking about how to organize and this would be Ideal, of course. I'm not sure if it is achievable at all But I allow a user for instance talking about A lot of pipelines create their own pipeline of freestyle job and Go and see what happens Yeah, well Just just a thought but Jonathan wanted to say something Go ahead, Jonathan Yeah, for example, we talk about this in the past, but I just Given and bring back the topic again. There isn't any chance we we just Start to use for example, Algolia for our page just for improved our Our user experience when searching searching about the topics So for example, I'll go to use a AI AI intelligence just to map all your documentation All three projects around the world are using algorithm in this moment. So for example, I put the link in the Chat so you can just access there We can a free plan to use but for of course, it's a small plan for us. So we need to Find some partners to Just buy to us some for example plan just to use Algolia in our website So there is for example pricing there we we can use more than 1000 Search for requests for free, but it's not And not for us for example. So we need to find a for example Some institution to just to I don't know their work in English to Guarantee the servers for us Sponsors exactly There is some way just to find sponsors to use that engine or other similar Because we lift engine search inside our page that the users can just find what they are looking for Right, right. Very good. So the yeah because to us is simple because we already know our own documentation So we just use cultural f and just shares for things but the Users their company when they arrive in our site, they have no idea. Where is Jenkins pipeline? Where is that tutorial about php or about Java? Where is that tutorial about maven? They have no idea So we need a search engine Yeah, a good good. So as an example that further supports what you've noted there Oleg did a prototype search for Jenkins for Jenkins.io Using elastic search However, as the same exact challenge that I Al Golea does is that elastic is only willing to donate Their search services To what I think he said it was nonprofits and they weren't clear that They were not clear that Jenkins was a nonprofit They could certainly is a nonprofit, but we're not a registered nonprofit in the us legal sense Really at least as far as I know we're not I I didn't know And so it's I don't know what the What the the limitations were there, but but elastic was one That but whoever it is Someplace has to host that search engine, right? There is there is some execution of code there and that execution of code has some cost Exactly And so whatever search service has some costs or For instance, I think a prototype had been done using google search. The problem with google search is if we use google search we risk that Antagonists or What might even be called competitors in get injected into the search results So I would rather not have the Jenkins documentation page Having something that suggests circle ci is a good choice for instead of Jenkins, you know, they've they've been very actively attacking Oh, you should replace your Jenkins with circle and I have no interest in our search results Giving any hint So so this the site search engine feels like another very good topic for discussion at in fact, I think I'm in it. Yeah, so for as a as part of that the government not governance the contributor summit Because I think I think it's this is a Someone may may say hey, I would like to contribute, but I don't want to write documentation This is an opportunity to write some code to contribute towards The to work the project, right? It would it would help just like the rest api generator is a help Good, exactly. And I'm quite quite sure if we use a search engine the experience Just onboarding Jenkins become better I guess, uh, I'll go it's a A good a really good option because all others projects I work on are using I'll go it so I don't know if if have a good plan for institution or It's a cheaper one. I don't know the reason but they all are using I'll go it Well, I guess in this case the proper path would be to write some kind of Jenkins plugin or I'll go there And use this plugin in our documentation for doing search Yeah, yeah, it's something like that right where it's it's a How somebody would have to do a prototype and And see how how the documentation would feel if we're using al gole as the search engine Could could our pages still continue to be the static site that it is or does something else have to change? I think it's an interesting Yeah, it's that the site they use the static sites all the documentation. I just yeah all the stacks Site split markdown. I don't know with A doc a doc files, but the user markdown Why is Jenkins not registered as a nonprofit or maybe it's the foundation cdf Yeah, that's that's a piece that I think needs more discussion. I I I didn't understand the details there and yes that What I think I do understand is a very high. I don't know how these decisions are made but For these companies when they donate stuff They get to report that as a loss on their tax. It's a contribution They get a tax break, but if we're not a registered nonprofit, they don't get that tax break I see. Okay. Yeah. So that I mean, I think it's just an administrative one Now what I don't know at the other end is what the ramifications are for cdf or Jenkins being officially a nonprofit For companies that are then using that as the base and making a profit off it I don't think that the open source stuff has been registered and maybe that we need to have a separate category which you know Don't even think about getting that to do Washington DC right now, but Yeah, don't don't know that's a it's a valid concern But it'd be a good question. It'd be interesting just to ask like Tracy You know just off the top of is it just a matter of file, you know, how would they feel about cdf being a registered nonprofit? Yeah, and because I don't know what the ramification all the ramifications are at that end But I guess one of the advantages would be that Uh contributors Jenkins the tributes can receive some well rewards From sponsors, I mean, I also Jenkins is big enough That it might be worse something to them just that the search engine box says search powered by agolia You know, that's advertising Right and and those are those are the things that we would need to discuss with The provider which one whichever one it is right if we use agolia if we use something else to see Would you sponsors because they They would be providing economic there would be economic cost to them to do it. Yeah, right Well, there's a couple ways too. I mean they could say we'll give you the salt We'll give you the you know commercial software We'll give you the professional software, but you got to find your own servers And google's our best place to go for those but I'm not sure google's going to want to sponsor something that's not using their their search. So right, right The mind boggles a good point beg All right, so we tangled web we weave So we've we've hit our hour I I would generally like to hold to an hour any other hot topics before we close Do we know anything more about the schedule the phos dim schedule like days and hours and the sort of yeah So february so this the contributor summit has now set february 23 through 25 Okay And the first session day one will be I think it was at 3 p.m. At 1500 utc on the 23rd And this one is at 15 on the 25th Okay, the other tracks we will determine dynamically at the at the Conclusion of the first session Which tracks we are going to put people on and what time they will be Okay So and and we'll keep talking in this session. I'm I'm continuing to send invitations to people to Consider joining and leading a track. And so those those conversations are ongoing All right Okay, anything else Thanks, everybody. We'll call this an end. I will do a recording. Jonathan. Great to see you flat Meg. Thanks. Good to see you again. Bye. Bye. Thank you Bye. Bye. Have a good week everybody