 Hello everybody. Welcome to the Pipeline AUK SIG meeting. This is our weekly meeting. It is February 7th, 2020. Welcome. Good afternoon. Good morning. Wherever you are. Evening. I am Mark, Marky Jackson. I don't know what I do. I do a lot of different things. So, do I have a note taker? I can at least run the screen sharing. I'm Liam Newman. Hello everyone. Also on the call are Steve Turana and Mark Wait. And here's me sharing. Apologies. I'm not going to volunteer to take notes because I reserve the right to drop off. I've got a single topic that I'm trying to explore and so I'll leave it to somebody else to take notes. Okay. Awesome. I believe it is my turn for note taking. So I will take the notes. Okay. Nice. Cool. I know one of the things that we talked about last week was the personas. I did get those personas linked and they are in the document. I do think, however, we may jump the chain a bit here. Yeah. I want to ask Mark, I want to ask you a question. Would you be or are you going to be attending these meetings regularly? Probably not. I've got a specific topic. Yes. But okay, awesome. I don't think that I don't I suspect most of the topics here will not be things that would bring me in immediately. Beautiful. So we are going to move the new item which is meeting times to the end since we don't need you for that. But I am willing to say that you we can bring your topic up to the head of the list. That way we don't keep you. You're welcome to stay but there you go. So your topic was how best to document pipelines. Where to put the documentation. How best to describe. Yeah. So I think Stephen really said said this and he said it well is that this is really falls into the personas. Okay. So maybe for my benefit, do we want to do a review of the personas that you're envisioning? That would help me and it may help others who view this later. Most definitely. Okay. So we've got while you while someone's bringing up that personas doc. We've certainly got a number of places where we are describing the how to use pipeline. We've got the Jenkins IO documentation. We've got Jenkins minute videos that Liam had created. We've got several other places. We've got documentation built right into the executable that presents it computes the help and shows it live in a what appears to be multi megabyte page. Okay. We've got a bunch of docs. I'm not sure that we're reaching the right people. And so personas seems like so Liam, maybe you want to open up the personas document that's linked there. Sure. While you're doing that, I'm going to talk about something related or at least in the same vein about what you're talking about Mark that I found interesting and frustrating. And that was the developer documentation guide is very fragmented. Much like you described right now, it is all over the place. And because I have a little bit intimate knowledge about how we are structuring our docs, I know where to look. But what dawned on me and the reason I asked in your in your docs channel was, what if somebody didn't have that knowledge? I almost feel like we need to have a landing page that really points people to one set of like, I almost like to think about mind map, if you will, for our documentation to make it easier for newcomers. And the reason I start about that is because in the same Google summer code, as students come on and they're trying to figure out how to do things, they're like, I don't know. And I'm like, go here. But when you go there, you're going to also need to go here and then like multiply that by like 50. And that's the links I'm giving them. So when you talk about developer documentation, you what do you mean by that? Are you talking about like the unwinded stack here? So Mark, you my question is like, developer documentation is what? So in this case, what I would do, not the extent not the extent to Jenkins stuff, right? Not the know how to write. Well, I think what you first do, and this is where we have to have our inception of personas is I am a developer that knows nothing about Jenkins, where do I go? I want to do something code related with Jenkins, where do I go? Okay, well, you have now fork in the road, you can go on or maintaining or you can write a plug in. Here's where we now diverge the path of documentation. But we have that in all kinds of different places. And for the person coming on for the first time, that doesn't know that it could be a large sort of undertaking just to even understand where they should go. I think that makes sense. I think before we even get to like a major restructuring, what we should look at what's the level of effort to add a search functionality, right? Like there's some tools out there. There's some tools out there that can index the static site to expose like an index that can be used for a search box. I think that alone would go a huge way to be able to find a specific topic, right? I'm looking at the Jenkins documentation now, and there is no way from a page that I'm on to actually search the docs for like a keyword that I'm looking for. So you wouldn't just use Google search or Bing or you choose your favorite search engine to do that? The concern with doing that is I have found, and I like to use examples of how I came arrived at something, there was a gentleman in the Kubernetes Slack channel in the Jenkins channel that was asking questions about Okta. And my first thing when he pinged me offline at DM was, did you Google this? And he's like, yeah, and I found a bunch of CloudBees documentation. That only tells me a fourth of the story. So that's the thing, right? So when people do Google things, they get a mixture of Jenkins, they get a mixture of CloudBees. And I think we need to do good. We've got to maybe better at separating that. I think also it would require, it sort of assumes a level of Google foo that everyone might not have, right? If you're trying to search specifically the Jenkins docs, you should add the site prefix to your Google search so it restricts the results to Jenkins.io slash docs. And then you're still relying heavily on Google to index everything appropriately. It's definitely a possible solution. But I think there are some frameworks out there that for a pretty low level of effort can add a search box and index a site during the generation of the static site to make your search more tuned for your content. Yeah, I mean, like, so if I'm looking for time out, I mean, I think this gets me to the right spot, gets me to the right page. But it doesn't necessarily get me, well, kind of actually, no, this doesn't. This got me to basic steps as opposed to if I'm looking like, how do I how do I add a timeout to my like this? Google search definitely did not is not getting me where I need to go. It actually did go back to the first page that you hit. Okay, so your basic because it's a single page, you have to find time out in the right hand block and click it. Right. Yeah, so it's and there actually is even an anchor. So this is a good example like this is where one of those one of those tools would probably actually take you to this anchor, like that'd be much more useful. Right. Okay. And while we're looking at an example like that, like it would be interesting to see an actual code snippet of using that like I but this is I have experienced this this this thing right here is auto generated. So pretty obviously. So that I mean that there's there's text that someone wrote. That's that's fine. But I'm pretty sure this probably comes from the Java doc or something else. Well, so so Liam, if you take a different, let's take a different page and let's look at one that's still still auto generated. Okay, look for step slash workflow dash scm steps. And let's look at the get step. Oops, I gave you bad data. Look for steps. I'll find it here. So steps. Yeah, there it's this page steps reference search for the word get space plugin. Okay, and click get there. Okay, so this is a page that's still generated, but is is populated with examples because the examples were placed inside the source that's read by the generator. Okay, so this that means that we need that the this kind of plug in authors have to insert the the the examples into their into their into their documentation into their source code. That's what needs to happen is this needs to exist. Wow, that link is interesting. Okay, time out. So the link is there. All right. Yeah, so so it's very much doable and that's doable incrementally by doing pull requests to to these target repositories for their their documentation. So that's very much we can do that on this generated page. I don't think that would solve the navigation problem you highlighted earlier, where, hey, I didn't find with a search, something that took me straight to time out, right? You were looking for specific information about time out time and what what it Yeah, exactly. And what it gave you instead was a single page that has all the keywords in it a whole bunch of keywords in it. And you have to get lucky to find it. Right, you have to Oh, now look for the table of contents. Oh, there it is. It's in there. So I would, it's also an interesting point for the generation, like, if there's a way for the auto generator to control this, then having each of these be on their own, almost on their own page would be better, right? Yeah, it might be in any or that I mean, it would get us better Google results, because then, then right. And that's a that's a generator to separate. I think there's two separate. modes to talk about, right? There's navigation. Once you're on the site, how do I find my way around? And then there's also the separate problem of like, I need to find a very specific thing. Do I search from within Jenkins CI? So there's better developer experience or do I have to open a new tab and do a Google search and find it? Right? So we can talk about what's the best way to modularize the documentation to make it easier to find things? How do we organize those modules so that you naturally can find your way to them? And how do we bubble them up through a search functionality, whether that's Google or an internal search functionality using like a lunar or something similar to that is some conversation. And good insight, which which leads us almost back to the back to the notion of personas and how does the how those personas interact with the documentation? That's perfect. Thank you. Okay. So I think I think I've I've taken enough time from the SIG meeting. I don't need to derail on the docs. I feel like we've got the part of the thing that we're talking about. So it's perfect. Yeah. Continue. Sorry, I just don't feel like you have to like run off. Please stay a while. So it feels like we've got a and maybe what we should do is let me capture in the notes that we've got a navigation challenge, right? There's a there's a navigation. So finding it. And then there's a then there's a structural thing about how do we organize it such that it well maybe that is navigation, right? There's that. Well, who's searching? What are they searching for and why? Yeah, and also how do we how do we generate it? And like, what is what is the source of the documentation? Right? Okay. Do we know what the current framework is that's being used to to create the content from? I'm assuming something like mark down or ask you duck. It's asking. Well, actually, well, I think the combination is those pages that we were looking at. So the the page that we looked at with the get plug in. Mm hmm. That one that actually is written in the plug in source code as the HTML help for that step. And then a generator extracts from each of the plugins. There's their snippets of HTML help and their parameter descriptions. So in this case, I authored this thing by writing HTML in in a specific file in the get plug in repository. You had to write the HTML for it, not just ASCII Docker markdown. Right, it's it's really it's jelly. If I remember right now, I'll have to go look to see but I think it's jelly. No, no, I take it back. It's definitely not jelly. It is it but it is help because jelly is used for the UI forms but not for the online help. The online help comes from just HTML files, but inside the plug in source code. So it's, for example, so I have to get I have to get plug in here. Yeah, so if you go into source main resources, and now I think it's probably under Jenkins plugins get get step. In that directory, you'll find help dot HTML, click it. Let's see. Yeah, there it is. So we don't Wow, okay. So does this get pulled directly in to the website? Yeah, so the website is is static is a static site, right? And so there is a separate background process that extracts documentation from plug in contributors and places it into those pages for use in the in the static site. So I'm just thinking from a security perspective, if I were to put an arbitrary we both went to the same spot, like, Oh, dear. Can I add a script block that does whatever JavaScript I want to on the docs page? Sure, sure, if you are a plug in maintainer. And if you have, I mean, you you have just described a supply chain exploit, right? And there are a lot more interesting ways to do supply chain exploits than than the HTML page. If if I'm going to be a do a supply chain exploit, let's exploit the source code of the git plug in or something like that that's much, much more frequently executed than people visiting a web page. Yes, yes, it's a it's a supply chain exploit exploit. I am I'm thinking about like, someone registers a new plug in that looks like it has functionality. But really what their goal was was to add some some nefarious HTML. Yeah, I mean, I don't it's probably a different rabbit hole. But it's the same. It's the same exploit. Yes, absolutely. If if we if we take a nefarious plug in into the ecosystem, they could do harm. Alright, so so we've But anyways. So the question that the question that I have here actually is, can we make this easier? Because like writing HTML to get documentation is not not preferable. You're awesome. But I suspect most, most maintainers wouldn't either not have the time or not not have the inclination to well, write documentation, but also write it in HTML. Yeah. So I'm currently dealing with the documentation issue on, you know, in my day job. And there's a framework out there. That's targeted at distributed documentation called in Torah. So the idea is you give it a playbook file that just says all the different repositories you want to pull documentation from. It's all written in ASCII doc, and it gets pulled together. Right. So there are hundreds, if not thousands of Jenkins plugins. So a migration is a very large level of effort. But picturing a perfect world where like every plugin has a docs directory that has modules for documentation, and then a giant in Torah playbook that pulls it all together and generate the static site lowers the technical barrier to entry for people needing to know how to write HTML and starts to let you do an ASCII doc and a slightly more user friendly way. Yeah, so we have something like we have something very much and Torah like that generates the Jenkins.io site. It's not specifically on Torah because Antora didn't exist at the time we created the Jenkins.io site. But yes, the concept that you're using is describing as a good one. This, this is specifically reusing online help that we provide to users to also present it as our documentation. And so it's that this is a rather obscure case, the general purpose case of describing tutorials or describing how to guides, those are written in ASCII doc. And then Antora is and others are very happy to take ASCII doc and present them. So for instance, this, this help is actually is you can get to it from inside Jenkins to write correctly that there's a one of the question mark spots. Yeah, one of the notes that what stuff that appears at the side basically the little question marks. Well, it's just to be to be absolutely precise. This because it is a pipeline step is actually not available on any question mark because there really isn't a pipeline step for a question mark. Right. What happens though, when you're inside Jenkins, if I go to pipeline syntax to the snippet generator, the, the pipeline syntax page. Okay, anyways, continue. Yes. Yeah, if I go there, then there is a link which will take me to which will generate that documentation and show it to me. And, and it generates documentation for all of all of the pipeline keywords, and then puts them into a collapsed list. And then I can navigate to my specific keyword, expand it and see all that documentation. The and that that's that's great, except that that means in my Jenkins instance, I'm generating a multi megabyte file. Yeah, so if you'll open one of those open a pipeline job. Oh, no, actually, you can even do it here. Just put slash pipeline dash syntax on the end of your URL. It's also available from inside any jank any job that uses pipeline, but this will get us there. Okay, hey, online documentation, the second from the third from the bottom there, when you click that, you're going to wait a while. No, goes straight to pipeline. Okay, so, so that's different than my local Jenkins. Might be a little older. But in any case, now you've got me inspired. I got to fit. Well, anyways, there is a hang on and I'll find it and we can show it here. Here we go. So if I go to the, go to the snippet generator and select get the get step, for example, I get right, there you go. There's the yeah, and it comes off of this little exactly. That's where that that shows up. And all of that HTML that we read is in fact. Yeah. Nope, you're right. Online goes straight to Jenkins that I have examples reference. Okay, global. Oh, steps reference there it is Liam. Okay, go above. Yeah, step reference. When you click that, wait a while, basically generates that for my weight, keep waiting, keep waiting, because it's it's still generate you see that spinning up at the top. It's still spinning. I see. And that steps reference will take a good long time to get. Okay, now it's done. And now if you click that get now it expands. There's another view of it. Okay. So, gentlemen, I apologize for interrupting. I have to drop for something. Liam, I made you the host. Okay. Thank you. Thanks. Thanks, Marky. Well, and I think I've I think I've achieved the pieces that I was most worried about or most trying to to get insights on we've got people who think about this. And you're it sounds like you're open to the the idea that we might consider generating not just the single page on Jenkins.io for a step but have a page per keyword as well or something. I mean, like there's there's ways to the to improve that navigation. Yeah. Okay, great. All right. Yeah, and I'm we're I'm definitely open and you have just as much power on Jenkins.io as anyone else pretty much right. So you can you could actually now advocate that forward. Right. Absolutely. I was more looking for opinions than proposals for who did who will do the work, right? Okay, I'm I'm trying to understand. And for instance, I had missed the fundamental concept of personas that was brought up earlier here. It's like, Oh, yes, that's right. There are different reasons why people come looking for things. Right. And that thanks for letting me take that time I propose I'll call an end to my topic. Okay, because there's more to be thought about. And this is a not this is a very reasonable place to do it for discussion specifically about pipeline where there's a lot of interest in pipeline documentation right now. Yeah. Cool. Well, thank you. Thanks. Thanks, Mark. So let's see here. Mark, he was running this show and he actually had to drop. So let's believe next up was a persona documentation. Right. So we've had conversations in previous meetings about trying to get our better sense of who our users are. Try to categorize them into reasonable personas. Mark, you was nice enough to put that doc together. So maybe we can start going through that. Right. And I was basically I was looking at he divided these up by I think coding experience, OSS experience, I'm not sure what he meant there. And what the the sum experience, maybe the general experience like industry or CI, I'm not sure what the what that third dimension of items that he was looking for there. No codes and he had divided up to no code, some code and lots of code looks like yep. And OSS not OSS and then looks like three different in language, out of language and yeah, I'm still trying to figure out exactly how he how he divided that up. Yeah, it looked like it was around how much coding experience does the person have, how engaged have they been in an open source community in general, and then how long have they been in the industry? There might be some tweaking we want to make to that to make this a little bit more Jenkins centric, right? So a Java developer with 20 years of experience could have no experience with Jenkins. So we probably want an access in our personas that's targeted at how much Jenkins specific experience to somebody have. Right. Okay. So when could you clarify for me, Liam, what you what what I should infer by industry experience. So the language or is that that I've done continuous integration before? I still am not clear on what the so what I'm looking at is this last he is divided he has three characteristics on as this like top level descriptor of each persona. But I don't know what he meant by this last one because the values so far are some experience, lots of experience, and in language family and outside language family. Yeah, I was confused as well. I think we'll maybe need to talk to Marquis about what exactly that one meant. You know, the more axes we have the bigger of a combinatorics problem. This becomes right. If we've got three, three different ones, now we've got what nine different personas potentially. Yeah, looks like he has. Yeah, I think there's ways to collapse some of these a little bit. But it looks like he's got roughly three, three by four. So he's got like 12. Something now. Yeah, basically a through D and one, two and three. So yeah, 12. But I don't know how that where that that comes from exactly. Just some experience, just going to list out the combinations here. And there, I think he might have some overlap, some, like, two different things or something. Yeah, I know that he had mentioned this was repurposed from the previous persona exercise. So there might be some remnants from that. Right. Just thinking about the axes in general, I think there's also an important axi of scale. Are you building a pipeline for a single team? Are you building a pipeline for, you know, a set of development teams, and you're part of an internal tooling internal tooling team within your organization? Because the needs are typically a little bit different. I do think that we want to we probably want to set a cap of how many personas we have, right? We probably want to scope it to like four or five max. Yeah. Because my experience, people like to people like to name the personas so that like, they just become a part of our conversation. Like, Sally is an experienced developer working at a large scale. Right. In implementation. So this matrix is a little larger than than we want it to be for now. But I think it's good to start talking. So let me just grab this. I'm just trying to get a high level view of what he was. No SS versus OSS. Lots. Okay, so let me just start here. We have someone who just wants to be a part of the community sees opportunities to convict contribute and looking to ads to test a new career. Okay. So this is sort of like the getting started persona. This is somebody that maybe just started in software development, they find their first role as someone that needs to help automate software delivery processes. So what are what their needs right there? They're probably when we go back to that that idea of an on ramp, they're probably starting at the beginning of that on ramp, they need to understand what is Jenkins and what do you use it for? They probably need a lot of examples of different use cases. They'll need to understand that, like, what is a Jenkins pipeline in the first place? I think there's a lot of implicit understanding that like Jenkins pipelines are a custom DSL on top of groovy. That would probably be a good thing to explain like a high level overview of what even is a Jenkins pipeline. Right. I ran. That's the end of my ramble at this point. So what I'm going to sort of add here is what what do they need? Like what? So their motivations are this but like how can we and I'm trying to think about like how can we engage them but maybe that's this too early to think about that. Because we're still trying to sort of define these out. So I'm trying to see what he's looking at. May over volunteer. So all right. May. So this is no code. I don't know what the lots of experiences. I'm assuming it's it's I do feel like so far there's sort of there seems to be an assumption in these personas that the person wants to be involved in the open source community. That's probably a much smaller percentage of of users that are looking to get involved in the community. Right. A lot of people found that Jenkins is a good tool. They want to use it and they want to they want to basically accomplish their ticket and their sprint and move on. Not everyone is going to want to join SIGs and get their channels. So let's actually let's let's talk about this. So you have let's just pick up some ideas here. So you have an a new enthusiast. I'm trying to I'm just trying to like maybe we should just talk about it a little bit and people that we've met in in in working on Jenkins rather than like trying to be like really thorough. It's like OK. So who have I talked to? Right. I think I think we have Yuri the utilitarian, which is Stephen was just describing. Right. Yuri the utilitarian really just wants to get the job done and does not want to waste any time and can't afford to spend any time helping a community, etc. etc. Anything they are just get the job done and and get back to their solving their real problem, which is creating great software in something. And I'd probably say that at least 80% of the community, if I had to guess, if we look at the fact that Jenkins is millions of users worldwide, I don't think there's no 95% or more if human behavior holds any any usual thing. It's probably between the 95 to 99% range. Right. Most of us are utilitarian. Right. So I used to do my job. I don't have I don't have time to I'm to engage. Yeah. Right. And the sort of an inverse relationship between their engagement in the community and their understanding of experience, right? Like a utilitarian type person wants to be able to find things quickly, find examples, implement it, modify and move on. People that are involved in the community are have probably more context to why things are the way they are. And they're going to be more understanding of maybe suboptimized documentation organization, tying off of our last topic there, not to pick on the docs at all. No. So do what I want to do. And I'm out. If I can figure it out. That's the other one. If I can figure it out, figure out how to do what I want to do without, like even going to the docs, I will like they're not even they're not even going to go to the the mail, the, the, the dev list, they're not going to ask a question. They're just going to do some quick searches and run away. And if they can't find it quickly, they're just going to hack it together. Right. And that probably means that this person is is also the least likely to read about best practices or be strict about implementing them, right? They're going to find an example, hack it to do what they needed to do and move on to the next ticket. Right. A lot of times when I find someone asking a channel, a question on the channel for the first time, they're probably utilitarian that got stuck. Yeah. And you go and see what the situation is. And they took a tutorial, and then added 50 lines of code. And now they're they're looking to make that next step to maybe make this scale better. Right. And that transition is probably an interesting thing to talk about, too. We want to figure out how that pipeline of people go from utilitarian to contributor to maintainer or whatnot, right? Like, how do we get more and more people engaged to help out with these things? Because it makes everything a little bit easier, the more help we have. Okay. So those watching online, if you want to help maintain a couple plugins, let me know. Yeah. And this is I mean, this is where we end up with the silent, the silent majority on that use Jenkins, right. So I mean, I've talked before about this, and I just never I'm a member of the community. And I still haven't actually done it is like, creating a plugin that is that looks for patterns and usage and just like, pops like something in the log message is saying, Hey, this is where you want to go to find out about that. Right. So that we have some, some engagement with with people is Google analytics hooked up to the documentation at all. Like, is there a way to get metrics around who's looking at what? Yes. And it's significant effort to get the analytics. But we have a feedback site where people give us a, Hey, give us your feedback on this, which still continues to receive very interesting comments, some of them rather inflammatory. Yeah, others, others really painfully brutal. Yeah, the get plugin page, the one that we looked at earlier today was the most hated of any page on the entire site. And had the most negative comments. Thus, I spent some effort trying to make it better. Right. We'll see if that actually helps with the inflammatory comments that we get. That just means that it's one of the most popular, right? It's a numbers game. That's a that's a lovely positive way to look at it. I like that. That's a very good positive way to look at it. Whatever the reason, it was the top as having negative comments. And so we picked it first to target. I remember when I was working on this more, the one that actually got the most, most number of views was the one on, I think it was on agents. And the problem was that it was blank. And it was just like, it comes like, what is this? Which just tells us like, Oh, this is something that needs to get filled. Yeah. Anyways. Alright, so we go back to persona. Sorry, we could, we covered the person that's maybe getting started for the first time, the silent majority. I think the next step, I've probably I'm probably the newest Jenkins community member on the car right now. So I think the next step is doing the getter channels, right? Like, you have a problem stack overflow hasn't been helpful. The docs haven't been helpful. So you try to figure out like, who can I talk to about this? So you join a getter channel. So the people that have gotten to this point, probably have some Jenkins experience. Right, they have at least used Jenkins enough to know that they have a problem the docs can't solve. I'm trying to think of a there's there's still kind of on the utilitarian end, but they're social utilitarian. Yeah, maybe even like power users, like there are people that the average or most common use cases aren't working for because if they if they were working, they probably wouldn't need to have engaged on the getter channel. Right. I would call it Devon the desperate utilitarian. Are they desperate? It's not always desperate. Some of them they're they just means that they're they're like, mm, they're they've moved from just like I just used to get it done to can I use this to do something like can I use this to do one more thing over there? Right? Okay, yeah, so an extended extended utilitarian. Yeah. So Eric, the extended utilitarian. I'm trying to keep some mixture of of genders in here too. So, oh, so then Erica, thank you. Oh, very good. Yeah, or Ellie or yeah. Okay. Okay. So this is usually the point where people like, Oh, I can I can get Jenkins to do something. I'm joining asking questions. Right. And at this point, they start to have some desire to understand best practice, right? They're probably at a point where they want this to be easier for them. So they want to start aligning their pipelines to different design patterns that will make it easier for them to build and maintain. I just I just realized what this the person that this most often is, is I was told that I need to go use Jenkins. I was I was told I was handed the Jenkins instance after after after Yuri left. I apologize, I've got to drop off. Thanks to fade out. Thank you very much. Thanks for joining us and hope to see you again on here at least. See, I run into this persona frequently. Yeah, I inherited a Jenkins instance. There's a lot going on. I'm not familiar with what do I do next? Right? Most of the time, they didn't inherit a perfect Jenkins, following best practices, they inherited somewhat of a rats nest, because the person before them did what they had to to get it done. And they started to want to optimize learning. I understand quite a bit. I well, so they have a I have a working working system system to base my work my understanding on, but it doesn't make a lot of sense. Yeah, it's in your experience, how how frequently are the maintainers of Jenkins or the administrators different, using a different role than like the authors of the pipeline? At least in my experience, if you're administering Jenkins, you're probably also the person writing the pipelines, but I don't know the rest of the industry. That's true. Well, at this level, yeah, I think you are. Basically, after this, like, when you go beyond this, you get to I'm, I'm a member of a team that's been that's that's doing Jenkins, though that that I'm a member of the DevOps team that that manages a Jenkins for, like my my group, right? If you get it, you get sort of single team. You get a team or a person that does this for for one or more, like, it's just that they move beyond just one team to a bit more and they're doing. Yeah. So somewhere in here, you go from I write the pipelines to somebody else right that writes the pipelines, right? Or it's weird because on one level, you have the people that that I don't want to get lost just yet. So help and best practices to get so I can do less. So this person, they're probably not going to contribute to Jenkins, they're still looking, they're not going to be part of the community in that respect, they might, you know, but they'll be on they might be on the channels, they're going to ask questions, they've at least engaged someone, right? Yeah, I think these people are the bug reporters, but not the bug fixers. To write fair. Yeah, I think that's fair. Right. And then I think there's probably two more, right? We talked about the DevOps team. Okay. And then the one then we go all the way up to plug in maintainers. So DevOps team member. Let's just let's let's make sure that we got that. And then you have community member of one's developers. Yeah. Yeah. I think we can group all those like super advanced users into that a common bucket of maybe the power users or plug in developers. Project contributors. Let's go with that. It's a bit more than I'm so everyone contributes as long as they're even even just asking questions. That's helpful. But like, but no, I'm just trying to see whether or not that's that's a sufficient contributor might not be. Well, I think contributor could be like you help out on a particular plug in or you answer people's questions in the in the channel. Like these are really the pillars of the community that help out other people. Okay, whether that's through plug in development or answering questions. I think all those people probably have the same more or less the same from from our perspective, people that are, you know, involved with the community are going to be like, you know, so people that are long term project contributors is are all served in the same bucket. At that point, you've got the resources to find questions, you know, who to talk to, you'll be, you know, saying, Oh, I need to talk to this person or I know that this is a problem. So I'll ask that, you know, or I'll go over there. They're already well versed enough to they're tied in, right? Yeah, exactly. They have a network. Yeah. So if we focus on the DevOps team member for a bit, try to flush that out. This is definitely where I probably relate the most. Yeah, exactly. I think there might be there might be one at least one more persona in here, but I think this is a good start because we're and we're almost at time. But I think so if you want to fill this that out a bit, what do you think here? So I think I think person that the DevOps team member starts to worry about different design patterns and reusability, right? They're supporting multiple teams simultaneously. They need to understand how to how to do that, right? It is so hard to take off my company engine hat, because it's literally why I wrote it. So like this, I'm trying to think back to what my problems were before trying to solve them. And it was right. So it was really about how do you how do you build and maintain pipelines at scale for multiple teams? So there's that's when like global shared libraries starts to come in because you want to modularize code, right? So at this point, like this team member is usually the person that has written a giant global shared library for their team that different teams end up consuming. They start to care more about best practices like Jenkins performance and utilization, right now that you're building Jenkins instance that's going to support multiple teams. You have a lot more concerns about system resource utilization and like distribute build architecture. I'm trying to think if this person fixes plugins, like I don't, I don't think they do. It might, it might contribute. But I mean, like, I think for yeah, for ease of separating it, I think it's safe to say this person might like fix issues on existing plugins. We need to draw the line somewhere, right? The long term project contributors are like the initial they will create the plugin and maybe they'll guide direction and stuff. But you'll you'll lean on these DevOps team members also file bugs and help start fixing them. Right. They're probably more involved in the community starting to answer people's questions. Because they have that experience at scale. This person cares a lot about training for pipeline consumption, right? If they're maintaining a centralized Jenkins instance, that means that other people are consuming the pipeline. So documentation and developer experience start to matter to them. Hopefully, right? If I could get a list of all of these people, I would love to give a talk with them. Right. I mean, these are probably the people that we see most often at Jenkins world, that kind of thing, right? Yeah, they probably so just I was just going to say just by the nature of the fact that they're on a DevOps team, they probably work at a larger company where the role of a DevOps engineer has been centralized to a common team. So answering the question for my team or group, I need to be able to teach others to do to do pipelines to write pipelines. Yes, or right to either right or to I need to I need to I need to teach others to use Jenkins. Like that's what they're like. Right, and that could be as simple as like I need to teach the developers how to look at build blocks or view their test results all the way up to I need to teach the development teams how to create a pipeline. Yeah. Okay, I've seen a lot of different DevOps teams that like right that shared library and then all the development teams just pass different input parameters to it or something so they end up having documentation around how that works. Right, so these people are creating abstractions on top of Jenkins pipeline to facilitate scale. So we're out of time. And I don't know how long this marketing would go for, but let's so now that we've started writing this out, let's think on this for this week. We didn't get to I think it was a good start. Yeah, we didn't get to talking about a having a different alternate meeting time, maybe every other week. But we can do that in the Gator channel. If you're watching this on YouTube, recorded later, join us in the Gator channel and we're going to be figuring out a time to do these meetings, at least every other week or something that that supports more time zone. So and so let's see here, Steven, for you and me, maybe we can kind of continue building out this list. Sort of think about whether or not there's. I think there's I think there might be one more person in here. There's because I think I think what you've got here, the one thing I would say is I think that the DevOps team member, there's probably at least two personas in here. One of them is someone who's actually doing what you've done, which has moved into that, like, I'm going to write like shared library and tools and like that sort of bigger version. And there's a slightly lower version of that. That's that's a little closer to the, look, I, I, I, I write pipelines, I use pipelines, like they're maybe not thinking of that one next, they haven't gotten to that next level of abstraction, right? Yeah, and I think I agree. I think I think we have a good point to, I can try to flush this out and then I'm going to I can try to flush this out and then next week we can pick this back up and hopefully Marky will be able to join and we can talk through the content that was already here. Cool. All right. All right. Thanks a lot. Thank you very much. Have a good day. Bye. Bye.