 Welcome, welcome, welcome to the Pipeline Authoring SIG. This is January 31st, and this is the revitalization of this SIG. And I'm Marky. Everybody else is online. I think we all pretty much know each other, but for anybody watching this recording, we meet weekly. It is on the community calendar. We do post a link to the meeting notes in the Pipeline Authoring SIG getter channel. So we welcome you to join. Welcome everybody. Happy Friday. We made it, barely. Some of us are just struggling to get over the finish line. I myself am one of them. All right, let me see. And I will look, oh, you wanna go ahead and share? I can be the one driving at least trying to. Beautiful. What I do ask is, can we get a note taker? That's me. That's what I mean. No, okay. Okay, perfect, perfect, perfect. I'm gonna shut up, then. Put myself at the top, haha. No. You are the leader. Put yourself on top. Whatever. All right, so last time we were talking about what we wanted to do. We wanted to discuss. We were sort of spinning back up some of the old notes and getting sort of trying to figure out and I think we're still gonna be doing this this time what we wanna do. These were the open tasks. I don't know, Marky, I felt like you had the, actually you and Steven both had much larger tasks to do in terms of what to do this time. So did you get around to creating a persona doc or? I did not create the persona doc. We'll just pull that into that. I have it privately set up. I will have it ready for public consumption by the end of today. Oh, okay, okay. And I will share that link in the getter channel to that document. All right, let's see, yeah. All right, so all business. And Steven, how about you? Did you start thinking about this? Do you have something to talk about to sort of show us? I definitely started thinking about it. Didn't create any artifacts for it. Okay, okay. I think that actually ties into what we were talking about last time with the charter and talking about the high level grandiose vision. So yeah, I certainly have things to say, but I think it's probably gonna be a lot of the recap of what we talked about last time. We have a new perspective on the call today, so I'd be interested to hear from the Jeff thoughts too. Yeah, so I'm hearing the echo again. So if I understand correctly, I think this may be actually something I've thought a lot about. One of the problems that I'm running into in the workplaces, although the company has spent a lot of time and expertise learning Jenkins and in particular I've spent time becoming a contributor, people think that writing pipelines is hard. And so they're talking about moving to things like CircleCI or TravisCI, just because I think Jenkins is hard. And first of all, I mean, my first thing is, okay, so you're trading one set of problems for another, but the other thing is, I get asked to help a lot on pipelines and a lot of the things people are complaining about are of their own making. They create like these monstrous, you know, multi-level libraries and things that are hard to understand. People leave and nobody knows how to work them. So I've been trying to think of ways to guide people to making that easier. Is that kind of under the charter of this group or am I misinterpreting? No, I think that's fair in this. Yeah, absolutely. So, yeah, no, that's exactly what we're, and partly we're trying to figure out what our charter is and how much we wanna take on, but that sounds square in the middle of, yeah, how do we make it easier, right? So my personal thing is to make it less likely that people will want to leave Jenkins just because they perceive it as harder than it is. Right, and I think we were talking, I mentioned last time, one of my things is like, hey, can we make that on-ramp smoother so that people don't think Jenkins is hard? Now, the weird thing is, now, I don't know if you've seen this happen, but like I find that, like, yes, CircleCI is like, oh, it's super easy, and then they start trying to do things and they can't. The issue is that we sort of, Jenkins as a whole sort of throws all the complexity at you at once, and so you end up feeling like it's harder than the other thing, but the other thing is just as hard once you try to do the thing that you're trying to do. Yeah, yeah. Yeah, it's like not a level graph when you talk about complexity to ease, right? With Jenkins, it gets easier as your, you have more complex situations and that's where Jenkins starts to shine, right? CircleCI or Travis might be ideal if your pipeline is run one command or something, but the second you need to start interacting with external resources or dealing with multi-component applications, that's when Jenkins starts to really shine. So that's on-ramp that we talked about last time, like digging into that a little bit. I'd be curious what you think the, sort of the beginner level steps to that on-ramp bar, like what's the most basic pipeline you could introduce someone to, to show them how Jenkins works and what are the step functions to build up that complexity? Right, I think a lot of the time, I think a lot of the time the challenge is that people don't have a good mental model for how Jenkins works or how pipelines work. So when you throw them into it at the beginning, they sort of feel like they have to know how to code and they have to understand what steps are available and how to figure out the syntax for them and there's all these challenges. So it's really about like, how do we help them build that mental model and then what are the steps in complexity to introduce people to in what order so that they gradually get more familiar with it? So one of the suggestions that one of my old managers had that he thought would make Jenkins easier is if there was a set of samples for building different types of things and maybe there is, but like, if you could go somewhere to a repository or some documentation and it says, okay, if you want to build an NPM project, here's what you do. If you want to build a Go project, here's what you do. If you want to build Java, here's what you do. And as a starting point, he felt like Travis in particular does a good job with that. And I did, when I looked at Travis, they did seem to have a lot of documentation around how to just do basic things. I know there's a, go ahead. No, no, go ahead, Marquis. I know that in the other SIGs, especially the doc SIG, they're doing a lot of work in refining the docs are, how the docs are laid out. One of the examples you gave, for example, like NPM, how to build a sample NPM project. And there is an actual documentation on how to do that. I think what happens is most users will come in at a beginning level and do these beginning sample steps, but quickly go to intermediate. And there's no good handoff documentation wise to show how to go from beginner to intermediate. Okay, great. I can now set up a basic NPM project, but now how do I add things to that project? There's no good way to do that handoff. And I find, especially in a lot of the questions that get asked in Gitter, that's what's happening. Like, oh, okay, I followed this, but now I need to do this. And then that, and I think, I think everybody kind of knows what specific example I'm using, but what would you say to that, Lin? Sorry, I was laughing because I'm thinking of this happens all the time. So you have the on-ramp and it's basically just like the movie speed, right? Here's the on-ramp. Oh, it's missing this middle section. You have to jump the bus across. And who knows how you do that, right? Well played, well played. Yeah, right. Sorry, you'll see me laughing like that all the time. I mean, so I've had to write a lot of learning labs for various frameworks that I'll maintain. And what I'm finding is that people will walk step-by-step through documentation to get something minimal working without pausing to understand the steps of what's going on, right? And then they get to an end of it and they have something that works, but they didn't actually learn the basics that the documentation was trying to teach you, right? So whenever you have copy and pasteable working examples, people copy and paste. So maybe it involves restructuring the docs so that you explain a step and a syntax. Maybe you hide the end result of what's going to get copied and pasted and encourage people to actually build it themselves with a fallback of if you're stuck, here's the working solution. But if someone sees something they can copy and paste, they're gonna copy and paste it and then figure out how to modify that, right? Which speaks to the fact that people are struggling to build mental models because they don't understand yet how all the pieces they copied are actually working together. I'm wondering if it makes sense in future meetings to actually maybe skip, like maybe do one meeting a month where we do like a walkthrough and encourage people to come like, hey, we're going to show you how to build a go job and a pipeline. And I bet you we would get a lot of people that would come to that. We could even do that as that. I think I like that idea. I think we should, maybe this group can sort of do that a little bit. I don't know that we're trying to get a ton of people into the SIG meetings exactly. I think that would be something that we would sort of like, okay, let's run through this together and see how that works. And then have one of us go to the, like go do a, sorry Jenkins on my meetup or something where you actually have, and then run through that again, right? For a larger just audience, here's the example, right? But having this group's like be part of the engine that generates the docs that we're talking about, seems great to me. And yes, having a video would be great. I think it'd be really interesting to find someone that's looking for that help and have them go through it with us sort of watching. Like I would wanna see what approaches are they taking to doing it and where are they getting stuck? Right, if we're talking about this from like a user-centered design perspective and we wanna do interviews with our stakeholders, like we're almost too familiar with it to know what knowledge we take for granted, right? So seeing a beginner tried to work through it would probably show us a lot more about what the challenges actually are. That's a really good idea, right? And you're exactly right. I mean, I've been using Jenkins for so much that I probably can no longer judge what's hard about it, right? I just know that people find it hard. And that'd be great data. I'm also wondering, I know one of the things that we talked about in our last meeting, which would be good towards personas and the charter is to get a survey out and to really start to get a pulse on what the community is having. And you know what? I'll tell you what, you could put an action item for me. I will draft up a survey and then I'll give it to the team to look at and we can see what's good and send something out. I think that will be really good too, to start getting the pulse on the community. I like that idea. I want to kind of drill in to the specific information we want to get from it. Do you like what parts of Jenkins are hard? Well, what are your thoughts? Well, I would like the survey to be centered around pipeline and specifically using the pipeline because at least one of the goals that I have for this SIG is to start to be able to generate items that people are able to use and find value. And that's something where we're trying to help author for them. So I would love to be able to have data to know that we're working in the right direction and not just it's for people who know Jenkins really well. We take advantage of some of the things that we find hard that other people may find that's completely out of the realm of my thought. Okay. And so that's something we would post. Where would we post that, like the dev list or? So that's a good point. I mean, we've had surveys for Jenkins as a whole. And one of the general things with Jenkins is that the vast majority of users are silent. And there isn't really an easy way to engage with them. So. Yeah, like if we had to break down a pie chart of the challenges that people are hitting, how frequently is it that they misunderstood the pipeline syntax versus an infrastructure related problem of they're trying to do something with node but their build agent doesn't have node installed? Or like in my experience, a lot of the challenges people are running to are more platform related than actual pipeline code related. Have you guys had a similar experience? So I kind of, I see two things. I do see that a lot. I mean, people are like, oh, Jenkins is broken and then you look at it. Well, Jenkins just runs tasks, no Jenkins isn't broken, you're misconfigured. The other thing I see is people not really understanding all of the things that Jenkins has to offer. Like I see people instead of using credentials, they have an environment variable that has user and password in it and their jobs. They just don't know that credentials exist. They write code to make REST calls to Slack because they don't know the Slack plugin exists or they don't, or they just like, they build infrastructure around sending Slack messages when the plugin can do that. Those are just a couple of examples I've been collecting on. Somebody was like using Curl to do REST things because they didn't know that there was a plugin that lets, so a lot of us just, people just not knowing what's available. And I don't know either, but when I want to do something new, the first place I look is the plugins for the plugin site. So just people just- As a maintainer? As a maintainer of plugins, I have a love-hate relationship with plugins. Uh-huh. And to touch on what you're talking about, Jeff, the reason that I do is I find, and especially with your Slack example you gave because I've had this happen. Uh-huh. There's a reliance on a plugin and I think a lot of people don't understand that that plugin is maintained by volunteers. Yeah. And that means it may not be up to date. So I have found that in my personal professional dealings that I like to write something out code wise and not rely on a plugin every time, mainly because if the plugin fails for some reason and people have gotten used to the functionality, I need to be able to give that back to them. Interesting. And not have to go write code for that plugin. So a good example would be the durable task and how that sometimes breaks the Docker agent. So using a Docker file, and I think the 1.33 version has fixed that, but in the 1.32 I had a full community that could not use agent Docker file. And so now they had to resort back to using native Docker commands in their Jenkins file. Gotcha. To watch the complexity of people that were just struggling to write these things natively because they had relied on a plugin for so long and it was doing these things for them under the hood was a real good lesson for me to say, well, plugins are great. We also have to make sure our community understands how to not use a plugin because there may be a time that they need to do that. Did that make any sense? What I said? Yeah, no, as someone who's maintained a Jenkins instance 14 like that, that's exactly the same philosophy that I ended up with where it was like, okay, I could do this with the plugin, but because of where we're at, I'm not going to because I need this feature or I need people to actually know how this works or I need to know how I need to have more control over it. I had a conversation with you this week, Liam, about something where I was like, I could use a plugin to do this and I might be able to, but if that goes south, I have to be able to know how to do this natively without that plugin. Yeah, but part of it too is not just the fact that they're doing it outside of the plugin, but if you set programmers that know a little bit of groovy to the task, they just create these monstrous hierarchies of infrastructure around something that could be one line. I could probably find some examples, but again, it just goes back to people making it harder than it needs to be. They're over-engineering. Well, that goes also to- Being an interesting channel to do like SIG oops, like we find those examples and we walk through how to maybe refactor it to be a little bit easier. Yeah. I'm still going to start using that hashtag now SIG oops. I wonder if that domain is available. I'm sure it is because it basically looks like a typo. So going back to the charter and the personas and thoughts about doing something like that, I think before we can do a charter, we have to have the personas because the charter has got to be based on that. Okay. Did you guys discuss last time like how many personas you want and what sort of what different levels they'd be? Or is that still open? That's still open partly because I think at least for my part, I basically wanted, I was waiting, I figured Marky could do a bunch of work and then I could just come in and be super mean about it. I like it. Yeah, that's nice work, man. We're just going to, So, no, but I kind of like, I work better when someone else sort of says here, like even, even a slap on the slap, the paint on the wall kind of thing. And then we can kind of discuss from there. That was my, that was my intent. No, I think it's a good one. I will have the personas initial draft of personas published today. Okay. I didn't like it. I'll have it in a document. Yeah. And even if you, even if you don't feel like it's in great shape, it's better to just have something that we can sort of play around with. Agreed. Agreed. That'll be out today. Okay. I won't even worry about putting that on here. That's the thing. Put that in there. Nope. I started to write it and didn't get to it. Okay. Actually, no, it's in, there it is. Cool. Um, so, and I think those personas are probably also, we'll also tune what we'll want to do for survey questions. Right. Agreed. Can you also change the persona owner to me? Oops. See groups. Yeah. By the way, see groups.com is available. It can be yours for 1199 the first year. Alrighty. I'll pass though. Okay. Um, I'll pass though. Okay. Let's see here. What else? Uh, so just as long as we're chatting. Um, So Jeff, you're talking about the, the sort of the crazy. Groovy things. This is one example of, of. I wonder whether or not moving, moving, not moving, but basically providing people with a YAML version of the, the declarative syntax. Would, would make them think more in terms of, think less in terms of it being groovy, but I don't know that that would help because we're still, we still have shared libraries where it's like, Oh, you can do this thing. And it could. I mean, I was actually hoping that declarative would, would solve some of these problems, but unfortunately it, it doesn't really because you're still able to do fancy things in it. Scripted. But, but yeah, putting in YAML, maybe. Well, the YAML would make people really think about it as not. Groovy, right? Um, Maybe. Yeah. Maybe the. I'm not taking notes of this, but maybe the other thing that might be interesting to do is, um, So we have shared libraries and people aren't clear that they occur on. That they run on your master. And they, they take up resources there. Um, Most of what people do in that context. Is. Could be done anywhere. Right. Like if you're talking about, Hey, I'm, I, I'm going to write myself a slack. Step. Right. Um, there's no need. For. For that to happen on master. It could happen anywhere. Right. As long as you. As long as you pass the right information, um, Then, then, then you're fine. Is that fair? So, so I didn't actually know that. So every, All code in a shared library runs on the master. Yep. Um, Everything that's not in a specifically in a step. Um, that, or specifically in a step that, that is, That is designed to run on the agent. Is running on master. Okay. It's running in a sandbox on master, but it's running. It's, that's why we have the security plugins and all these, Some of these other things where it's like, you, You, in order to sandbox this work, You have to do all this work to get it to. Um, Sort of be able to run in. Process, but not have access to everything. What, what, what sort of ties into the idea. Uh, I was just going to say that kind of ties into the idea of like a static code analysis for your pipelines. Which would be a pretty. Uh, easy thought, never the right word, but a simpler check than others to see if it's encapsulated within another. Um, So, When you have like distributed files, right now it's, You don't know where that method is being called from or, Or something like that. Actually, maybe you're not clear on this. Just because you're inside a node block doesn't mean your code is running on the, on, on the agent. That's fair. What prevents it from, What prevents it from running on the agent though? I want to make sure I understand this. There's nothing that specifically prevents it, but the, Hmm. Historically, maybe it's the way to say this, uh, the way that, that people have treated this is that like, Oh, so I'm running this code. So I have access to, For instance, credentials and all these are the things. Right. All the things that are in that are on the Jenkins master. Including like, Oh, hey, what other jobs are running? Or if I need to do this thing or that thing, or, Or a bunch of environment, A bunch of context from Jenkins, right? Most of the time people don't think about it. Or like what I've, I'm sure you've seen people do some insane, you know, For loop crazy stuff inside of their inside of a node block. And they think, Well, obviously that's running on the nodes. Like no, it's not. It's not running on the agent. It's running in master. And you're just doing a bunch of work while you're holding on to your agent. The worst of all possible worlds. Exactly. So there's nothing, There's nothing that specifically stops it except for. The hundred million gotchas. That about around assumptions, right? About like, Oh, I'm going to run this thing. And I expect that this variable that I, that I declared at the top of my pipeline is going to be there. Well, it wouldn't be there if it was running on, on the agent. Unless we do some, some degree of marshaling. And there's a bunch of other work there. Right. But, but you can have shared groovy that experience. Right. I mean, I mean, I mean, I mean, I mean, I mean, I mean, I mean, I mean, I mean, I mean, I mean, I mean, I mean, I mean, I mean, I mean, you can have shared groovy that exposes a step like I'm thinking about the build, the build plug-in step that that we use to build our plugins. Does does that actually end up running on the agent? They must. It basically it's a step that returns a pipeline. I'm not sure. So some of it has to, because it, it runs on like, Yeah, yeah. So basically the Jenkins file for most of the plugins just has one like one line in it that says build build plugin. I think it is. Oh, okay. So that's not a step though. That's, that's a shared library that calls that is still running on master. Eventually there's that that that turn if I want if you want to go pull that up but basically that that is that's a shared library method. And then that gets called and then that runs some some code and eventually that calls some steps that do like something on agents, right, but okay, maybe it's worth. Am I, we might be getting a little in the conversation. Yeah, yeah. So my, my, my reason why I'm at the reason what I was going for here was like, most of the stuff you think is running on the agent is not. And, and some of the insanity that we could we might be able to address some of that insanity by saying, Okay, everything inside this block is going to be run on the agent and that, or, or something right and it doesn't have to be groovy. Right. In fact, I'm certainly saying we're not going to do it in groovy we're going to say, you know, anything inside here goes on to an agent and have some way of transferring, you know, the little bit of data that people usually want between those two things. It's too far a field, but it's, I guess, you're talking about crazy groovy scripts and got me thinking about yeah, we got people off the end of that odd ramp. So I can, I can give you another example of crazy groovy libraries. So I was on reverse engineering a pipeline that one of our mobile apps uses that it wasn't working at uses a bunch of shared libraries and I started like digging into it and putting several layers in that uploaded code coverage to a confluence page for another app. So, so every time you ran any, any Android build or iOS build that that usually shares what shared libraries it would contribute code coverage to a specific app even though it was a different app. And that happened because the team that owned the app that was doing code coverage they said oh well we'll put it in the shared library even though that that's was used by everybody. And it happened because I think somebody copied their pipeline is like oh this is working I'll just copy this pipeline. And so that's kind of the sorts of things that that I mean with these like, like crazy groovy libraries is just you just, I've seen cases where you just don't know what's going on unless you dig into it which takes a lot of time and I I want to encourage people not to do that. That might be outside of the scope of this group might just be my personal. Well, maybe but I mean this, it goes to the heart of the problem, at least one of the problems that you're talking about is being hard to use and then also like how it. What can we do to make it so that people know that there's a better way. I guess the source of the problem was that people were copying this pipeline because they thought Jenkins was hard to use so so I'll just copy this working pipeline. And they didn't understand what it was doing. So, maybe that becomes one of the personas, you know, I, I do not know. I know this sounds, this just sound wrong and I don't mean it this way but for lack of better phrasing, I do not know how to use groovy and I need to build a pipeline. And I'm going to copy something or something around those lines. I do like I think it's absolute. Yeah, I like the idea that Steve. I don't think that sounds bad. Right. I think that's our engineer's work. Right. I mean, seriously, when we don't know how to do something, we find an example and we try to augment it. Well, but the problem with that is, I think one of the things that I'm going to speak for myself, I won't speak or generalized. But one of the things that I do is if I go and I copy something, I'm only using that as a vehicle of under for understanding. So I like to try to unlike you were saying Stephen, I personally like to try to understand what is happening with what I'm looking at or why it's doing this and how it's doing it because essentially, I want the knowledge to build my own thing and not just take somebody's, but I think that's been that speaks to a larger problem that you the user community does not have a granular understanding of how to do certain things with the pipeline. So they copy and they don't understand and it gets them into problems. And then I think people think, oh, it's Jenkins is the problem. They may not want to understand that. I mean, it may just be I got to use this to build my thing. And so I'm going to, I'm going to get a pipeline going. So I can go back to coding. Yeah. The part that is making that difficult is because companies are especially competitors with paid products are attacking open source as Jenkins is the problem when it truly a they shouldn't be attacking attacking open source, but that's their marketing arm. And I get it. Yeah. What they're using Jenkins as a crutch, really, when it's not, it's the lack of understanding on how to do something. I think I'm going to go a step further and say that like the vast majority of consumers of pipeline shouldn't have to understand how Jenkins works, right? So when you get, when you get to a specific scale at some point, you have a centralized team that helps manages for people and it really becomes how do I configure my pipeline instead of build it? So there's definitely a significant portion of the community that's probably represented in one of our personas that do not need to know how Jenkins works. They don't need to know how to consume the pipeline and maybe configure it with certain parameters or different libraries or whatever. But I don't think our goal of this thing is to make everyone become an expert in Jenkins, because most people don't have to be. Well, I think we also find what an expert is. Right. What do we define as an expert? And I think that that speaks to what you're describing, Stephen, is we for pipeline authoring have to make it easy enough so that the persona of expert who knows how to write groovy code can consume it. And the persona of expert who just needs to be able to tweak or configure or just consume what is already there. By the way, can we call the copy and paste off their persona, Mike? Okay. Okay, well, anyways. Copy and paste persona will be known as Mike, don't worry. Okay. I'll let him know. We have a lot that we can start building. I think one of the key things is having the personas just to get that started. I think that's where we're going to gain a lot of understanding. I think, and maybe based on the personas, but I wonder if we have like organization, organization, the life cycle of a Jenkins org, right? Of a Jenkins pipeline, right? Because you can kind of see like people start with, okay, I'm just this one person, I do this pipeline. And then like Stephen was saying, they move to having a central, you know, having a Jenkins person that does these things. And then having it gets big enough that there's an organization that now does that, right? Yeah, it's really hard to take off my plug and maintain our hat and like my life focuses around that large scale adoption side of things. So I'm trying to remember the first time I wrote a pipeline and what it was like when your scale was, you know, an individual app team. But I'm usually the devil's person supporting like 60 microservices built by different development teams across different companies like I sort of live in a different world than I'd say a lot of a lot of Jenkins users end up having to. I know it's the thing that I was where I was going with that was just that there's a this is again we're back to that on ramp where we the there's there's both a front loading of that difficulty because people like I'm a beginner. I don't know what I'm doing. Okay, I got something working copy and paste. And then we actually guide them into that scripting space that Jeff was talking about, which makes their life later on harder. Right. So sort of a there's, there's it's not just on ramp but the continued the turnpike of things like that that that path. We we seem to lead the structure of Jenkins seems to lead them in lead lead our users and pipeline authors in a direction that ends up having them fall into a pit. I have a I have a document later on. After this meeting, I'll put it in the channel. And what I think what you're describing Liam is something that we created at Yahoo. And this was called the, it's called the continuous delivery maturity model. And it talks about like what the culture and the organization is it starts it starts off like what the initial view looks like with the managed view define quantitative managed and then optimize. And then it talks about all these blocks in the lifecycle of that model. So like it stops as like teams are based on platforms and technologies, the build and release is like infrequently and unreliable manual processes and it goes through how you get to these different steps. I'll share that document because I actually have it and it's it, I think that's part of the public domain now but I think that would help because it's describing very, very much what you're talking about. And I think that the personas that we're going to generate as part of this, there's some opportunity for collaboration with big docs, right like it would be fantastic if you go to the doc site, and it's organized per by persona. So, like people of different levels are directed to different levels of in depth documentation based upon our and there are anticipation of their needs, which is never going to be perfect but might be a little bit easier than it is now. Okay, okay. Anything else that we I mean mark it seems like the personas will definitely be what we'll talk about next week. And then also that document that would be interesting for me anyways to sort of have that as a something to think about. Yeah, what I will do is I will in the notes that you have here, I will put links to them. In here, and then I'll make I'll drop a note in the channel saying I have updated the meeting minutes with the links to the, with the documents I'll have that done today. Okay, cool. So, sorry, Jeff, go ahead. Well, I wasn't saying anything. Oh, sorry. All right. Do we have anything else that we wanted to, I mean I think this is a good, a clear thing of what we're going to work on next time for next time so that's good. Yeah, I think this is really good. Is there a getter channel for for this group. Yep. Yep. Okay. I might not might or might not. We have that in here probably not. I do not see you in there Jeff. Okay, well fix that. It's pipeline authoring sake. I might be able to invite you. And I will actually I'll do that right now I'll put that at the top of the thing. Anyways, I'm going to stop sharing my screen. Okay. All right, if there but he has anything else we have action items, most of them are me. And then we'll the rest of us will pick it up and start and be ready to talk about it next time. Sounds good. We have anything else. Nope. I'm going to open a poor quest to our actual SIG site, linking the meeting notes from the website. Great. Great. That's my primary action. Cool. Yeah, thanks everybody. Awesome. Have a good week everybody. I'll see you next week and I'll see you online. Thanks.