 Awesome. Hi, everyone. Thank you for joining this week's pipeline authoring SIG meeting during the course of the meeting. We're going to adhere to the Jenkins Community's Code of Conduct, which more or less just means be excellent to each other and be nice. We are recording. So if that's an issue for you, feel free to either not have your webcam on or drop off. This will be uploaded at a future date. The Zoom, excuse me, the meeting notes for this document for this meeting have been pushed in the Gitter channel. So I will share my screen so that we can track those notes one moment. And I can also post that in the Zoom chat one second. I think I can. I'm not sure if I can share and message at the same time. There we go. Everyone. Alright, so the link to the meeting notes is in the Zoom chat window. Feel free to join and add yourself to the attendees. I think we're going to start today's meeting with Mark, who has something to talk to us about about the user experience hack fest coming up at the end of May. So, Mark, I'm going to hand it off to you. Super. Yeah, so May 25 through 29 we're going to do a user experience hack fest, an online event to encourage people to help with improving the experience for users of Jenkins and the experience includes not just user interface look and feel which is certainly a compelling part of it, but also their experience with documentation and I think it's the pipeline authoring SIG is a good fit for, hey, there are ways to improve user experience in authoring pipelines. One of the specific activities I just completed last night was to identify the top 40 pages on the Jenkins wiki in terms of their access patterns. And I placed issues on to Jenkins.io in the GitHub repository for those top 40 pages will now work through those. And it might be a place where the authoring SIG might want to look at some of those issues help me process them and think about, hey, which of these are pipeline specific and where should that information be placed so that we can get some good first time contributor issues ready to go for this hack fest on the 20 that begins the 25th of May. Now, Oleg's joined us and Oleg maybe there's more that you want to highlight on the hack fest. I have a link to the current work in progress document. Yeah, I have almost completed the pull request for landing page for the hack fest. But if you want I can just show the Google document quicker. Sure. Let me stop sharing. Okay. Not sure if I'll have to explicitly give you permission to share if you can just. Yeah, we have to we have to hand over leadership of the meeting to him. The way that Mark has it set up is that way. Yeah, yeah, we could fix that later. Another later time. Yeah. I can share my screen in the document that you had shared in the zoom chat. Yeah, that's what you're going to use your way to go. Okay. Yeah, I'm just trying to the agenda and also to them properly. Yeah, unfortunately, all right. Yep. So this hackathon will have three main tracks user interface user documentation and also spreading the work sharing your stories. And basically the pipeline authoring have some cases in all three domains. So user documentation is what Mark presented already was spreading the word. Yeah, many people create pipelines. So maybe somebody could share the experience, especially development tools or how great pipelines with Jenkins or how not cool. And user interface, there are also some relevant tasks. So for example, one task, which we have tentatively put on the gently is improving pipeline and browsing writing in the Jenkins web interface. So not an abortion, but a classic Jenkins. It's under the discussion, but it could be done. And potentially pipeline authoring seek has other use cases. For example, they are topics in the roadmap like ID integration, etc. If they seek or wants to focus together on whatever single story, I think we could easily add it to the hackathon scope and maybe to facilitate contributions there. So you scroll down. There are some project tracks, project ideas. Yeah, you can see that there is a lot of things in TBD. Because we started something basically this week. But we try to get some stories on the table already. If you have any suggestions, especially this group would like to work on something together. It's definitely a good opportunity. I think that's a good idea. Mark, do you have which repository did you create those 40 issues on? Maybe we can go through those pages and see if there's something that's particularly well suited to this thing. And see if we can add labels for the pipeline authoring sake so we can track which, which issues are most applicable and we can maybe coalesce around those. Good idea. So github.com slash Jenkins CI or no slash Jenkins dash infra slash Jenkins dot IO. Yep, that's the one. And if you look at the issues there there are now 66 issues whereas before they were in the 20s. Each of these pages that are right now visible there say convert some wiki page to Jenkins that IO. And so what you might actually use the the github search facility there go back one Steven and if we just put the word pipeline in there I think it may may already hint if there are any of those pages which have pipeline information. I would be surprised because pipeline was created mostly after the Jenkins IO website. So Jenkins I was introduced into the zero and after that there was a major effort to create pipeline documentation. So I don't think we have any feasible or useful pipeline documentation on wiki at the moment. But at the same time there are definitely a lot of opportunities to improve pipeline documentation on Jenkins IO. Well and I've got lots of feedback from the docs feedback form that is submitted with Jenkins IO. So there's a docs feedback spreadsheet that we collect feedback from the Jenkins IO pages and many many of them are asking for hey give me better pipeline examples give me better this or better that relative pipeline. Yeah maybe you would like to share this spreadsheet link. Oh yes. So probably we need to move some of these stories to github issues. And last week we already had a discussion about replacing Google form for providing feedback by just github issues to keep things simple. I haven't implemented it yet and for me it's one of the topics I would like to address in the use of documentation. I think that's a good idea I am. I just saw one that caught my eye. I remember I opened a poor request related to this one around CPS mismatches log ticket run. So basically it was maybe all CPS right. Yeah I was surprised I just yeah Mark mentioned this when I went and looked just commented on it. This page is so relevant I think I would really like to expand this into more comprehensive documentation but it's kind of the best that I know of on low level details of pipeline for now. Great. Well and that's that. So Devin you and Steven just just inspired exactly what we hope for here which is help us identify which of these things are high value which are less value and that way we can we can make progress. I put a link into the pipeline authoring signals to the the big spreadsheet that collects all the data. Let me show it right now Steven just for everybody else's reference if you ever want to hear really blunt feedback from people sometimes laced with profanity about something they dislike about the documentation that's the place to go. Probably often it laced with a profanity. Right and I apologize for that but we don't filter it and that's okay. We just trust that you will turn up your your your comfort your your your barriers and not worry about them saying harsh things about something. It's like the help reviews right there's only the two ends of the spectrum that are going to provide comments those that are really happy and those that are really unhappy. Yeah why do they even game the the the four three and two starts really only one and five it's this. I don't trust people that give three stars. Something sketchy going on if you're giving a three star review. Right. Yeah, so definitely if you have four stars in yeah. If you see in the box and for example Liam David and you Steven you like to have a lot of experience with drinks by plane documentation. So you could just start creating a good hop issues for that. Because even if we don't handle them during the heck test it would be useful in the future. For example we are starting Google season of dogs. Hopefully on one day we will get a positive response about whether we accept it or not. And if you accept it the improvement by plan documentation could be also a potential project there. So just having issues etc. Would be helpful. I took a quick look at the spreadsheet from Mark and it just seems like 90% of it is people asking for examples on all the pages that give the steps documentation which is auto generated. Makes sense, but I mean, well, actually that that one I specifically had a concept, Devin that I think what we have to do there is more frequently point them to pipeline snippet generator. And say over and over again use the snippet generator that's already in your system. It will generate examples for you. Well, the examples right inside plugin code, because step generator uses Java doc, you can inject snippet straight inside Java doc. In some cases. Yeah, I think it's twofold I think, you know, the pipeline syntax generator. I don't want to call it a hidden gem, but it's like a trick that a lot of people haven't heard of that I interact with. So like exposing that in more places and then also in the plugin development docs maybe having a best practices section where we talk about be great if you could provide snippets in your in your Java doc. So that this is exposed in our documentation. Oh, like forgive my ignorance but I wasn't aware that Java doc was used so that I knew about the dot HTML files that I can embed and those those I've done with the get plugin for instance, but it was a lot of work. You're saying that it's some of it is extracted actually from Java doc for the classes for the classes and attributes. I believe so. I might have to investigate that thank you that gives me hope. Yeah, I might be messing copper. It was extension funds, maybe Devin his. Yeah, I don't think that Java doc works I think it's like the embedded HTML files and things like that. I don't know. Maybe we're thinking of different can you write Java doc a. Can you write Java doc extensions that like wrap HTML CSS classes to do code snippets or something that I refuse to accept the world as it is like maybe there is a way that you could write plugins for Java doc. To do some some syntax highlighting and stuff like that. Right through your Java doc. I'm going to create a type and library documentation generator. Java doc. I have published this final. I think definitely we could ask people to put examples whether it turns out that Java doc works or it's the embedded HTML help files. We could say hey try and put examples. Whichever of them it is. Or even if it's like we recommend that at the root of plug in GitHub repositories they have an examples directory. And then in your Java doc you just say like go go check it out here. You can see area and get up or something. The only thing about Java doc is that I don't really seems unexpected for me to have users be looking through plug in source code or at least like I would hope they don't have to do that. Well, we could apply more magic. We have a repository called pipeline examples. We could somehow automate extraction of data from this repository. Because our jink site website also has a lot of generation. So we could apply some magic to take examples right from pipeline examples repository. But yeah, this magic would need to be designed and implemented. It's definitely something we could do during the hack test. So I'm happy to just document it as potential project. You definitely have a tricky task of mapping the examples and the pipeline examples GitHub repository to the documentation pages that are auto generated from the plugins themselves. But that would be an interesting idea. Yeah. Alright, so the action items that are coming out of out of this are to I can make an actions item here to review the top 40 pages for opportunities. Align to the pipeline authoring site. And then from there, once we identify those, we can then see if anybody has the capacity to help improve those or as part of the access to do some improvement there. Anything else we want to consider for the the hackfest any of our features on on the roadmap that we've talked about from like I could now just unit testing call that user experience type stuff. Is there anything that we think would be a good fit for the hackfest. Well basically everything would be a good fit if you have either new befriended tickets, you could suggest. If you have a team which would be interested to work on that. So, yeah, we have a lot of ideas we could do. But, yeah, basically six could just discuss what they would like to do together. Have it the kind of team bonding event or whatever. Why not. So, yeah, you be a friend. We should definitely. Yeah, definitely the new beef in the side of that to try and and having more stuff doesn't actually make it better. It's more like, okay, let's. A certain points that we have enough. We could we could add more of the things but yeah. Okay, so that's coming up on the. I was just going to say it's coming up on the 25th. So maybe. One of the actions for those calls that that have the opportunity is to review. The hackfest page so that next Friday we can see if there's anything that is already on there potentially that's a good fit for. The goals of this, this thing. And see if we can try to break that down into like new beef friendly tasking and. And all those great things. Does that sound like a plan? Yep. So for next time. Actions and for next time is basically the same thing. So we'll. Add something here that review existing. Hackfest activities. For this next time discussion. All right. Is there any, were there any leftover items from from last week's. Meeting? I know that we, if I remember correctly, we talked about the pipeline is YAML. We talked about the, the new job factory idea that Steven Foster had proposed. Is there anything from that that we, we tabled for this time. See, not specifically. I still have to write those jure queries. I'm not, I have not had time to do that. So, but other than that, the other two things are. Basically, take a, take a look at the, the YAML plugin. And just give it a try. And then Steven, you had some questions that we have on the, in the notes. Again, I don't know if those are actionable questions or just be pontificating. No, they're just, they're, they're, they're questions that we want to keep in mind, but I don't think we have anything else. So, so is there any other topics we want to cover in today's meeting? We want to cut this one a little short. And we'll review these, the hack fest and the existing issues that Marcus created and we can regroup next Friday. I think we're good. Thanks soul. That sounds good. Awesome. I'm going to, I'm going to stop the recording. I would appreciate like three minutes of your time. If you could hold on after I cut the recording. Thank everybody for, for joining and we'll talk to you next week. Yeah. All right. Somewhere in here. I should be able to stop sharing. There we go. Hey, Devin. I have a quick question. The recording is still going. It is on the. Stop.