 All righty. Welcome everybody. It is February 14th, 2020. This is the Pipeline Authoring SIG meeting. This is our regular US meeting. My name is Markey. I am one of the leads for the SIG. I welcome everybody. I usually like to just say one of the things is be nice to everybody. Don't be rude to one another. I don't want to have to rude anyone. So with that, welcome and we are going to get started. I have linked, I have linked Liam's link in the chat, the document for meetings. If you could just go on there and make sure you add your name to the attendees list. For February 14th, I am also going to put a link to one of the items we will be discussing today and that is the personas. Okay. Are you putting it in the chat or? I put it in the chat. Okay, cool. I'll also put it in the doc. There we go. So you had to drop last time too. And I'm, so, let's see here. So Stephen and I and, let's see here. Jeff, right? We were talking about, so we were looking at the personas that you had and it was a pretty comprehensive list. I was a little confused by the last item on there, the some experience, lots of experience. I wasn't sure what you had in mind. Yeah, so what I mean by some experiences, for example, when you have a developer that comes on and they may have beginning to intermediate level, let's say Java experience. Okay. Whereas opposed to there may be lots of experience where someone is like, you know, I would say someone like you, that knows it in depth, you know, can walk the code base fairly easy. Those are two personas that I feel that we have to address. And the documentation around this and that's kind of where I dropped at the, at our last meeting is when we talk about creating documentation, we have to have the personas in mind so that somebody that does not have the in depth level of code base experience can actually get in and know how to navigate in that. And one of the last things that I touched on is if we talk about those two personas, such as somebody who has a little experience to somebody that has a lot of experiences, as we create these personas, there also needs to be a bridge that we create. So somebody knows how, or at least has some guidance on what it means to go from beginner to intermediate, intermediate to advanced. And they know what that looks like. And our documentation should really be able to walk somebody through that. Okay. So we were trying to kind of suss out what you were saying. You have like 12 personas here, I think. Yeah, covered quite. Two by four, three by four. And so we started, we were like, okay, I'm not sure what we can do that. We wanted to kind of, we started going sort of a different direction with them to sort of tell more stories, tell sort of a more focused, like, who are the like sort of big bucket rather than these were smaller, more targeted buckets like, okay, let's try and what are the kind of the big buckets that we deal with? And we had gotten to basically like four so far. And the mark was here. So he and he likes alliteration. So it was really utilitarian, etc. He had a drop. So that was when we stopped using stop coming up with names. But anyways, anyone wants to apply a name to either one of these two. Thanks, please feel free. Yeah, there we go. Thank you. So the, and I think this, this is the bridge that you're talking about would come somewhere in here. I think that there was, when we were talking, I was thinking there needs to be probably one more persona to somewhere in here between either between David and Lisa and between or between Erica and David, just to kind of fill in that that gap. Because there's sort of a combination of who who someone is and what their role is and what kind of team they're on, right? Yeah, I'm reading through this. Yeah, I think, I mean, just like shooting from the hip, I think it needs to be between David and Lisa. Okay. Right, because the long term product contributors is like, okay, that's, you're already in the community, you're already yeah, involved with this or isn't enough to know where to get help and contributing back already. That's, and it's not really as interesting for this group to talk about that last one, because they're, they're already at a point where they're, they have their the connections that they need to get to get knowledge, even when it's hard to find, right? So something in here, yeah? Yeah, I think that's where kind of it needs to go. And by all means, everybody pleases a collaborative effort. If you see something that's like, you think we're way off base, or even if you don't understand it, please by all means ask questions. Okay, I have a question then on distinguishing personas here. Is there any use here on distinguishing between like a developer team member who is like, maybe more of the DevOps side where versus like an SRE, which might be more operational focused on a DevOps side of things, or maybe like, even like a release or productivity type team, as maybe an in between, or with that spectrum cover, like, like, essentially, these types of personas, that sounds like that almost sounds like that's the persona we're looking for. Yeah, where it goes from maybe DevOps to, you know, an SRE sort of operations, keep the lights on. So the the operations side, though, is is more like the utilitarians and or, or either one of the utilitarians, these are the people that that are that either that are just trying to get the thing done, right? I'm just going to do the thing, right? At least that's the way I was thinking of it. Maybe I'm not as clear on I think they're I think what you're talking about somewhere in there is definitely that that's where that the persona is. But I want to make sure that we're separating them clearly, or at least having a clear picture of what the what the difference is. Can you talk a bit more about that? Like, what are you thinking of? Well, I'm kind of thinking of some some general generalized typical personas of Jenkins, like in my own experience and around, like, I can think of like three broad categories, essentially one being developers setting up CI essentially to try to follow continuous integration and maybe, you know, and maybe CI CD to and continuous delivery potentially. There is the maybe like a QA side of things where you're generally like, automating tasks that you need that you're trying to run for continuous integration types of things or continuous testing or things like that. And then a more Opsie SRE side of things where you maybe you're automating various infrastructural tasks or deployment things or what not. So it's kind of like the spectrum of dev ops, dev to ops. Does that make sense? Yeah, that's to me, it sounds like dev ops, dev to ops, dev tools, dev productivity, something along those lines. Yeah, and I guess to add to that a little bit, I've noticed, like, especially with larger companies that would get more like, involved in dev ops and things would tend to make a distinction between like the automation team versus the developer tools type of team, even though or like the deployments versus the like the automate basically various automation things would be kind of they'd get a little more specialized than just a generic dev ops team. Okay, so I'll cover where we got to in this. Mark brought up utilitarian. And this is generally the silent majority. I think of those as generally, those are the ops people, those are the one that like, I'm just getting stuff done. I'm not as sure and getting involved in the community. I'm just so I want to let's let I would say this is the the generally the ops person, right? Yeah, that makes ops end of the spectrum. So what are you talking about? What are you looking at that is not being covered in either this or this other case where sort of this is sort of the not ops person. When some there's the when there was someone on the team who got Jenkins going for for the team, and started using it and sure and the team has value. And this is like a sort of a weird like space to be in, right? Where it's like, okay, that person left and now we've handed this to somebody else. And they're trying to, you know, wrap their head around it. Right. So this is the I see what you're saying. I can kind of see how this actually maps out. Because I see the DevOps team member is somewhat what I was thinking of to a more like SRE extent. Yeah, now it's no longer just plain ops. Right. It's I want I want to I want to automate my ops in a more like thorough fashion. So in the beginning, utilitarian could be even for just continuous integration purposes, like for or just general like, you know, your general automation tasks, any anything that you you would you could potentially do in cron, you know, Jenkins is great for that type of thing. And that's right, probably, you know, that's your typical seems to be a utilitarian view of Jenkins typically, like I need a thing that runs stuff. Right. Yeah, now that I see this more and understand this a little bit more, Liam, I don't think we actually need another. I don't think we need a I don't think we need something between David and Lisa. So here's and let me just I'll finish the story and then you can tell me whether or not this is whether or not you're still on the same page. This was Steven last time was like wanting a persona for him. Right. And so because he is one of the he would definitely be one of the personas that we want to reach. And I sort of like was pushing down on it a little bit. Because he's Steven is basically ends up in the long term project contributors bucket. But that's partly because but before he became like an actual contributor, he was doing things like, you know, looking at writing a templating engine for for for his Jenkins team that manages, you know, the large number of Jenkins for a large number of teams and has to manage their their where they focus the energy and stuff. So it's it's not even like a so this is like, that's that's where that I sort of pushed down underneath where Steven is to get this persona. And I wasn't sure if there should be another persona where it's you're not a member of a DevOps team, but you're like the member of the team that's doing the our enterprise Jenkins stuff, right? I essentially the next level of Jenkins administration and automation. Yeah, something like that where you're you're building on you're building you're building almost like an internal application on top of Jenkins to of Jenkins, right? It's basically like, okay, I want to specialize Jenkins for our large team, large group, right? Multiple teams. So I think that could really be David. I don't think David has to be a DevOps team member. I think he can be a portion of it. But I think David, it could be David could also be a developer that says, Okay, we have Jenkins, I'm going to now, you know, build something on top of it or some automation to interface with it. But it could just be an individual contributor developer that's been tasked with doing that. It makes a lot of sense. One of the things I also like is from David to Lisa. Yeah, that feels like a bridge to me. Okay, because David understands as he and I when I say David, I'm thinking Stephen in my head. So David has he's he's he's felt the pain. He's gone to the community to ask questions. He's seen a deficiency. And he figured that there's a way I can make I can plug that hole. And by plugging that hole, I built this and David being Stephen built the templating engine, right? And there was the bridge for him to become a long term contributor. He saw the he saw the gap. He instead of expecting someone else to do the gap, he filled the gap, and then gave it to other people. And that seems like a bridge to me. Okay, so then for me, there should be a then there should be one person underneath between these two, which is I'm a developer on a team that David supports. Right? Like that, because what you're looking for there is someone who is not a Jenkins expert, but want but is like, Hey, my, my, our group, we have a group that does Jenkins, and they've given me these tools. But there's this like, how do I write the pipeline? Or how do I do that? Do I have to go and ask them all the time? Or is there a community or and, you know, dev tools, like an IDE, like I expect that there's a there's a persona right here, I don't know what it is, that expects there to be dev tools, like, Hey, where's my, you know, IDE support? Where's the where's the online document, the documentation that just comes up everywhere. And like, they expected to behave like Java, right? Like, where's, where's where's the where's the the the IntelliJ plugin for this, right? Or where's the library for this? Right? Is that kind of where you're going? Kind of. It's, yeah, I don't know. I don't know. This is, does anyone else have any thoughts on this? If anyone else is talking, you're muted. So you're, it sounds like this is Carl, you're sound, it sounds like you're describing someone who's expecting a mature ecosystem, who's come from other, you know, from other technology, ecosystems, and is looking for work alike tooling. Dev, like something like dev productivity or dev tooling maturity, outside individual contributor, something like that. Yeah, I mean, and then I would say, yeah, right where you're at, I'd say Olivia is looking for maturity. And now if I start to think into the future, we have the other document, which is in the notes for everybody in in the maturity model that I put that I built out. And that's where we start to say, where do these personas fall in the maturity model? Okay. I just wanted to throw a time marker out there. I have a hard stop in two minutes. Okay, we may or may not continue depending on people's interest. So one of the things I will say is what we have here is very, very, very good, very detailed. I think if we and I'm going to throw this out as an idea to the team. I think if we took these personas match them to the maturity model. And if we were to take the maturity model and start linking the maturity model to current documentation. And that's not something we're obviously going to do in one meeting cycle or even five meeting cycles. But I think it would be good to start helping us to decide, as we have the personas, we have the maturity model, where does it fit there? And where is the documentation currently that shows how that matches? And I think we could that's where we start to really define the pipeline SIG, because we see where the deficiencies are in current documentation. And then we start going through the documentation to say, oh, man, we really need this or we really need that. And then we could interface with the doc SIG to say what we need. And we start this sort of cross SIG collaboration. And that will help out future wise in the future. That would really help us to start to then find out what we're lacking from pipeline authoring standpoint. And that's sort of what Mark was asking about was how best to document pipeline so we can sort of loop back in with them. Yeah, yeah, I think if we had maybe a task and I'm willing to with the one minute I have left, take that task from now to the next meeting to start to go through to make this mapping so I can create a new document that refers to maybe some anchor in the previous document and we can start to see the sort of lineage between all of these things. Okay. Well, I mean, I think we'll consider we'll start talking about the we'll continue talking about the personas that people are interested. And if you have time to come back, that'd be great. And then we can see about, yeah, some like that. Yep, I will be back. I will be back in hopefully 15 minutes. Okay. So remaining Matt, Carl and Devin. Do you have anything you want to add? I mean, this person is very minimal. I'd like there to be a little bit more there. But if anyone has anything they want to add you're all muted, though. I don't I don't have anything to add yet, mostly because this is my first one of these meetings that I've been Okay. So yeah, okay, cool. Seems like you covered a lot of lot of the ones I think of. Yeah. Yeah, this seems to cover the spectrum in a different way than I was thinking. But it because of that, I think it makes it it covers it more broadly, which is, which is good, because otherwise, you probably could end up with like 20 different personas. Right, exactly. Or more. I mean, people use Jenkins in space, supposedly. Indeed. Sorry, I just gotten to I wasn't ops. I'm not ops. I'm DevOps. There we go. Yeah, okay, there's more. There's more to that person. I just not sure what the main thing that I'm thinking of is someone that definitely is not thinking of Jenkins from where it's sort of like the utilitarian but but like, because they're not there, they would definitely prefer not to think about Jenkins. They're trying to get something done. And they're trying to use it as a tool. So I think more of a power user type of thing. Yeah, maybe. Like trying to use it better. Oh, yeah, that's the on DevOps thing. To So the thing about the I'm DevOps thing is that it that it's like, these are the people that's actually this maybe this is like, when they're thinking about the design patterns and usability, they might be thinking of like higher architectural concerns. Those do seem related, though. Yeah, they're not the title isn't quite right. Because this is this is the developer on a team that manages like multiple Jenkins and does all the tooling and stuff for people. And this is the consumer of that, that person's work or someone that is wanting to treat Jenkins. I want to use Jenkins like I use any other, you know, development tool, right? Oh, well, I guess from a pop from from a sort of power user perspective, you could have like both the the power user who is it is essentially administering Jenkins and and trying to get people to use it appropriately versus the power users who are trying to use Jenkins for very advanced scenarios, you know, like maybe, you know, the people who are who are using it for full on CI CD type things like where you would use Jenkins with GitOps or things like that, you know, that would be like super power user trying to find best practices for how should I use Jenkins in, you know, advanced scenarios or like modern scenarios or best practices type of thing without necessarily being like I want to be the person in charge of running Jenkins and and actually the whole and maintaining the system type of thing. Whereas maybe the DevOps team member cares more about the actual build system itself too, essentially. Sorry. So which goes which side here? You were so that the longer thing I was saying would be the Olivia part the outside whereas the whereas the person that being the person more interested perhaps like in the continuous delivery or deployment type of things using GitOps, you know, or basically trying to know the best practices of using of using Jenkins and pipelines to automate the various things they're trying to do. Okay. Whereas the DevOps team member might care more about the actual market like care more about how Jenkins is used. Right. Yeah. Okay. You know, they might care more about the Jenkins specific stuff. Like mentioned there with like shared libraries or trying to you figure out the proper architecture of setting up their agents, you know, and all that sort of thing. Whereas the outside developer might care more about like the, you know, the big picture type of thing in a CICD type context maybe or that yeah. So to them Jenkins is more of a tool than than whereas I think the DevOps team member type of thing might be using Jenkins more is like a framework almost might be the difference there. Yeah. Okay. And I think that the the the thing is like for the for David, at that point, you're, you're getting into a lot more hairy situations. But by the time they get to users get to this point, they're pretty aware of what Jenkins can and can't do. And they're, they're they're already sort of aware of the pain points. Olivia, particularly Olivia and Erica are the ones that I think run into the walls or run into like the the gotchas that that the most, right? Because yeah, I could see that is because Jenkins is not meeting doesn't meet their expectations, especially for I think, Olivia. That's the the people that I talked to them. This is what this is the kind of questions that I get the most from people to look whether like, look, I'm a dev. Where's my where's my where's my debugger? Where's my testing testing frameworks? Where's my, you know, whatever these all these things they sort of expect to be there for what we'd call a mature product, right? Well, and Liam, like right now with the thing that I'm working on. Yeah, I am Olivia. Yeah. Yeah. Here's, you know, here's this this mountain of shared libraries that you were trying to glue together from pieces provided by other teams. Go figure out how to make this work. Right. So I'm going to worry about the expect. I need to do one more thing. IDE integration. Demi, do you have anything to add to any of this? Just check it in. No, not in particular. I mean, okay, I think I already agree that I see like this Olivia persona as having a lot of the one running into a lot of issues and being the most frustrated with Jenkins. The because the utilitarian basically is like, I just they sort of these are the people that go to go to sack overflow and copy and paste something in it works. Cool. I'm out of here. They don't it's horrible and doesn't make sense. If it works, it works. Exactly. And Erica doesn't expect there to be anything. So they're they're not disappointed. They're like, Oh, whatever it is, it is I'll accept what you give me and work with it. Right. And it's really this person that's coming in where they're like, Okay, I'm ready to do this. Wait, what? So talking about how this maps to the maturity model that of that Mark, he was talking about. I'm not sure. Did you guys just have a link to this? Or do I need to post it? Or can you just read it from here? I had not seen it. Okay. Let me copy that and it might be at the last meeting notes right there. Yeah, but it's a longer link. So I'm gonna paste it into the chat if I can find the chat. Of course, now my there it is. Computers are awesome. Okay. Is that the right one? No, that's not the right one. The link is this garbage. So that's not gonna help. That's the sharing. That's not what I needed. Come here. Wait, okay, I can do it this way. Maybe that is the right one. Yeah, looks like it is. Okay. Alright, that was in the chat. You guys won't step over there. That's great. I'll give people a second to look this over. I'm not sure. I'm not sure I actually understand how this maps. I fully understand these yet either. So this is where people are on the CICD maturity. That sound right? capability maturity. Okay, I'm not sure how these map onto the onto this because the it's not sort of a one directional thing. They're for the personas, they sort of go in. It's not really a spectrum as much as it is a matrix. They have different dimensions. So I mean, certainly, David persona would be somewhere in the defined to quantum kind of manage kind of end of things, maybe into optimized depending on but this is talking about the teams that they're on and I don't know. I mean, you guys have some experience with you. I don't know that the except for maybe David that there's a one area right for the for each of these personas one kind of team or one environment they exist in. Although I mean, I guess it's roughly maps. David is somewhere up in here. The Olivia is somewhere in kind of this this range in the middle. And utilitarian can actually sort of exist anywhere along in here because they're there. Although I guess they're more sort of in the mid to low end because again, if you're once you get up to the other end, you other end of the spectrum, people stop being just throw it together slapdash and being more, you know, engineering excellence kind of minded. So yeah, I mean, it probably actually lines up lines up somewhere in the overlapping thing directly. Thoughts? Yeah, I think there's there's probably a little bit of I'm struggling to find the word. It's not a it's not a perfect you know, rows and columns thing, but exactly reasonably close. Yeah. Close enough for making generalizations like like personas anyway. Right, exactly. So as a as a latecomer to this to this work that we're looking at. And by latecomer, I mean, this meeting is the first time I've ever seen any of this stuff. Right. What are we what to what end are we defining these personas is this for is this for organizing our documentation in a better way? Is this just for sort of getting our head around where we take pipeline in the next year? Like what's um, and if you don't want to do that here, if you want to do that offline, Liam, that's cool too. But just to sort of no, actually, that's context, I guess. So we were only three meetings and yeah, three meetings into this sort of reboot of this. And we started off going because what asking the same question you just took is like, what do we want to achieve? And Markey suggested that we have some personas that of people that use pipelines and are working on pipelines, or either working on pipeline or working with pipelines that so that we can kind of talk about. Then we could that would we thought that would help us focus on what what it is that we actually want to do because we we started off talking quite a bit about a bunch of different pain points and what works and what doesn't and things that we could try and it's like, okay, we get there's lots and lots of things, but we don't know yet. So what we're trying to do is sort of figure out how we can serve each of these personas better with Jenkins pipelines. And so like the, for example, Steven was talking about teaching, you know, being able to show people how to use pipeline better things like Codacoda or better documentation, or do we need better ID tools? Or I mean, it's really just a question of where do we focus our energy next? Or is the the best in making the syntax better? Or is it, hey, let's let's have an option to use YAML instead, if that's what people want to use and what does that look like? So this is what this is we sort of started our first meeting going, Oh, my God, there's so much with so many different ways we can go and tried. And so the personas that we're talking about here are trying to bring that bring some focus to that and looking at what we can do. You know, how can we serve each of these best with next steps? Okay, that was really helpful. Thanks. Yeah. Um, so let's I again feel badly for asking questions about no, no, but Marky's background is was that where is he from? Is he just I don't recognize the name? He's he's in the US. He's been to a couple of Jake's. I think he's in the US, pretty sure. And he's been to a couple of Jenkins worlds and serious pipeline user. He's been on a bunch of the the the SIGs and doing work around Jenkins as far as I know. So I think he's also done some work on some of the plugins. So yeah. So is he for I get I didn't ask it specific more specifically enough as he's like probably in the Lisa or the David for example, like, you know, the guy who is he one of the people behind that? Um, that I think booze booze Allen visit. Ah, that'd be Steven. Okay, okay. Got it. I'd I'd all right. So I was on the right track. Yes. Yes, you're talking. These are the right set of people that you're that you're referring to. So Steven is not here today. Good. That's good. That's good to hear that I didn't imagine that. So yeah, what you're talking about is so far most of the people in the group are either David or Lisa that that were, you know, long term contributors or otherwise doing things that are building on top of Jenkins. And that would still include also Matt and Devin and you Carl. So there's some need here to get a wider set of perspectives. And we were also talking about, can we do a thinking about doing some sort of survey, getting getting people to sort of give some feedback? The yeah, so there's a bunch of options there. I definitely I mean, personally, I definitely I think this is, I think the Olivia for me anyways, that now that we're not actually created this and that that's where I want that's where I would want to focus, right? The people that because for me anyways, these are the people that are either either one of these two are the people that are most likely to become long term contributors and power users that are going to going to ask us to, you know, be interested in doing the improving pipeline, right? Sure. And they're also the most likely to get frustrated and fed up and go use something different. Right. So I'm not sure what so if we map that to the maturity model, I don't know. I mean, I think that there's for me anyways, I find it easier to tell stories about people than about organizations. So and this is definitely where I've gotten the most pointed questions from people at DevOps world and stuff like that where people like, okay, I've been using this for a little while and I'm looking for how do I test my pipeline? How do I do these other things? Yeah, but something that's been talked about by a lot of people for a long time. The difficulty is that this is also some of the hardest stuff to given the framework that we have, right? I don't have a year, you have, I would say the most technical experience in this in this realm. All I can go is sort of hand wavy like, that's a lot of work in there. You mean like debugger wise or any of these things? Like, what in understanding what the level of effort would be to do something like this, right? I mean, I think some of these things, like, I guess is like reusing external libraries is like pulling a separate groovy library and use that. Yeah, like, there I would say like, we don't want you to do that, we should discourage that. Like some level of IDE integration, I think is certainly possible, especially since text wise, not necessarily like super problematic, it's more like, you know, can we actually successfully maintain like a VS code plugin and keep it up to date and useful? It's kind of I feel like the bigger question there. Debugging testing, I think are like the real more complicated bits. I know there's a lot of approaches to like do static testing of pipelines and shared libraries, different approaches and people like some of them some people don't like them. debugging would be nice to have but I think it's like, technically a huge hurdle, probably unrealistic to ever happen. Or at least like, maybe you we could give you a debugger, but I don't think we could give you a debugger that's stepped through your pipeline in a way that was useful. We could maybe give you a debugger that's stepped through this synthetic generated groovy code, which would be completely useless. Right. Maybe we could give you one that went through steps or something, but I don't doesn't seem like that would be super useful. Like, basically, I skipped overall groovy code, but I don't know. It kind of depends on what you would want to do with the debugger on whether we could give you something that would be meaningful or not. Yeah, I'm wondering like how it would be completely unrealistic to have something that actually do stepping through the declarative pipeline. Or is that like, you could have something that steps through and like before a step executes like wait since it says like, Oh, the steps about to execute. But I mean, like, what information would you want to see when that happens? Right. Would that be useful? We could do it. I mean, you would have to run like inside of Jenkins. It could be done. There's also works for it to work like any other debugger. I imagine it's like, you know, examining the state that it's running and maybe being able to inject some code to run, you know, in that context and that sort of thing. Yeah, and that I think is where it becomes quickly unfeasible. Like, I think if you want to do only things that look at the the pipeline in terms of like steps and flow nodes, straightforward and as possible, if you also want to interact with the groovy code, I think it becomes significantly more complex. And that's where it's good to find a good design delineation here of what of how much debugging how much debuggability you want to expose based on that feasibility. Right. I mean, really, I would say for all of these, like when you start asking these questions, I would say you probably want to look at creating an external like command line tool that your pipelines use written in whatever language you want that can be debugged totally independently from Jenkins and use any kind of libraries, whatever, you know, you package that together. And then Jenkins just calls your command line tool from Michelle step. And so you keep your Jenkins file as simple as possible. Anything that's interesting logic is in that command line tool, you can debug that however you want without Jenkins. Like, I mean, obviously it's a fine line, right, because you want people to be able to understand what their pipeline is going to do and stuff, but pipelines not really intended to be like an application platform that you're writing sophisticated like programs against that to where you would want to debugger. Right. Hmm. So what I'm thinking about here is just the what you're talking about is so the reason so the question is why do people so why are people doing shared libraries and external libraries or complex? Why are people in this this spot right here, right, where they're like, I have to do this really complex thing. We could we could like ID integration for while you're like writing declarative or hey, what steps can I use? That would be really helpful for these people. But then when we get into let's let me just reorder these for a second. So they're gonna like ID integration is, you know, it's a little bit it's work, but it could be done, right? Because you're basically you do something where you get the data that can then be consumed by the IDE, right? Testing the pipelines, testing the pipeline itself. Probably, you know, there's already some unit test frameworks that that people have people are working with to do the stuff. The question is when people start doing shared libraries and external libraries, what are they trying to achieve? And like, can we can we create something that would make it make them more likely to use external tools than shared libraries? Yeah, I mean, I think some of it is like, they be mixed messaging and grand hopes in the past of what these things could become and how robust they would be eventually, that kind of never materialized, right? So like, this user, we have documentation on shared libraries, but I don't think we really explicitly say, like, Hey, this should be for pretty simple stuff. If you're, you know, writing, like, if you're trying to create like a arbitrary class or doing any kind of subclassing or extensive object models, you're probably doing too much, you should do something else, but it's possible. So people do it, right? Like, yeah. Like I would imagine like probably the intention was more that your shared libraries would be like, Oh, here's a chunk of like what would amount to a declarative pipeline stage or something. Right. You can go ahead and call that if you want. That was probably more of like the idea of what people would do. But that's not what people did do. Yeah, I think that's probably the the core of the issue. And I mean, I think really what we would like to do is give people some feature that makes it very clear that it is not just group your Java code and you shouldn't use it that way. And you shouldn't want to debug group because I shouldn't even, it shouldn't even be something that should be useful with the feature we give you. I mean, I guess there's some, in some sense, it would be nice if we could improve shared libraries to be more like real groovy. But I just think that ultimately that's never going to Well, it's also the new right. And we end up with the problem of that code runs on master, which means, yeah. Yeah, and like maybe we could change architecture of it. So it doesn't. But then it's like, then you delete a lot of the capabilities that people wanted shared libraries for if you can't interact with Jenkins directly because it's not on the master anymore. Well, and the question the question I have actually for that is how much do people actually interact with Jenkins itself on that? Or do they, is there a way to Yeah. I mean, from what I see, like a lot of times shared libraries are used specifically because they can be run outside of the sandbox and access like Jenkins internals for like some random thing this company wants to do with like agents or something like that. All right. So it's like, I wanted to say that everybody does use it like really extensively for that. But I would say a lot of people use it have at least like one or two things in the shared library that would not work in a model where shared libraries ran on an agent. Right. Anyway, sorry, that was a bit of a range into this, but it's worth talking about. So we're actually almost a time and Marky hasn't made it back. So I think we'll probably go ahead and call this for now. So the for next time. Marky is talking about mapping these together a bit more and making that choice. Hopefully I'll take a look at what we've we discussed there on the video. And then. I think we'll continue what like how what the this question of like how how can we serve each of these personas best and. And and I'll note actually I'll put in the notes that what we talked about for for this one. Actually, this is kind of I've been noting as we go. So that's good enough, I guess. Or maybe I'll just pull that over to the. The the notes. All right. Well, thank you all for coming and the the will be starting up a so we do this every week on Friday mornings for morning for specific time Friday at this time. And in a couple of weeks, we'll start up a meeting on Thursdays for the European time zone. Which will be later in the day on Thursday. So check out the Jenkins calendar page and for more details on that. All right. OK, cool. Thanks, everyone. Everyone.