 Record to the cloud. Okay, cool. We are recording. I know a reason I wanted to do the recording is is that for anybody else that may want to view it later We are ready So a lot of Jenkins world I spoke to Koske about trying to revitalize The special interest group which is near and dear to my heart And he recommended I reach out to the two of you. So we did that on getter and and here we are So I thought that we should at least like revisit focus areas Try to identify like why did this is a lot in the first place is the scope of this thing too narrow or too poorly defined and try to figure out ways to Revitalize it and get engagement going try to figure out strategies for like maintaining an agenda into the future so that we You know aren't scrambling on a month-by-month basis to try to figure out What we're going to talk about so I feel like I have the least amount of open-source experience managing communities, so I I'm excited to have your guys expertise here to help with that So I can start I can sort of just rattle off the existing focus areas as a launching point or do you guys have any ideas for Do we want to start from scratch and try to re-imagine what we think they should be or do we want to start with what's there and and try to iterate on that I Think the I Wanted I want to say start from scratch and just make it something new and fresh But then again, I don't know if that's the right way to do it because I think we have to identify What was previously done and why it fizzled out so it doesn't happen again, but that's just my take Hot so I Can speak to like the origin of the SIG at least so to Jenkins world to go so that'd be 2018 I guess Koske Sort of saw a talk that I gave a Jenkins world He saw some work that Austin what was doing with Jenkins Spock and there's sort of a bubbling I guess of Cool interesting projects in the community that are focused on how do people Author their their Jenkins files and how can we make that experience of doing pipeline development easier for folks? So the Jenkins template engine was one example Austin wit from from home away had developed a unit testing framework for pipelines called Jenkins Spock And then obviously Andrew Bayer was involved obviously declarative is Probably the primary and most commonly used framework for developing pipelines at this point as a Simple easy User interface for developing pipelines. So I think the general theme of this was really around developer experience For Jenkins pipeline is code in all the forms that that might involve so including things like How can we make static code analysis easier? And how can we make it easier for people to identify? Issues in their pipelines before they blow up in production Different tools that might make it easy it like basically how do we apply the same? Best practices from software development when we're building applications How do we take those principles and apply them to developing pipelines as code is sort of how I think about it I think that's a good place to start right there. So Hmm so talking about the engineering practices Coding tools stuff like that So here's the here's the thing I actually it was interesting I don't know if you guys you guys weren't in Lisbon and I gave a talk on pipeline What's going on with declarative and it was interesting for me because it was one of the more pointed Q&A sessions afterwards of people asking like when is this feature going to happen when is that happen and and also One several in particular like okay, what about developer tools what about testing a little bit debugging and that kind of thing and While I Mean I think there's a sort of a trade-off here on one side We want this to be a vibrant community want it to be people, you know making New things and means it's forward, but at the same point the more there's there's a there's also a counterbalance that of Do less in pipeline, right? Of like pipelines should be the glue not the not the workhorse right and I guess so the question that had is is Sort of like is more developer tooling really I mean it's what people are saying they want is that what they Really need and is that really where we want to go and they're not saying that let's not do it I'm more just like I want to kind of maybe Make sure that we're Working on the same assumptions, right Um what it would it make sense to say we need to define a charter Also am I coming in okay on my mic or is it sound like a robot you're fine. Okay to me. Okay. Okay, cool Yeah, I'm wondering maybe if a charter needs to be defined, but I think that should be more What you guys think Steven I saw you talking, but I didn't actually like hear you. I don't know if that was me or in general switching, okay Can you hear me now? Yes. Yeah Excellent. All right. Um, so yeah, I I think a charter might be I think seems maybe like a charter might be a little Overkill until we really know the the vision that we have like I I think that You're you're right on the right track Liam. We're like we want to make pipeline development Simple right your pipeline shouldn't if you can't build your application without your pipeline Your pipeline is probably doing too much right from a from a I don't know best practices perspective if a Purist about it. So it's really in my opinion about how do we make the abstractions? You know the right way so the pipeline development is simple So developer experience doesn't mean that we make it more complicated and we add a bunch of tools in there So that people can do more advanced things. It's more about How do we make it easier to do powerful things simply? like I Don't know. I'm trying to break out of my like JTE hat that I always have on my head But thinking of the Jenkins sampling engine is like it's an abstraction for making pipeline simple And how can we apply that with or without JTE like it's declarative right declarative took over So well because it it was a simple facade on top of a complex pipeline DSL So when I'm thinking developer experience, I'm thinking like how how can we make pipelines that scale easily? Don't require a a large technical barrier to entry to develop And how can we validate those simply defined pipelines in a way that you know if they're going to work before you actually run them? Right so that that gets a little bit into linting a little bit into unit testing um But I agree with you that that we don't want to like Add tooling in there for advanced parallelization when like that's really not Something that your pipeline should probably be responsible for and I mean like I kind of feel the same way about debugging I mean, I like if Like they're to me anyways philosophically I I'm I'm kind of I've pushed back against debugging because like well if you're doing declarative you really don't want to debug that and I mean, I don't know it's it's um It's also just it's the kind of problem that we could spend a lot of time On and I'm not sure that it's where the biggest Like as an example debugging is I'm sure that's where that's the biggest gain in experience like in positive experience, right? One of the things that I think is is critical is identifying When we think of a charter, right? I think we have to have a charter But the charter has to be defined that we know what the charter Problem is trying to solve but in order to know what problem we're trying to solve We also we need to know the person we're trying to solve the problem for so I'm wondering If it makes sense to before we do that start to create personas So we kind of know who our users are because if we have a new user That's never really used Jenkins They don't know what you know what they don't know like we have somebody that's sort of intermediate They may have used somebody else's they don't know what they don't know and if there's somebody advanced You know they may have an opinion But they're not looking at it from the new user or intermediate intermediate user I think that makes sense. I think along along those veins. There's also like scale personas Which is sort of how I think about it, you know the the needs of a person running a pipeline for an individual application Are different from like a central dev ops team that helps support CICD for multiple teams simultaneously right so From a debugging that's like your use case. So we have personas and we have use cases Okay That makes sense When I'm thinking about making pipelines easier. I You know, I love the pipeline syntax tool. I would love it more if it was in my IDE um right so little things like that like how do we How do we make it easier for people to figure out the right syntax without having to go to the pipeline? syntax tool and if the only or um, I know these are grandiose visions that are not easy to solve um, but I I've got to think that the same Implementation or design that led to jank and spock by inspecting the class files and pulling out the Being able to mock those things you should be able to use a similar style api to bubble up the the syntax of expected pipeline stuff um So I I don't want to get into solutioning in this meeting, but just thinking about when I'm sitting down to write a pipeline I don't want to have to have jankins open to figure out what the syntax is to do that necessarily Um, I know that I know we're not going to get into tooling. I know vs code has done some stuff around this May have some Nice little linting tools, but I don't think I think it's very rudimentary. It could be a lot better Yeah, I mean I so I I'm on a dev ops team as part of a huge company and I see all the common problems that people knew to jankins hit and it's things like That static code analysis could help with like you have a distributed build architecture And you you did a file exist, but you never unstashed or checked out any files Right, so sometimes that code's gonna work if you got lucky and it ran on the same node twice Other times it's not going to but like there's some common patterns that are detectable from a code standpoint That could lead to unreliable pipelines But the number of those those cases are probably not large enough to justify an entire Like static code analysis endeavor um There's some interesting stuff too with like jankins file runner like I know that project started up I don't know if it's still in development, but how can we How can we run mock pipelines locally without necessarily needing a real application to be testing against just to make sure that everything It's going to work as expected Like jankins spock got us to mock like mock unit testing Is there anything that can get us to integration testing without a full-fledged jankins instance um, well essentially jankins file runner jankins file runner is effectively a full-fledged instance right it is it's a jankins right so yeah But I but what you mean by that is by not speeding up a whole new server or whole new I don't know. I don't know where how you want to distinguish that but uh A long running jankins as opposed to a ephemeral one Yeah, that that's probably as close as as you can get right now given jankins current architecture um So maybe we just start with like our first couple meetings are Interviews with the community like Instead of the three of us trying to figure out who are all probably jankins experts sitting down and trying to figure out what the problems are It would be interesting to get people together and talk about like what are your challenges? That you're having and that the people you're working with are having It's sort of a hard problem because the people that are involved in the community are Probably not the people that are the newest at it right If you look at the total population of people using jankins and then the percentage of those involved in A special interest group. You probably have a not very representative sample of the actual user base um But yeah, I think we got a survey together That'd be interesting. I wonder how quickly turning the support For um right like hey fill out this survey and we're we get questions that are like I have this specific use case and this specific problem How can jankins make my use case easier? Yeah, we would probably need to tailor. I know in another community that I work on uh in We're when we do surveys for our sigs. We're extremely like we pour over The questions we're going to ask and think about it thoroughly To not turn it into a help desk thing or or a gripe fest But more to try to get meaningful data out of it and then you know use some analytics to cross-reference that data against other things So maybe that's something, you know, that's just a suggestion something we might be able to do Like if we got a survey together, we got together with maybe You know the the advocacy group and alissa and then had that survey go out and then Sort of see what we get back But we would need to as a team really decide what the questions are going to be If we went that route, I think it would be a good thing to do because it gets a pulse of the community But I totally see the other side of that Yeah Go ahead So maybe we're also scoping this too small like we're talking a lot about the pipeline authors experience Maybe we can also expand this to be the pipeline consumers experience Right. My role is frequently I build a pipeline that app teams use and I field a lot of questions from developers about their pipeline and it's always things like the pipeline's broken I'm like, well your unit test failed Like how can we make it easier as a consumer of the pipeline to understand exactly what went wrong and why? Um So if it becomes more a pipeline experience sig instead of just an authoring sig It gives us a couple more avenues of conversation and Features, that's why I think personas are going to be critical. I think they're going to help us drill down to What we're looking to solve based off of the persona. Yeah, I think I think definitely at least At least looking at what are Yeah, I think that the personas at least are are useful for for focusing our discussion Like who are what what what sort of thing are we? And sort of grouping the the kind of thing that we're going to work on Well, uh, if you got if you guys are okay with it one of the I'm going to take an action item Like I start drafting up between now, uh, I have another question But I'll say between now and our next meeting I'm going to create a new doc that I will link into the notes here at some point this weekend Where I'll start creating the personas Okay. Yeah, we can have a lot of stuff from other communities that I can use At least to get sort of the framework and it makes it a little easier to do Sure Stand on the shoulders of giant. Yeah. Yeah, right so Um speaking of of feedback from the community We have at least at least one and I'm pretty sure I've got a link to another one from a year ago Or from yeah from various ones of these uh, the Sort of pipeline discussions that happen at Jenkins world and we can talk about those some too those I will say did also turn into hey, I want this feature or hey, there's this bug a lot more than But um, at least in Um In lisbon the interesting thing that came out of that was the the same problem was actually we had like it was a bird of birds of feather Can move around thing and the same thing was brought up Two or three times it was like the same like one Issue and it's a long-standing issue with the the way that we do parameters, right? um Anyways point that was the thing that was funny about it was just that it that that each new group had basically started with that same thing so you get I think we have some things that we can address that are like, oh, hey, we want this one behavior to be different um But usually the what happens with those like for in this case with parameters that behaviors is the reason why it is the way this is so sent is buried under layers that we that in order to move it like It involves some really hard thinking about okay, what exactly can we do, right? um The same thing happened like people are people have asked for hey, I Like not the second most common, but the but certainly one of the top Top 10 is is hey, can we can we why don't we do a yaml pipeline? Why don't we do pipeline and yaml and I'm like that's great except for like Once you if you extend that like it sounds great on the on the surface, but then when you get into Actually dealing with what does that mean and where does that end up? the It goes to declare a little generator like a yaml parser, right? I don't think it'd be a big lift to take a yaml intake and Send it through the same abstract syntax tree I'm pretty sure I like dove through the declarative code and there's like It takes your groovy and there's a json output and a yaml output Uh json output. There's no yaml output right now um But it doesn't mean there couldn't be Yeah, that seems like a Forgive me for saying not complicated But like if we have a json output typing that to yaml shouldn't be right except for When you you go down a certain distance Uh, for instance when you get to steps are the steps in yaml are are they groovy? Like what is and and for those like Even discounting the script block like when you when you start working with them the the The step itself needs to be written Sort of groovy ish like we could kind of convert them to a certain point and maybe make the parameters But then once you get down to the parameters themselves, they're gonna have to be Groovy some degree of groovy at some point Yeah, you'll end up with some nasty thing where like the values of string that you parse through a groovy engine sharing the invocation of that thing uh Well, that's that's the kind of that that's that that's sort of like when it's like oh, this is great. This is great. Oh, oh, this is not great Oh, this got bad. This good. Yeah, and I love you talking about like how do we drastically reduce the scope like you want to yaml syntax Okay, but here's the subset of features that we can support to do that Right, if you want to have an array of steps that run inside a container image and execute some sort of script You could write that parser and like a day, right? It's just iterate over the yaml run docker.image.inside and then run a shell script um So the value of it is smaller, but for those that don't have complex pipelines it provides some value But um, okay, and I'm not saying we shouldn't do this, but like as an example, um Maven has supported attributes For year for a decade now, right? Nobody nobody uses it like everybody wanted it and nobody uses it It would make it would make all your maven files like Way more understandable way more easy to read nobody like it isn't it has never been never gained traction So are we going to document both? Like are we going to show are we are now going to start showing yaml for our pipeline too? And I'm not arguing against this. I'm like this is this is when you actually take this to Like, okay. Yes, I can write it in a day. Boom. There it is Like when you actually like take this to its logical conclusion, it gets a lot harder um and a lot more Like what is this supposed to look like? I agree. I think I have a pretty hard line depending on most things and my my take on this in general is like listen if you Just learn declarative like what what does yaml give you that you can't do it declarative? Right, like I don't know that I understand the actual value proposition Of yaml, especially when you start to look at like how easy it is to mess up indentation in yaml and Like then we have a whole other this is a such a loaded topic Right, but and I think we have that now as long as you're Go ahead go ahead as long as you're arguing as long as you're arguing Uh against yaml, I'll argue for it now just to say that you get all the schema you can do a whole bunch of things Easier, I mean like you get syntax highlighting for free and like I've heard all the arguments the other side of this too, so I think one of the things that uh, I know what i'm about to say will be extremely controversial Please forgive me. Uh, I think one of the welcoming facts to yaml is it they some people feel the The bar is a lot lower for entry to newcomers Then it would be to say learn You know declarative, you know groovy sort of Syntax so people like look at that and they say oh, I can understand yaml easier than I could if I have to go learn You know a job of a subset of you know groovy and and they're just like it's easier to do Drag and drop coding right I'm going to pivot a little bit like I think that In general the pipe like jankins does a fan and I use this analogy for the templing engine too is like It does a fantastic job documenting the oven like all the cool features and everything that is possible to do with it But it doesn't give you any recipes Right and I think jankin's x starts to go this route a little bit But maybe something we talk about is like You know, we can't tell you how to do your pipeline, but here's some common design patterns And how they're implemented in jankin's pipeline so that Yeah declarative might be intimidating to some newcomers But if they were to copy and paste like here's your git flow pipeline Just change these lines of code to match up to your tools And over time as you get familiar with it extend this to be what you need and give people a better starting point than just Like here's the syntax documentation That might be an avenue too Now I'll play devil's advocate on that Currently we have in in the jinkins.io site We have a node js example for a pipeline and one of the things I see in the getter channel More often than not at least especially the last week or two is people that cannot get that running And so now we like people like I found myself and a few others are answering these like node js questions on this pipeline because People don't understand how to use it. So I think if we do recipes, which I think is a great idea We have to make it as simplistic as possible including the environment to which it runs on So people understand this is what you're going to need to make this work Yeah, and if we accompany it with a docker file that spins up a jankin's preconfigured or something Um I used to teach programming and robotics to kids and over the summers in college when I was teaching if statements I would say if Quotes condition and you don't know how many times I went to a computer and they're like it's not running and it's because they literally typed if quotes condition So I I definitely that resonates with me that if we give them examples, they're going to be Our major source of support tickets um But yeah, like okay, so the the docker file to spin up an already integrated sample application with some some dummy reference architecture pipelines At least then we we can hope that as long as you have docker installed You're going to get the properly configured instance that has everything you need to run these examples Um, almost like catacoda scenarios Yeah Maybe that's what we need to do create some sort of No, like learning lateral, right? Yeah, there's club. There's cloudbees university, right like something similar on The open source side that's like here's a scenario. We're going to walk you through it In catacoda, you can spin up a jankin's instance as part of the environment for that Uh and embed it in the documentation site Uh There's overhead there and there's orchestration and it's it's not an easy lift But that might be another like learning opportunity for people One of the one of the first things I Sort of was looking at when I started Advocating with talking about jankin's and writing blog post was the the on ramp for new users Right, so this is this is the same kind of thing where it's like look How do we create an on ramp that isn't that that isn't, you know vertical? It needs to be a smooth sort of transition into okay Here's this thing and then like now you can like now you're you're up to this level, right? So I think in the creation of personas you have to also Have Some type of handoff per persona so that way if you know somebody as is is that at the beginner I've never used jink and flight now have to or want to They need to have that the handoff to the next persona should also exist. So started that bridge Yeah, and that can look like I mean I don't want to be super corporate, but it's like here's a demo lab if you can complete the scenario You're an advanced user or you're a intermediate user So we give them like I don't know A self-paced take it if you want to test so that we can like point you in the right direction based upon what you already know Exactly and then there's a prerequisite. So you can't if somebody comes in and says I should be here They should you know, we have a prerequisite that says you shouldn't be here unless you've done this Yeah, I found that everyone either thinks they're a beginner or thinks they're an expert right no one No one is going to come to and say I'm in the middle of the road They're they're going to say I've never used Jenkins before or I know everything about Jenkins Um, I don't know there's an answer. I'm out of that statement, but that's my experience with Trying to get people to evaluate their readiness for different topics Okay, I I want to switch gears to ask a question something that I have on here Uh, one of the things I have meeting caves. Do we want to do weekly? Do we want to make it five weekly? Well, we could do this this time works for me every other week, but it's actually I think it would be The reverse of what we had there I would need to be one week shifted. I'm pretty sure So you would next week this time you would be able to make it and then following every other week after Is that correct? Yeah, that would be That would work for me. I'm For sure Stephen, what about you? Yeah I think that works for me. My schedule is like a roll of the dice given different client sites I meetings just pop up for me all the time. It's kind of hard to know for sure Um, I can try to be strict about I'm not accepting a meeting But if someone says you have to go meet with the cto of this government agency, I don't have much Well, I mean, I would be the other thing to do Here is just I mean I can push things around and say look, I'm this is important. We got to do this And we could meet weekly even if there isn't a lot to do like make the time and show up and then Like if there isn't a lot to talk about great or if you know, we don't have the ability to do things that I think part of where we Sort of fell off last time I can talk to like why things fell off It's just because because the meetings were far enough apart and we were trying to sort of Boil the ocean as it were so Yeah, we had a we had a lot of different things to look at and a long time between meetings so people sort of Ran off to do with it like you sort of like oh, I have to do this thing here. I have to like get distracted. So um I also think the meetings weren't very conversational like it was a lot of someone getting a presentation on something that they had done And not as much as talking about listening. So I think there's a space for that like maybe You know every third friday or something we try to bring in use cases for people to show off like examples that might be I don't know thought provoking But doing it every time before they just become something that's easy to skip because they'll just watch the the presentation later If it's an ongoing conversation, that's something you want to be present for to help guide Fair enough. I mean the Flip side of that is though at a certain point. It's like, well, when are we going to do this? Well, when we when we have time, right? um Yeah The perennial open source problem like A lot of people it's not a lot of time to to do them outside of our nine to five Okay, so for what i'm going to do just just to close that loop. I'm going to move Uh, the meeting I think we have set for weekly right now I'm going to leave it For next friday same time But then following that I will move it to a bi-weekly and then we can decide from there if that's You know, it's too long in between and And maybe we you know, we work in in getter I do think one of the first things that's going to be critical for us is the personas So if everybody's okay with the meeting cadence, I'll I'll go ahead and action that Yeah, that sounds good to me I'm looking at the existing SIG page that's available. It looks like you found as well Marquis and you've got the document open so somewhere here. We've got Meeting notes from the previous section. Yeah um, and uh, I guess the action item for me is to Uh, go dig up more of those Okay, I'm looking at the link right now The SIG and I think it says oh like one of the things I just noticed that popped out of me. Oh like to start, uh ML discussion. Is that a machine learning discussion? I have no idea That's awesome. Yeah, right Okay, so I think we have what we need between now and the next meeting What do you think? Yeah, I mean Yeah, we'll we'll get the documents sort of to go And the start talking about personas and then so next time we'll talk about the sort of cover some of the Anything interesting from those docs and then also sort of go over personas and see if we have a See what comes out Yep, I will again. I'll share that document out in the uh in the channel. Okay cool That makes sense. I'm gonna spend time thinking about You know in a perfect world what this writing a Jenkins pipeline looks like Like I think that that's really the problem. We're trying to solve here If forget about what's currently possible just like It in the nirvana state, how would you want this to work? And then figure out what's possible and how we compromise to that that end state So I think that sort of goes back to the charter idea that you were talking about marky is like Our charter is how do we make this as easy as possible? We make it as easy as possible but like in a perfect world how does this work? And I don't know that we have a consensus definition for what that actually means Yeah, but I I think when we do have that and it's defined and it's met with personas People will come in and they'll say oh, I'm like this person in your you know I see you guys put your charter out there and for sonas. I'm that person and I'd love to follow that track Yeah, that sounds yeah Yeah, uh, okay. So another thing I have what I've got another action item here. I got a right I'm gonna make another action item. I am going to I need to get this meeting cadence added to the calendar Um, I can I have access to yeah the the Jenkins calendar. You mean? Yeah, um, I have access to that so I can Oh I'll leave it to you then Uh, I mean if someone doesn't already if neither of you have it already then Make it simple and I can do that Okay that and one other thing we do. Oh, I I'm going to get a look I'm going to get two emails out. I will revitalize the email to our pipeline off sig saying Hey, this is what we're working on. We just met. Here's a link to the recording Here's our document of things we're going to work on I'm going to get that out to our sig emailing list as well as to the dev mail list Okay, cool. And that way we can see if it you know drums up excitement Okay, so Did I create this for myself? Or did The the thing on the yeah the thing on the calendar. I'm trying to remember Doesn't look like it. Ah, there you are. No, you made it. Got it Oh, yeah, this one I made Yep, that's what I Looks like you've already got it set to weekly But this one is not on the community calendar Oh Oh, right, right, right, right. Okay. Yeah, this is more of this one is my I'm like, but it's already here No, it's not on the calendar He already did it. What's that? Yeah, slow. Yeah, okay All right, so got it. Um, and I'll we'll keep using your zoom for now. That's okay. Yeah Yep, that's totally fine I mean, I think there's a we could also do it on the actually we should probably do it on the on the youtube CD Uh, so, uh, so here's the thing. I am Uh We can keep it. Uh, hold on just a second. I have to yell something. Yeah, julie Check into your flight sporting, sorry, uh We can leave this zoom Waiting for the finalization for me to be a youtube admin. I can upload this video to youtube Okay And then something I want to do later on down the line is uh, I will link the youtube and create automation So it'll automatically upload it every time because I don't that's what I do for another community because I do not like Have to manually upload things. I want it to happen. Just sort of Okay Okay doki, um All right, well then we'll leave it at this for now and we can yeah Cool. All right. Thank you All right. Um, you want to have anything else? Okay, so do have the meeting and uh, okay And I don't have anything else Cool. Thanks guys Thanks everyone. Have a great weekend everybody. I'll see you next week later Cheers