 Welcome everyone to the Jenkins Pipeline Authoring SIG for Friday, April 10th. My name is Markey Jackson. I am one of the leads for this SIG. Thank you everybody that's coming. I see we have a lot of names here that are new. And that first and foremost is awesome. I thank you so very, very much for participating. Before we do get started, I would like to remind everybody that the meeting is governed by the Jenkins Code of Conduct, which essentially just amounts to be nice to one another. Don't be a jerk. So I don't have to kick you out. With that being said, I have placed a lazy link in the Zoom chat to the meeting stock. If you could please jump on there and add your name to the attendees list. We do like to keep attendance just to know who showed up and what not. All those fun things. Generally what we do when we start this meeting for the new people that are here, we will walk the meeting notes and cover anything that are on the meeting notes. I usually, we usually turn that over to Liam. So Liam, I am actually going to make you the host. And the reason for that is because that will allow you the ability to screen share. Screen sharing is off for everybody else. Okay. So without that, without taking it away, Liam. Take it away. One second trying to, there it is. So now I'm sharing my screen. And everybody see the blank screen. There we go. Here's the docs. Visible. Yes. Yes. No. I couldn't unmute. Yes, it is good. Okay. Well, the only thing on the list, the agenda for today, I guess the open items was the roadmap. I'm going to ask and it's back to Marky. How to go Marky or is this still something that you're working on this week because a little bit crazy and chaotic for me. I will work on that between now and the next meeting. I have a rough draft of, but I did not feel that that would have been a good enough draft to put up because people would have been like, why are you putting this up? There's nothing I can do with it. So, right, I will have that up before the next meeting. My apologies for not having that. No problem. Right now. Let's see. That's the stuff from last meeting. We can, for this meeting, I guess, talk about items that we would like to see on the roadmap that we think would be good on there. We could also, Craig, I welcome to see you here. And I guess we could talk about the topics that you've been bringing up in Gitter here if you want to do that as well. I don't know if you're unmuted or anything or you have, I can't actually hear you. Okay, you were talking and now I can't hear you. Yeah, I said I'm here. Okay, cool. Up to you if you want to add things. We don't have anything specifically on the agenda for the day aside from, I guess, talking about the roadmap. I'm new to this meeting and I don't understand like how this thing is structured or anything like that. Well, we're sort of establishing that as we go. Okay. The were we've been relatively open ended on things if people bring them up. We talked about what personas, the sort of establishes of personas that we're talking about the same set of users that we're trying to serve with improvements that we're going to make to pipeline. I mean, the don't have it directly in my and I really should the Charter for the for the meeting for the SIG as a whole is to make the experience of writing pipelines better so So who who who define the Charter of the SIG? The SIG was started by Andrew and myself. Andrew Bayer, who was who was working actively on the clear pipeline. And then things got busy and Markey came along and we resuscitated this meeting. So that was the where things where things came from. So from CloudBees perspective, where does pipeline fit into like I'd rather not actually talk about this in terms of CloudBees. This is a Jenkins. I admittedly there are I mean, I'm a CloudBees employee, but I'd rather talk about this in terms of but I'm the only CloudBees employee currently sitting here. So the SIG is independent from that it exists as a Jenkins project. Yeah, but I, I understand that but you can't separate pipeline from CloudBees because Of course you can. Why would you think you couldn't it's it's an open source project. So when you're defining Jenkins you're defining Jenkins as an open source project when you define Yeah, I wasn't finished. I wasn't finished from Craig I was not finished. Thank you. When you're defining CloudBees, CloudBees is a product. CloudBees does not dictate the charter of this SIG and they're very different. So that's one thing I want to make sure that I'm very clear. I'm not a CloudBees employee. The charters not dictated by CloudBees and if anybody tried to dictate that from a company standpoint. My guess is is the board would get involved just wouldn't happen. Okay, so I mean the problem that I have is that this technology was developed by CloudBees employees while they were working for CloudBees and unfortunately, the technology itself is very complicated. And the barrier of entry is very high. So for people if there are people in the community that can come in and keep this going. That's good, but some of the problems that I've had with pipeline that interfere with the, you know, the ability to write an author pipelines. The only people that really have the knowledge to solve this are at CloudBees unless there are people that can come in from the community and maybe be mentored to come up with this. So I mean, sure, if you have a roadmap and everything. That's good, but there are some fundamental problems with pipeline that interfere with some of the charter items. And when the original SIG was developed by the author of pipeline, it was very easy to say, Oh, okay. You know, we can do all these things and work on the pipeline, because like I've raised issues from like two years ago. Well, let's, before we, I don't want to cut you off, but before we dive into the actual issues, let me just address a few of the things you said in regards to the charter. The charter still open in. I'm sorry. Yeah, why don't we let Craig. I'm sorry. I know, I know that it's there's a bunch of things in there, but let's try and keep this. Give reciprocal respect, like you wanted to finish what you were saying, so Craig, please continue. Sorry. So, so I'm not, I'm not against the charter. I'm just raising the issues that I have seen and the problems that I have had and I'm hoping that some of the issues that I could, I have raised could be, you know, acknowledged and addressed within the framework of this SIG, because from my perspective, what I've done, I found problems in pipeline and I've reported the bugs on Jira and, and, and some of the issues they are valid issues. Oh, yeah. They, you know, because of, you know, issues with people at cloud bees, I mean, people have left the company people have moved to other projects. Some of these issues have have fallen through the cracks. And as someone who I don't work for cloud bees, but I use Jenkins heavily. I don't have the technical knowledge to address some of these problems. You know, so that that's the problem that I'm in. So, if I can raise the some of the it like I have I found other issues but the two issues that I raised which I asked to be on the last agenda, right, they were like to what I consider common ones. And, you know, if we could you know have lists of bugs and pipeline itself that are tracked through the SIG, you know, even if they're not solved tomorrow but if there's some you know movement on those and if the people who wrote this stuff are too busy to help, but if you know people could be mentored to help fix these problems. You know, from my perspective, that would be a good outcome of the sake. Okay. So, how do I address so the problem that you're describing in terms of they're not being enough technical knowledge. Or not, we don't have the right people to work on things. Craig, could I ask you to mute yourself when you're not talking just because there's otherwise there's feedback. Thank you. That's that exists in all open source projects. And I understand that that your opinion, from your perspective, there aren't, there isn't enough technical knowledge outside of cloudbies to do this work. I would say that they're that there also isn't, there isn't enough. There aren't enough resources, let's just be more, it's not more general. There aren't, there's less resources than needed. And that's true of any open source project. Saying that there needs to be mentoring saying these are all, these are all good ideas, but they they are predicated on their being more resources from one particular area that you would like focused on this thing, right on the on the issues that you're talking about. I, I'll pick out at least one thing that you said, which is having a list of issues that that are of interest to the SIG that that is a great idea, we should probably do something like that where we actually are gathering, you know, issues in pipeline that are that are high priority or just of interest. Also, having a list of issues that are good first issues for people to work on one of these that you brought up with the need for the linter. That's actually the, and we talked about that a little bit where it's like having the linter at a, you know, a validate now button in the UI. That's actually a really good first issue for as an example. And as, as we said in theater. Yeah, the, the, the barrier to entry is far, especially in working on some of the issues inside of pipeline is far too high. But that's, that's a reality of the situation. Saying, if you're just to, I guess, just what I should do is set expectations. If you're looking at this SIG as a, as a venue to poke cloud bees to do more work that you think needs to be done in Jenkins. I don't know that this is going to be the place for that. I don't think you're going to achieve what you're looking for. So, this is a way for the community as whole to organize and if we find specific issues that we're working on or we need more resources. We'll have more luck getting, you know, resources from cloud bees. If this thing is organized and has, and has figured out a direction and saying, okay, we want to work on this area and this particular technical part is that we need someone from cloud bees to come give a presentation or do something like that. We can probably get that kind of resource but just, hey, cloud bees do more work on this is going to be not, is not going to be a very effective way to go about it. We're not going to, that's not, that's not going to be over as an outcome for this. Yeah, I think I would just echo that, you know, I do not work at cloud bees, and I contributed to the underlying pipeline plugin, you know pipeline groupie workflow CPS, the workflow CPS groupie library, and I definitely sympathize. There's a high technical barrier to entry, and it's sort of involved just getting my hands started and diving into the code base. And I would just say that like from a, as a plugin maintainer to like it's not that no one wants to do this work, right is that there are so many different avenues for potential improvement. I've got seven open issues on a repo I maintain that keeping up at night and it's just, you know, bandwidth is limited. I think from a mentoring standpoint this dig is sort of while mentoring might not be the primary point is sort of, you know, it does that by talking about these issues and maybe if there are people on the call that have that experience of where to look, you know, we can, we can start to do that stuff but I just wanted to echo that it's not that people don't care about the issues it's just, you know, there's hundreds of, if not thousands of open cheer issues, and people are doing the best that they can to prioritize them. I would also like to add to that statement and thank you very much Liam and Craig I do apologize I did interrupt you and that was very very unprofessional I apologize. I would like to add that one of the main things is that if you, if you participate, people will help you. If you and I'm not saying you I'm more saying this in a general sense, if you expect people or it's if individuals expect people to just stop and focus on something else will never get anything actually done and and as the word has been used here it's a volunteer organization. It's not work for cloud bees. So we have to, we have to prioritize what it is we can do it, I will say to you, if you're interested in taking up some of these things, I personally would try to help you understand code base or whatever I can do to make you successful in the sake because the more successful you are the more successful the more successful you are. So, so I will, I will just add that. Yeah, I agree. Yeah, so from what Liam described, I think that is, if the same moves in that direction I think that would be a good outcome for the same because from my perspective, I don't care who solves the problem whether it's me or someone from cloud bees or someone from the community. On the other hand, yeah, I can't expect cloud bees to do anything because I don't have any contractual relationship with cloud bees. So I mean, that's, I understand how that goes. So, but I think that, yeah, if we, if we acknowledge that this is a problem and we want to improve it and get to a better place I think that would be a good outcome for this thing. There we go. I forgot I was muted. So, I'm going to just take a couple of notes notes. Get there. Let's see. Direction and origin. And so correct just to be, when you say that what what that review, were you affirming. You said you said two things. So the thing that you expect that you can poke cloud bees and get them to do things. That was not it. So the other thing that you mentioned, which is, I'm asking you to help me so I can type it out. I'm going to invite a venue to bring up issues and ask for help from technical domain experts to mentor and help fix the problems. Like whatever you said that was. So, so, um, I think. So the way that I'm looking at this, let me just see. Here. These are so the focus areas for the most part in here have been our more around. Kind of the how and like, okay, how do we, how do we do this? How do we do that? I think what. I think we probably need to add one more item to this to say that is what you are talking about here is. This being a venue to discuss pipeline related issues and technical and share technical expertise. Okay. I think that sounds right. Yeah. I mean, I do apologize. I do think if you go back to the, to the actual landing page, does it have a think if you go to the bottom, I vaguely recall communication. Okay. Yeah, but like, so this is okay improving and curating. So that's, that's fair. I think it's just it would be. It might be helpful to add, add this so that we're, so that we're talking about the same thing so that because I think part of what happened, what has happened with, from my perspective, with Craig coming in and asking, asking about these bugs, was that there isn't all we were able to say was well that's not in the charter, right. And what he's asking if, if we say well, if instead what we hadn't if we had something in the charter says yes, you're we're totally on board with people asking about technical issues and pipeline and getting help with working on them. Then that would have been a more satisfying outcome for Craig and would have been more inclusive, but would allow to give us a given us a scope of how we could help address like include Craig and his, his perspective. Right. The things that he was asking about. So a common thing I think one of the risks of opening up bugs is that it can quickly consume the entire meeting but one thing I try to do on projects that I'm working on and my job is, you know, dedicate a particular percentage of capacity towards like SRE or continuous improvement. So if we were to expand the charter to include something like pipeline bugs, we could also include like to ensure that we keep making progress on the experience of running pipelines, we're going to limit the amount of, you know, bandwidth or capacity in this meeting to a third of the meeting or one meeting a month is going to be dedicated to bugs or something like that so that we can include it, but scope it in a way that we retain some primary focus on experience. That idea. Yeah, that sounds totally fair. Because you're right. As you said there's thousands of bugs. We could spend all day, all meeting every meeting talking about bugs but Yeah. Okay, cool. So I just ask a question. Craig, would you would, if we thinking about that. If we had, say, one meeting a month where the meeting was just, you know, a focus where we kind of like, I know in other communities that I'm in we have something called walk the board. We could do that once a month where we'll actually go over whatever the project board is or whatever issues are open in Jarrah what I mean in Jarrah get up. If we actually did that once a month would that be, would that be good. It doesn't have to be once a month but it could be like at some time interval. I mean, if it is, if the, if the charter of the state could allocate some time and resources to tracking these issues, I think that's, that's better than what is there right now where issues basically fall through the cracks for years so that I just, I want to be sure that we're clear on this though tracking it doesn't mean that they'll get worked on by this by the people in the six things that will track them. And, and, and so that if someone wants to work on the committee and will help at least provide some like, Oh, okay, you'll need to look here here and here to work on that or something. Yeah, yeah. Okay, I mean providing some attention, rather than no attention is an improvement in my opinion. So what interval we do that. I mean that that doesn't have to be once a month it can be like whatever works for the for the same. So, so, I mean, I guess, Martin, the question here is, does anyone object to this to adding this as part of the charter as one of the items in the charter. I don't object. I'm a plus one for doing it. So, doesn't sound like it's objection so yeah let's okay this sense. This is this will help I think in the future so cool. And maybe that's okay so my background is in test, I would like to take on the task of creating something in our Jira in the Jira that has a list of pipeline bugs and a way to sort of say here's the things that are great are at least. I mean, it's going to be a huge list but maybe there's some way of organizing them in a way that that will help people find the find bugs to work on. So, that sounds good for people I mean like that's. Okay, cool. Not just create but organize. Thanks. Cool. All right, great. Anything else. Any other other topics to talk about or do we want to people have things they'd like to put on the roadmap. Yeah, the reason I'm in this meeting is because I was trying to figure it with a roadmap of the Jenkins pipeline is, I couldn't find that on the websites at all. So I'm going to come here and ask what what the direction is. And the reason I ask is relatively new to Jenkins myself, I've been using it for a couple of years now and started with the declarative pipeline syntax, which I think was very near the time. And very quickly after getting started realized there's declarative syntax and there's this other syntax, which is older and supports more features. You know, there is little clarity and around which of those syntaxes is preferred, which one is going to be the chosen one in the future, who should be using what that sort of stuff. So it's hoping to get some sort of idea from this group as to what they see is the future of the Jenkins file syntax vis-a-vis the declarative syntax versus the older syntax. So what's, I guess, the older syntax exists, the newer one, the declarative, I'm not sure. Can you expand on that question a little bit? I think he's asking about scripted versus declarative syntax. Right. Yeah, that's true. What about it? Well, I think a lot of the newer examples use declarative syntax, but there's a lot of things you can't do in declarative syntax. So as a person trying to use Jenkins, you get so far using one syntax and hit a wall where you end up copying and pasting a whole bunch of things instead of creating functions. And I have to fall back to this other syntax, which is similar but different. So it's not a particularly good experience for users. One of the things that we were doing early on and is we started creating personas and in these personas, we're trying to, we're trying to, by using a persona, address a person where they may be coming in from. Like your entry point is I'm sort of a new user, but I'm not, you know, like, you know, I know what I'm doing to a degree. And now I'm seeing some deficiencies and I need a little bit more guidance. And that, and I'm sort of not quoting you but just saying in a high level. And that's what we're trying to address on the personas because the personas will match to what we're calling a maturity model. And then we're trying to match that to our documentation so we can see where the deficiencies are. And we have in some of the earlier notes you'll see where we have the persona creation and then the mappings to the maturity model and then we've had the doc sig in here, who was also trying to help with getting the documentation linked to those certain things so we are trying to address that. I definitely know where you're coming from completely. Is the focus there around keeping what we have an improving documentation, or is there actually intention to like add more advanced features to the declarative syntax and encourage people to use that over script pipelines. And there's so that they're the docs protector they're talking about documentation. But the question is always from my perspective is always, what can you give me an example of what it is that you're talking about. Because, yeah, so I can think of two specific examples using declarative syntax where I've run into issues. One is like each of our stages has a post action that happens. And it's the same for each stage, and it's maybe five or six lines or eight or 10 lines. Right. And if we have six or seven pipeline stages that I'm going to copy and paste it. And as a developer, that's taste bad to me. Right. And then the second one, recently we had a single pipeline stage and declarative syntax that we wanted to run across multiple nodes in parallel. And again, relatively easy if you just copy and paste the block and stick it in a parallel declaration. But again, you're you're copying and pasting your knots. There's no language feature in the declarative syntax that allows you to express repeating something. So, so this is probably a documentation and communication failure, but matrix actually does allow you to do that. And if you haven't played with matrix yet. You could add you could that says that is exactly what it's for. So, but the fact that there hasn't been more sort of communication of that feature and how it works and what you can do with it. That's at least some to some degree on me. Yeah, I will definitely check that out. I would a lot of switching didn't find anything around how to run stuff in parallel except falling back to scripted pipeline. Okay. Yeah, if you can. So, good, good point. Okay. All right. Thank you. I would take a step back and just talk about the difference between scripted and declarative for a second. This is disclaimer. This is my perception of the two features. I definitely don't speak for the plug in maintainers at all. My, my understanding is that declarative is intended to be easy to validate and easier to write right it's not a programming language necessarily it's a spec, a data structure that can be easily validated and have some functionality and then scripted exists for some more advanced use cases. I think under the covers declarative syntax and scripted syntax are invoking the same things it's just different facades for for interacting with them. Right so to me that they both exist in parallel to support different use cases. So it's not really like a one is going to be more supported over the other. It's more about like how advanced of a pipeline or how complex of a pipeline is probably a better, better phrase on how complex of a pipeline are you trying to write. And if you need to do things like looping and things like that that you would typically do with a programming language scripted is going to be a better fit. If you just want to like run a bunch of make commands and maybe spread them across agents and have some post blocks and declarative might be a better fit. And I am very open to feedback if that is anyone else with different perspectives on the two there. Yeah, so my my perspective is a little bit different so how I saw this stuff evolve. I actually I talked to Andrew Bayer like very early on, even before like declarative pipeline was around and he had a earlier. Earlier prototype called plumber where you could specify a pipeline in YAML. And then that that kind of didn't go anywhere but basically scripted pipeline was the first implementation of pipeline. And then the declarative pipeline came after that and the idea was that declarative was a easier and easier and more intuitive way to write a pipeline, but still reuse all the same code and construct so it's like a deal it's like a restricted DSL that that tries to make a pipeline more readable, but I found when I've authored pipeline when I tell new people I point them to the new stuff because it's a little bit more easier to follow. But I end up using the script tag quite heavily to and to me the script tag is an escape patch because the the script tag. Basically, it doesn't mean what you think it means like a lot of people think the script tag means all I can put a shell script syntax in here, but it's not the script tag means you can use any groovy construct in that script tag. So what I end up doing in a lot of pipelines that I've written is I start out with the pipeline and the restrictive DSL but then I use the script tag to do more Cody kinds of stuff like loops and defining variables and things like that. So I mean, there was the intent of what this stuff was and then there's actually what you end up doing to actually get things moving. And what I what I found is that I kind of straddle both things where I use the declarative pipeline but then I use the script tag to do like more programming language kinds of things in there. And maybe that wasn't the original intent but that's kind of what you have to do. So one clarification I would make just in cases, you can't use technically any groovy syntax Jenkins under the covers leverage is something called continuation passing style. So the Jenkins pipelines can resume the implication that that has on the code that you write is that everything has to be serializable, because it's continuously writing the state of the pipeline to disk. So that common bugs that can come up where you write what is valid groovy code, but when you run it on Jenkins it, it causes some issues because the objects you created weren't serializable. It's definitely a nitpick but I've hit that many times so I wanted to throw that out there. Yeah, that's a very good point you brought up to comment on what you were saying earlier Stephen around the use cases for scripted pipeline versus declarative. I think that's a good way to look at it, but in practice as someone who ends up writing these pipelines for our software. You start off with declarative because it's simpler and the current documentation sort of pushes you that way. And then you have a simple pipeline because your project is simple when it began. So as your project grows, your continuous integration requirements or deployment requirements, expand, and the, you have a pipeline written in the declarative syntax, trying her needing to and having to transition to a different syntax. As your project scope expands is is not easy, especially as the two syntaxes are like they're somewhat similar but they're different. They're more difficult than it needs to be. And I think it's very common for people that they will start out with one and end up meeting the other. So, coming back around. I noted that matrix is this button in a piece to find for some of the some of the scenarios that it's that it really actually does apply to. The way that I have with the documentation matrix, there probably needs to be something more added to it to say hey to the, to the parallel section to say hey, if we're trying to do this, go over here, you can get that. But the other, there's two things that I want to bring up here. One, the consensus seems to be oh yeah you do declarative for the simpler things. And then when you, when you grow up and and and are ready to take on the real thing you go to the script and Yeah, that's not what that's not the design intent. In fact, the intent has always been for declarative to some it's similar to the now declarative and solution were created sort of side by side and the descriptions are actually very similar declarative is an opinion native way of going up of doing pipeline and for me the main thing that when people bring up oh well there's something that I need to do but I can't do it in declarative. And my question is what is that because there's we as a sort of a short like okay I'm just going to fall back would be put something like for the case that you mentioned, which was, you have the same five lines need to do a bunch of different places. That's what shared libraries are for. But I'm not, I'm not completely satisfied with that answer. I mean, that's an answer that I have to give because that's like well, if you need to do it. There it is. But I, I'd like to see that addressed more locally or the ability to address something like that locally, right, within your Jenkins files you're not having to go out to a shared library could completely separate repository just to do some basic code reuse right. So, and in fact I've even reached a point of like, okay we don't have the original version of original releases of declarative there was very much a no we're not going to do variables. And I'm like, yeah, but there are cases, you know, where it makes sense. And it's not an easy the thing is it's not the easiest thing to solve within the, the structure that we're trying to establish and the, the on the flip side from this when people say well I can't do x in declarative the some of sometimes that x is stuff where I have to say, why are you doing that in your pipeline. Yeah, you can do that inside of Jenkins. But you have to understand that you're not that you that you're doing things that are actually more expensive inside of groovy and inside of the CPS framework and you're running them all on your master. It's maybe not where you want to be doing that. So, there's sort of a two sided thing one is, yes, let's push the boundary of declarative so that it hits hits the right mark of complexity and feature set for what people are doing in pipelines, but and at a certain point, I am I'm sort of as the main the main maintainer right now, sort of continuously asking myself, where the where the line is that we should stop. Right. And when people go over that having to be having to go. Okay. The reason why you're ending up in scripted there is not because we have a gap in our features that we want to fill, but that you're trying to do something that we don't want to that we actually don't that we actually want people to discourage people from doing. And that's not clear right now what that line is right because it's continually moving there are definitely gaps. But I want to hear about them and we this is another example of like, we should have a set of, I'm hoping to put this together as part of the stick a set of items on the on the road on the road map that okay here's what we're going here's the gaps going to fill. And then, when people then after those, we should be sort of pushing back on people to go okay. No, don't do that. Right. But I Michael I sympathize all the points you have brought up are valid. I have encountered these things myself. And so, you know, keep keep bringing up these points one thing that I would maybe recommend. And I've done this myself when I find weird things and pipeline that I don't understand. I ask the question on stack overflow. And then if I find a solution or someone else finds a solution I post that solution to my question on stack overflow so at least I have that, you know, documented somewhere. You know it's not ideal but it's better than nothing because I understand for people who are working on pipeline. They're usually under the gun on something that you have to get done. And you don't you don't want like the technical decisions about okay this is an opinionated implementation or whatever to get in the way of what you're doing. Because I mean it's not your problem that was something decided by someone else a long time ago, but you know, do do raise the issues. And if you find solutions to your problems. You know put them somewhere where other people can benefit, because I use Google a lot to, you know, and I looked at stack overflow a lot to ask questions and also find answers to questions that I have about pipeline. We are about 10 minutes. I was just gonna say I just imagine an equally interesting and horrifying idea of being able to do something like go templating for your declarative pipelines to be able to augment your declarative syntax with some of those more scripted functionalities but please do not actually implement that. I'm envisioning a whole bunch of like ghost group templating everywhere and just horrible and everybody's like, why doesn't this work and those are things those are nightmares like I don't want to have. We'll use Jenkins for that too. It'll be one Jenkins job that builds a Jenkins file and creates a new repository as it to Jenkins. There you go. Yeah. So we're about 10 minutes out. It's a great conversation. I think it's very important to this SIG as well as the overall community. Does anybody have anything else. Yeah, I have one thing where the meeting minutes posted because I couldn't figure out where to find them from the website. In this in this zoom chat is a link to the docs also in the getter room before every meeting I post a link to the minutes as well as to the zoom link for the meeting. Can we you add a link to that on the web page on the yeah on the sick page. Not there. Or is there a reason not to. So it renders it very weird. That's why it was removed somebody actually complained the way that the doc the link in there I think is fine. But the way it got it rendered the Lincoln in the actual web page so when you were scrolling you hit the dock and then you're scrolling through the doc. So I took it out in the past. Oh it embedded it. Yeah. Oh, yeah we can figure out a way to a better a better way to do that. Posting a bear link there's a way to there's a way to do it. Okay, my only thought would be with that open us up to some random person finding the links and then being able to go ahead. I mean, so Craig let me ask you a question is there a reason that us posting the notes in the are or a link to the meeting notes in the getter channel is not sufficient enough. It's useful to go back and see what the minutes are for people who don't attend the meeting so would you just not have that bookmark somewhere I guess what we're trying to do is limit. So in your original you had asked and get her to have this information put at the top of the topic of the getter channel. The reason that I find that difficult is because now we have to maintain multiple places where there's a link to the doc or documentation to something in the calendar invite, which is on the Jenkins community event site. It has the link to the dock in the calendar invited. So as I'm trying to avoid it. If a doc gets messed up and we have to switch or the zoom link we have to change. I don't want to have to do it in multiple places. That becomes unmanageable. So I think is is Liam. Yeah, I've looked at like the user experience sake. They have a link to the meeting minutes. So I mean, yeah, I mean, and what I'm showing right now is actually the problem the problem that marky is the meeting agenda is right and this this sort of embedded in the in the page. So, but we can, there's certainly a way to do that without actually, and it, I think it actually is right here and you can click on this. And it'll take you to the thing rather than there's got to be a way to have it not embed that. So is it is not my question is it not okay just to have it in the calendar invite, which is on the events page because again if I put it in multiple places and something changes. Yeah, then that means somebody has to be responsible to go to multiple places to make the change. And that's what I want to avoid. Fair enough. Let me think about this for a second. I just got pulled. I'm just following sort of the consensus. You know, I think if we can the link to the document I mean you could always post it. Figure out a way to post it as a tiny URL fix it. Um, so that it redirects automatically should go and redirect it from one place that if it really matters in that respect. But I think we should try and follow some, you know, the consistent behavior from other things. So, seems like and it seems like that's this posting the agenda in some form. Some of them are embedding it by doing PRs, even so I think the link is probably a reasonable choice. It just lets people see the history of what we've talked about more easily. And even if that causes something, it's probably worth doing. Okay, I'll take that action item and I'll work with you on it. Great. Thanks. Future caps. Okay, great. I'm just finishing up this note in terms of things that weren't discouraged. And the point there is that we just need people to keep talking about them. So, all right. Anything else. This has been a really good meeting. It's been a really good discussion. Great. Does anybody have anything else if not, I will give everybody five minutes back. Thanks, everyone. Thank you. Awesome. Thank you, everybody. I will go ahead and stop the recording. Thank you. Oh, wait, wait, Liam, you have to stop it. Okay, stop sharing and save it to the cloud. Where do I, and okay, stop the recording.