 Hello, everybody. This is the Jenkins Pipeline Authoring SIG meeting for February 21st, 2020. This is the US meeting. And my name is Markey. And we are going to get started with this meeting. I usually try to think of a better way to do that intro, like something really cool. I wound up signing the stupid stuff. I apologize for anybody watching. Yeah, we're going to some 3D animation. Yeah, with some sound effects. Fireworks going all over. In the get a chat, the link to the notes has been posted. I will drop a lazy link here in this Zoom chat. If you could just add your name to the attendees list, that would be awesome. The link has been posted. And can I get a note taker? I think, Liam, you are always the note taker. Yeah, sure. I'm already going about sharing my screen and doing that. Beautiful. I also want to say something that we do this in another community and I'd like to start doing it here. And that's just to remind everybody about the code of conduct that Jenkins has. And really what it amounts to is just being nice to one another. And I think we actually all do that so that shouldn't be a problem. All right. I have added the entry for today's notes. We'll go ahead and get started with the first discussion topic that I've added. Due to overwhelming demand for a more EU friendly time, we've created a second meeting. This meeting will start Thursday, the 27th of February. And that will be at 6 a.m. PST. I added in a time converter there, so if anybody needs to convert their times. And largely I think that meeting format will follow this meeting format. But I think what we will do is I will feed, since that meeting starts Thursday and ours is a Friday, I will feed the following Friday's work items into that meeting. And then anything we've come out of that, I will feed that into our next day's meeting. So we kind of keep a good flow in between meetings and there's not a separate sort of work streams. Any questions about that? Awesome. We'll go into the open items. Last we spoke, we talked about personas and boiling those personas down. Has anybody had a chance to work on that anymore? I personally have not. So I'll summarize a little bit from last time, if I can get this to the, there we go. After you left there was some discussion, why is it you asking that? Around this end, we didn't boil them down so much as sort of get to a, we added one more. And the, so we have these, basically the, sorry, I'll get my talking cap on. We had three, topped out by David, who Steven sort of created at describing himself, for the most part. And I felt like there needed to be one more before you got to David level of someone who is not ops, but wants to use Jenkins like any other development tool. And comes and is coming into the Jenkins community, there may be new ish depending. And they, this is a persona that I definitely see a lot of and I think is underserved in pipeline tooling and pipeline documentation and all these things is someone who is, who wants to treat Jenkins pipeline as a, an environment that they develop, you know, that they write code in. And so as you can see here, they're, they're coming at this as a, hey, where's when Jenkins is a mature, Jenkins pipeline is a mature technology, where's my IDE, where's my testing, where's my important using external libraries and all these other things that they, they're coming at pipeline as, as code, which is both great and also not great in that, like it goes against some of the, the, the guidance that we have of, hey, pipeline is, you know, the glue, not, not a full-fledged development environment. And so, but that doesn't mean that we shouldn't have something that makes the, we shouldn't have the tools to make what people do, do in pipeline work well. And that's, you know, that's what this, this person is about. Okay, that makes sense. I think I was there when we were doing that one. And I think we all agree that that was a good one. It was that there was, we didn't, we sort of went on talking about it a little after you had to dive out last time of, of kind of fleshing out what that persona is. Yeah. So in previous meetings, we also discussed matching these personas to the maturity model and then linking to the documentation. That is still an action item that's open and that is still on my plate. So what do we get out of linking them to the, to the maturity model? Because, I mean, it's looking at this last time and they sort of, the way that we've lined, lined them up, they, they sort of roughly appear in, you know, the same columns more slightly, you know, or with some crossover, you know, one to two is, is on one side and then this sort of like a, on either side of that column sort of thing. Yeah. My thinking, my thinking. What are you looking at, looking for getting out of that? I was, the reason that I was thinking of linking personas to the maturity model is then we could link those to the documentation. And the idea there is. Which, which, which documentation? The Jenkins, sort of just the Jenkins overall documentation for various parts. And like various parts, just like, like, how do I run it? How do I start a pipeline? I am this persona. Where is the documentation to guide me? And I think one of our earlier meetings, and this is when Mark, Mark White was on, hello, Mark. He's not here. But one of our earlier meetings, we talked about the lack of documentation in, in authoring the pipeline. And really what we want to think before we can start to write any tooling around anything, we have to understand what documentation is out there and where that falls in the personas. Now that was just something we talked about. Yeah. I think there's two separate concerns, right? There's one concern that's the documentation by itself should could be organized, maybe a little bit more intuitively to be able to find the different topics that you're looking for. And then there's what we're talking about here, which is, I don't know that we need to functionally categorize the documentation according to persona, but we could have a landing page that describes these personas and then like elevate different pieces of the documentation to that landing zone so that someone can see themselves in a persona and find the docs. Right? So I don't know personally if we want to like organize it per persona, but we want to have a place where you can find topics on a page that correspond to what you're probably concerned about, that link to the more intuitively organized documentation. Does that make sense? Yep. Yep. But I'm not sure how the maturity model maps into that because I can see the personas like that's directly like, here's this person, we're serving that person. The maturity model, does that help us? Well, I'd imagine it might be something like when you go, like if you've seen like Panda's documentation, for example, they kind of split split it up into like, here's the beginner stuff, and then here's sort of like the intermediary user guide stuff. And then here's the advanced API reference with all the details. Sure. And it might be sort of, that might overlap a little bit with maturity model of like, you know, once you're in a fully mature thing, you're only using this as a reference documentation, whereas earlier on, you might be using this as an actual guide on how to do things. Yeah, I see it as a bridge. So when I come in, and I know nothing about Jenkins, it's nice to be able to look at a list of personas and say, Oh, that's me. And then that maturity model links you to where your ladder is, right? To be considered, let's say an expert, and I'm using that term lightly. But to know how to get from one to the other, you need to know what those others are. And that's where that maturity model goes. And that ties in with the persona. So if I could just to give you like the 30,000th of you, if I come into Jenkins and I want to do a, I need to know what a is, or where I fit in a. So you look at the personas and you say, Oh, I'm a new I'm a newbie. And then okay, I'm going to go and all this documentation is now shows what newbie should be looking at. And then you see once you've got this, you really move over to this persona now. And that persona is this maturity model. And you're sort of seeing how this gap or this bridge moves you up the ladder. Okay. So I think that there's there's a good idea of having like a what's next section. But the phrase maturity model. I feel like that could run rub someone the wrong way because not every Jenkins user is going to need to be an expert. So it'd be interesting if under the persona, there was a like things to look at next and then figuring out how we can have some criteria for when you actually need to go to that next level of maturity, right? If someone starts out learning Jenkins, then need to run a pipeline for like one application, one team. The documentation or tips that we're describing in our power user expert documentation is probably way more than they need, right? So being able to quantify how to avoid premature optimization and at what point of scale do you need to start being concerned about things like shared libraries or what have you? Does that make sense? Yeah. I think what I want to do like what I I'm looking at this from a different lens and I'm looking at it from the lens of the support questions we get in getter. And what I would love to be able to do is when a person's asking questions, the answer that I give them, I would love it to be dependent upon their maturity level in the ecosystem or I guess probably the best phrase to use. And so if somebody's saying I need to understand how to write a shared library and then I could say, okay, here's how we do it. Here's sort of our map and you fall in here and then because you fall in here, this is the maturity model. Here's the links to the documentation. Go read that and if you still find your stuff, come back to us. Did I? Does that make sense? I know it sounds off-putting by saying go read something and if you're smart enough, you'll figure it out. And if you're not, you'll come back and ask us a dumb question. That's not how I mean it, but I know it comes out like that. And I don't mean it that way. Well, I'm open to I mean, I guess what you're what I'm taking from what you're saying is that this is a another pathway through the another way to to find what kind of documentation you'd be looking for. So on one end, you have the personas and then on another one, you have a maturity model. And they're both ways of people finding their way to the kind of documentation that they need. Yes. Okay. So like, I think I've been in another community. Oh, go ahead. Go ahead. I was just going to say that like, being able to ask the question, I want to learn about shared libraries, has an inherent assumption that the person already knows that shared libraries are a thing. So it might be interesting to talk about it from a use cases perspective. Like, I want to be able to share code between pipelines, right? And then personas and use cases are going to be pretty similar in their goals, right? Different people are going to have different scenarios that they're trying to solve for. If we can organize the documentation around like those use cases that those personas might run into, because it's sort of like, if you're a junior software engineer, the problem is not that you can't learn it. So you don't know what words to Google to find the resources that you're looking for. So how can we elevate these topics without people having to know that they already exist? This sounds a lot like one of those XY problems where you have a problem X, but you're asking, how do I solve Y? But people don't know that your original problem is X. And in this case, X is the use case scenarios we can kind of show. And the Y might be when someone comes in and says, hey, how do I do this thing that sounds like a bad idea? But it's like, hold on, step back a second and see where you're coming from. And figuring out, like you're saying, are you asking the right questions or even looking in the right area without knowing based on your own maturity level here of the product? I will say this, and this is the cynical side of me. No matter which way we come up, someone's always going to complain that it's wrong. Oh, yeah. Well, it's always going to be less than, there's always new space for improvement. But it's one of those, you start to do it. Exactly. So I'm game with coming up with anything. And maybe if we just start with one small piece of it, getting it out there and letting people chew on it and see what they think of it, maybe we were able to iterate faster. I don't know. That's just a suggestion. Okay. So like, what do you think? What are you thinking of? Do you have something in mind? Maybe we start with like the beginner persona, which I think we... The utilitarian? Yeah. And maybe we just start seeing like, you know, maybe when people are asking questions general in the Jenkins Gator, we could start to just use that and try it out, kick the tires. Yeah. Yeah. I think if we come up with some of the questions that these different people are going to ask, that can expose either documentation updates that could happen to finding those resources more readily available, or it can introduce like feature ideas that maybe we need to think about so that this problem isn't introduced in the first place. Right. That's what I'm thinking. I more want to get the rubber beneath the road. I'm all good with like Jesus today. Right. Like if I'm a beginner, my first question is, what is Jenkins? Right. So glorified cron job, task runner. That's... I think it'd be interesting to figure out the types of questions we think these people are going to be asking and then use those questions to guide our decisions around whether it's a documentation problem or whether it's a opportunity to improve the developer experience of writing pipelines. I think one of the first questions that I always seem to get is, I want to run Jenkins locally. How do I do that? And there is documentation out there. However, it's not so great when it says, I'm on a Mac. How do I do that? Or I'm running Linux. How do I do that? Or no offense, I'm running Windows. No offense. So Liam, are you using Windows? No, I just, I'm laughing at the no offense. What? So I get that question quite often. And usually what happens is, is they think they are the beginner in personas, but really they've used Jenkins before, but they just don't, they're not, like you said, they want to ask about X, but they're asking about Y. So maybe I... I always start to get into like the stickier side of things, which is, does the community have a preferred way to do this locally? Is our preferred option, you say Docker, run Jenkins to some port forwarding and have your local Jenkins instance? Or are we recommending that people do Java jar or Java and set it up from the war? I have found that multiple people I've been dealing with, like I'll say, of the last three months, and if I say 20 people, over 15 of them have been using Brew. Sure. Why wouldn't they? Yeah. I mean, it's especially, it's super easy. But see, then... So they run like Brew and saw Jenkins and then they started up? Yeah. And they say, they're off to the races. Yeah, and that's just the Java dash jar wrapper. Exactly. There you go. So maybe we just do, choose us, choose one persona and just start throwing it out there. And maybe, I guess maybe the next big question becomes, when we throw it out there, what are we looking to do with it? I feel like right now we're trying to figure out what our backlog is, right? Like we know that there's opportunities to improve developer experience in Jenkins, but we're still in the early phase of figuring out, what does that actually mean? So I think this exercise is trying to populate our backlog of groups of topics we want to be able to address. I agree with that. I think that what I would add to that, though, is what is the next step? After we've populated as much as we can do, what do we want to do next? Well, that's the hard part. Right now we just can meet on a weekly basis and talk about things and have some good conversation. And then the next part is we need to start figuring out action items and seeing how we can fix things. Any thoughts around what that may look like? It's a really hard question to answer because of the open source model of its based upon people's availability to contribute outside of their typical responsibilities. I'm trying to think of maybe a good way. I think another problem that we face, and this is a problem, like when I'm saying about, you know, let's get a persona out there and start seeing how it works, I think one of the problems in doing that is then we run into a rabbit hole, right? We're going to start going off of this one persona and that could go on forever. What I don't want to do is turn all of this work into really we're trying to format for help desk. Better ways to deal with get or help desk issues. Yeah, I think that the most important thing we can do is try to capture these action items and display them publicly, right? If everything we come up with in this meeting is going to be relying upon the people that joined the meeting to implement, I think it's going to take a very long time. But if we can find a way to elevate this and label things like good for newcomers to write docs or just try to expose our backlog to the wider community and see where we can get help. Yeah, so maybe an option item there is to get, I can get it from someone, one of us, I don't want to take all the extra. Don't have all the fun. Yeah, right? Maybe we can get an email together to get out to them. A call for questions even. This could be like, hey, here's your free opportunity to ask a question. Maybe not say whether or not it gets answered, but you can definitely get a lot of good questions to get some raw data to help maybe extract some good clustering points or something, categories, you might say. Yeah, one of the things I'm really worried about, I'd be very upfront and with this, putting out a call for help and doing that, there are a cluster of people that just expect us to do everything. They don't want to contribute. They expect, you know, I'm trying to think of the right way to say this without sounding super negative. They will complain about everything, but they will do nothing to fix it. That's going to be true. Yeah, that's going to be true no matter what. There's always that group of people where they're fine to say that's at the report a bug and then you're like, cool, when are you going to fix that? And they're like, what are you talking about? So what are you going to do? I don't, I mean, I guess it's, I agree it's a good idea to be upfront and address that, but I'd rather not assume, focus nor assume it, right? It's a numbers game. There will be people that will contribute and you have to, I think we just have to sort of go, okay, here's what needs to happen. And we over time, either it will be something that gains traction with people and they'll be interested in doing it or they won't. Yeah. So maybe what we can do is just get an email out to the dev mailing list and our sig mailing list saying what we've done for this month or thus far, but maybe we get like, and we make that a monthly cadence where we send out an email and say what we're working on. And then somebody may read that and say, Oh, I'd like to write that, you know, and then they decide to join. Yeah. As a sidebar, is there like a SIG of SIGs, kind of like a scrum of scrums? Like how, how do we track if any of this work is already being addressed by like the documentation SIG or one of the other sub communities within Jenkins? I think we have to participate in those SIGs or someone from here would need to participate in them to get that information. Yeah. So I can tell you one of the things that is on the roadmap for this year for the advocacy SIG is getting a, maybe it's a monthly, we meet by weekly and we're thinking of doing a monthly cadence where every SIG has to come and report sort of the state of the union. Maybe using that as an example on this political free charge climate is not a good thing, but I think you get what I meant by that. I see it soon enough, it'll be modeled similarly to larger things. I mean, I'd imagine this might have been a useful case for having a Jenkins board where, you know, the SIGs could all make reports to the board and a board keeping track of being kind of rebroadcasting out to all the other SIGs what's going on between the SIGs kind of like the summary report. Yeah, in another community that I mean we have a monthly meeting that at various times of the month and I think it's each month they do it, four individual SIGs are randomly chosen to come and they have to give updates at that meeting. And if they like can't make it, I think they get like two passes and then on a third pass, they have to go meet with the steering committee and tell the steering committee why they aren't making them. That's not similar to what we do at Apache. So maybe, so I'll bring that to see where we're at with that and the advocacy SIG. I think we have a meeting next week and but what do we, how do we want, what do we think we can accomplish between now and the next meeting? Would it make sense to get an email out to both mailing lists sort of saying what we're working on? Well, I mean we're, yeah we're not done with personas yet. Just left to right some go through and sort of fill out what kind of questions they're going to ask. But we can say that's what we're working on. Yeah, that makes sense. We're working on personas because what I really want to make sure we're doing is we're being as transparent as can. Everybody can come to this meeting. We pretty much blast out when the meeting is done and where the recording is. But nobody, I think, I don't want to say nobody, some don't, they don't use that type of channel. So maybe we have to also add the emails monthly to say what we're doing. Thoughts? That makes sense. I think that makes sense. I mean that especially made sense up until you're adding the European friendly time for asynchronous viewing because I know myself, I typically don't like to watch videos of meetings but I'll definitely read through the notes or things like that when it's things that are outside my time zone or something especially. So I think it would definitely be useful especially for people who might not have known what it is exactly. This SIG was about because I'm sure there'll be some people who have opinions and want to help contribute. They just had no idea what was going on. Could be time constraints or they just are messy with email too. So I see Liam typing and now it gave me something else. We should do, I think we should do an email. I think we should do a SIG blog post. That sort of mirrors what we say in the email. And if nobody else wants to take that up, I can take it up. But I don't want to keep Fire Island to myself for any of you. Those are what about ball fans? I'm fine with you taking that on. I'll create a Google Doc. I'll share it out and I'll plan to say we want to have this out by March 1st. Okay. That gives us time to have that the first European time zone meeting as well. Yeah. And then I'll sort of explain kind of how those meetings feed into one another so people don't think they're separate work streams. That sounds good. Okay. You can assign that to me. And then if people want to look at the personas and add questions that they think that kind of persona, each of the kind of personas will ask. Does anybody want to take that action item? I don't know if I know enough about the different personas but I'll at least go through and add some myself. This might be a multiple person thing. Yeah. Like I said, this is kind of an add questions to persona, questions and this is kind of an all. Yeah. I'll try to watch the Gitter channel too and see like what questions come in and if we can map those questions too. Great idea. Anybody have anything else? That gives us a little bit of stuff to go on and what I'll be doing is for next week's starting of the EMEA meeting, I will, this is the stuff that I'm going to talk about. So I'm going to basically fill that meeting with the notes we have from here and then anything that comes out of that, I will fill that into our following days. Okay. Well, I mean, it gives us action items and gives us something to work on for the next week. Since you all probably fit under at least one of these personas, you could probably ask your own questions there too. Yeah. Exactly. Right. You know, like what's the deal with XML or things like that? All right. Sounds like some Seinfeld. What's the deal? All right. Okay. Cool. Thank you everyone. Nobody has any other things. We'll go ahead and give you back to like 20 minutes of your life. Awesome. Cool. Cool. Hey, everybody have a great weekend. Thanks. You too. Have a great weekend.