 Hi, everyone, thanks for joining this week's pipeline authoring SIG, like all SIGs. We adhere to the Jenkins Community Code of Conduct, which basically means the excellent to each other. Looks like we have a pretty small attendee list when people have some conflicts today, but we can recap last week's action items and see if there's any new topics. We want to talk about the link to the Google Doc as in the Zoom chat. I can share my screen to show it. All right, so last week we talked about the 40 pages that Mark had highlighted for opportunities to improve documentation. We considered going through each of those issues and labeling which ones are best aligned to this SIG. I guess, Oleg, one question about that. How would we go about adding labels to these PRs? Who has the authority to add labels? So for labels right now, so we have two teams. One team is copy editors. So basically the team which reviews pull requests. And we have recently introduced the triage team, which is basically responsible for initial processing of issues and pull requests, and they also have permissions to label items. So maybe the way we should handle it is, when we identify those issues, we can open a new issue that just provides a list of other issues that should get the pipeline and authoring label, and then maybe the triage team or the copy editor team can then work off of that issue to label the other ones appropriately. That's one of the ways, another way we could just create an issue template. Because I've recently added the issue template to this repository. And for example, it allows community users to still submit issues with labels. Even though they have no permissions in principle. So all our approaches work, but like we discussed last week, I'm not really sure that there is any open issue which would concern the pipeline authoring seek. Maybe just one issue or two issues, but there are only a few issues because most of the documentation should be already on Jane Kaseyo for pipeline. Okay, so I think I probably agree with that. I'm not even sure that the CPS mismatch one is necessarily an authoring concern, right? We could probably say it fits in the SIG if we want to stretch, but I'm not sure if it's a one-to-one map. I can take a look at it though. Yeah, so we also talked about the hackfest that's going on. So we added a discussion topic for today, Chakin's UIUX hackfest pipeline authoring. So I'm trying to think, you know, is there an opportunity for the hackfest? Is Blue Ocean end of life? Right, is there maybe something around improving the pipeline visualization in the Chakin's UI in a way that's not as extreme as Blue Ocean that would be within scope for that? Yeah, and moreover, there is already a project idea for that. I'm not sure whether we published it on the website, but it's definitely on the student document. So we have a Google doc which is linked from the million list. Just a second, I'll put a link to the meeting notes. And in this document, we basically accept any project ideas, but yeah, as long as they relate to user experience and as long as there is somebody behind them who's interested to work on them or coordinate the effort. So just a second, I'll paste a link. So this one, I was sure I had these pipeline bookmarks. So it's basically a pipeline visualization. Yeah, so right now it's a wide open idea, so we haven't published it on the website because we need to at least provide some context there. So if you ask me, I would be happy to just say, let's put a pipeline browsing from Blue Ocean inside the Chakin's interface. Well, it's easy to say that. The problem that I'm not really ready to commit enough time to do that. But if there is strong interest from Pipeline or the Ring Seco or whoever to work on that during the hackathon, it would be nice. Yeah, maybe something closer to the current state. So for example, we have Pipeline Template Inc. engine, which could somehow contribute to user experience. Same for example, for remote file, plug-in for multi-branch, or maybe even for Pipeline is YAML. We could probably find some topics there because hackathon is just five days, and doing Loach integration in five days means that we need a team of experienced contributors to spend full time on that. It's just technically doable, but I'm not sure whether we are ready to organize it. Yeah, that's a good point. So for UI UX, are we primarily focusing on like design CSS, like look and feel type topics for the hackathon? Yeah, mostly look and feel. So just we have three tracks there. One track is user interface, which includes you look and feel, probably navigation and all other improvements, all accessibility and other topics. There is user documentation topic, which again may include some Pipeline related stuff, for example, documenting features, and including features into the main documentation, because right now we have pretty good documentation for core Pipeline on Jenkins.io, but if you try to look for particular plugins, most likely you won't find any documentation there, because plugins are kind of isolated, and if you had some time to connect all the documentation and plugin pages, it would be nice, because Pipeline, it's several dozens of plugins, even more, and even if core Pipeline is documented pretty well, ecosystem isn't documented well. So yeah, I think that's a common challenge I see people run into, right? It's like they'll see a pipeline step and they'll sort of look in the pipeline documentation, but that step's coming from a particular plugin. So I've seen that people have like a hard time figuring out where is this particular method being contributed from and where the documentation for that. My concern about offering ideas is like then being able to commit the time to actually fuel those during the hack fest, which is always the hard part, right? I have lots of ideas, but I don't know how much time I have. Yeah, right. So yeah, there are two ways, basically submit something you would like to work on yourself, or if you see that you have some time to coordinate the effort, then submit something what you would like to coordinate. There are definitely some abstract ideas we could put on the list, but for me it doesn't make much sense, because we already have quite a list there, so I would rather focus on putting real ideas. Yeah, I think anything we put on there should be something accomplishable within the five days, or maybe a prototype of something that could be accomplished in five days, and then maybe the folks that participate can drive it after the hack fest to finish it off or something, but abstract ideas are going to be hard to actually make tangible progress on, unless there's already like wireframes or something like that. Yeah, one idea which we could try, and which could be interesting, is to have a pipeline landscape. So yeah, just put a link to CNCF landscape, but basically without investing mass effort and documentation itself, maybe creating a kind of index where people could find a plugin, etc. So if you have a CNCF landscape. Yeah, the 7000 tools that comprise CNCF. Yeah, so it's a bit, yeah, CNCF landscape is definitely a pretty difficult thing to negate, but if we have created something for pipeline, it could have been easier. It could provide some benefits. I'm not understanding what you're envisioning with this landscape presentation, so this looks like vendors or comp products that are in the area? For me, it's just use cases. So for example, pipeline, we can have area-like tools, and then we put plugins like pipeline median plugin or whatever. Then we have area-multi-branch pipeline, and then we put remote file plugin. We have core area, and then we put all core plugins like pipeline job, etc. So the idea is each card would be, each card in this would be potentially a plugin or a collection of plugins, and then the grouping rectangles are categories or collections that those things might fit into. Yeah, something like that. Also maybe I could see there being a category for like, go ahead. Maybe enhancing this structure to all plugins would be much more better, because it's very hard to find what you need in the plugin side, even your search, but you need to go to lots of plugins and descriptions. Not only maybe limiting for the pipeline, but also for the other things that maybe we can group together. Yeah, we started some grouping effort on the plugin side. So for example, recently we introduced a categorization of plugin through GitHub topics, and it was applied to many plugins. Now you can query for Kubernetes plugin, for Azure plugins, etc. You can also query for pipeline plugins, but it just doesn't help too much because you get almost a hundred of plugins there. Yeah. So auto-generating something like that would be nice. Better navigation on the plugin side would be also nice. And if you're interested to propose something specific in this area, I think we could work on that, because I spend some time regularly to improve plugin side, specifically in navigation and plugin search, because I totally agree with you that it's impossible to find anything here. Yeah, I mean, like Jenkins is very rich when it comes to plugins. So like, I think it will be nice, maybe like, I don't know, maybe using some labels or something like, or maybe some maybe smart search, something like that, it will be much more make easier for people to find what they need because it can be really hard. Yeah, so if you're interested. When you search for plugins, do they show, does the results come up in like first founders? It's sorted by like number of installs or something. So that when I search for a particular, go ahead. There are multiple search options. So if you want to take a chance to show it to you. Yeah, sure. I can stop sharing. I might need to make you the host, which, right? All right, you're the host now, you should be able to share. Yeah. So do you see a new top right now? Yeah. Okay. So here's, here's our plugin site. Again, yeah, there is a lot of things under development today, but they are significant improvements. So here you can search and just for pipeline or whatever, you can sort things. For example, relevance, most installed, trending, it's the recent installations, title, et cetera. And Daniel Beck has recently introduced a metadata for plugin rating in update centers. It just hasn't been exposed here yet, but eventually it will be here. So they, you wanted to have a kind of plugin ranking based on various conditions like quality, et cetera. And Daniel started doing a grant work for that. You can also search for particular cases. So for example, here you can see that there are labels right now. We don't have label for multi-range pipeline. For example, it's something we could fix. But yeah, these labels are basically managed right now through GitHub topics. So US plugin maintainer can just put a number of labels and they will automatically appear on the plugin site in a few hours. So I'm going to add a few labels to a particular repository right now to make sure some labels go up on the site. Yeah, let's try to find this particular repository. Yeah, you might need to search like templating engine and it shows up as the first one. Or it did on my screen. So yeah, our search is not exactly Google. So it's not that tolerant with regards to mistakes. Yeah, here you can see that the plugin has no labels at all. So right now it won't appear. And the labels are useful because labels also appear in plugin managers now. So it's not on the plugin site in Jenkins plugin manager. All labels appear. And thanks to Daniel, he keeps improving for that part as well. Oh, you want to give? Cool. So yeah, you can improve navigation, you can add labels, same for example for remote file. Okay, so it's here. It has a pipeline label. But for example, for this plugin, I guess we really need a multi-branch label because with the current team, you need to read the description to understand what is exactly about. Or maybe it's actually better to rename the plugin at least display name. I don't know. Yeah, for that plugin, yes, maybe just for the others. I mean, even like a person who has experienced hard years in Jenkins, it can be really sometimes tough to find what you are searching for. Maybe indexing the documents from the Github rhythm files maybe can help people to find what they need. Yeah, search techniques. So right now we index name and the plugin description. So we don't index the full page for this site. Well, if you use Google, yes, you will get a full index. Let's think about it, because I mean, it should be easier for people who want to start Jenkins and try to implement things. Yeah, so what we started doing in Jenkins to the zero, we created setup wizard. It offers some plugins by default. It also offers some additional plugins. But yeah, this functionality could be much better. For example, if you use start Jenkins, you can also, it asks you whether you would like to get plugins, for example, for the net of iOS development. So right now it won't really show anything for us. Now it shows. So there is some backend query on the website. But yeah, generally, when you use these filters and setup user, you get the same advice. But the chat that you showed, I think it's very useful because like at least it gives an overall picture about what we have. Also maybe we can just define or divide this chart for different groups. Also maybe like for pipeline, a chart that which plugins are related to pipeline, as you suggested, or maybe like we can just change this graph to like maybe dot net grouping, the only dot net related charts, plugins in that style, maybe it can help. Yeah, maybe. Well, generating such landscapes for plugins and sets is definitely an interesting project. Yeah, I believe that it would require maybe a couple of months for experienced developer. But if somebody implements it, the number of sources would be really usable, not only in Jenkins. For me, I was thinking specifically about pipeline. Okay. And well, if you want to work on making pipeline plugins more discoverable, I think it could be also a good subject. I will not look at it. I mean, it will be nice to at least help in this context to make people find things easier for them. Just I will look at it. I will just search for things. I don't know if I can find anything, but yeah, maybe one thing we could do during the hackfest or before this have a special session about making plugins more discoverable. We had a blog, not even a blog post, I sent a couple of messages to the developer, mainly about that. I believe Mark has also created, for example, labeling recommendations. Maybe we could have a session about basically how to properly label your plugins to help users discover them. Feels like a user experience. Okay. Thanks for this suggestion, because I will definitely put it at least to the idea list. I don't know the situation about the blue ocean, so it is not maintained anymore. Well, I can translate official position. Basically, what was communicated in the developer mailing list is that this right now doesn't invest in active development. We still fix critical bugs and security issues, but right now there is no ongoing investment to develop new features. And there was a number of JEPs, for example, JEP for Bloat Ocean Extensibility, which wasn't delivered. And right now, there is no any expectation about it being collected. Personally, I really like Bloat Ocean as pipeline browsing tool. I have never used pipeline creation tool in Bloat Ocean or basically any other feature of Bloat Ocean except pipeline browsing. But Mark has some expertise with that. I've used it quite a bit to create pipelines. Is it useful? It is for me. I find it very simple. The things it can do, it does well. The things it can't do, it doesn't do. I found that it's really helpful for like helping people find the logs in the Jenkins log where something actually went wrong. I usually administer pipelines for development teams and I'll just get links to broken builds that say I don't know what happened because they pull up the build log and it's really long and they can't find the exception. So, Bloat Ocean has made it really nice to be like, look at the red bubble. The red bubble is the thing that failed. You should go read the logs there. Most of the time it works. That's right. So, personally, I would be really interested to somehow detach the browsing engine from Bloat Ocean. One of the big Bloat Ocean architectural problems is that, well, it was created in an opinionated way. So, it provides some advantages because it provides a good user experience out of the box. But it has significant disadvantages because you can actually extend that and also it declares a lot of dependencies. For example, if you want to use Bloat Ocean, you have to install Jira plugin and more than 80 other plugins so that it runs. Which is probably not... And for example, even at CloudBees, we had difficulties with certifying all these plugin sets. It was one of the struggles for Bloat Ocean plugin during the productization. So, would it be possible to implement this kind of Bloat Ocean UI into the Jenkins code? I mean, is it possible? Or it should be a plugin, always? I believe it's totally possible to make it a plugin. I mean, it would be a plugin, but it would be still a part of the Jenkins web interface so without creating new pages. Whether it's possible to put it right in the Jenkins core? Likely not because Bloat Ocean requires a lot of pipeline-specific stuff. So, I would rather expect it to become a part of pipeline plugin set, not a part of the Jenkins core. I might be wrong because, well, in principle, you can provide a lot of interfaces in Jenkins core and then somehow glue pipeline is there. But this would definitely require help from a core pipeline plugin maintainers. I'm not sure how much bandwidth they would have for that. Yeah, you'd have to do a lot with looking at the flow graph listener that they have implemented. You'd probably have to do a lot of SVG math to try and draw the path that Bloat Ocean makes. Sort of just assuming that Bloat Ocean probably has some hard-coded SVG pictures that they render for those different parallel branches and stuff like that. So being able to do it dynamically is going to involve some math or some fancy front-end frameworks for SVG path animations or something. It'd be a cool thing to do, though. It would be. So if somebody is interested to work on that, it would be cool. At some point, I was really thinking about doing it on my own, but for me, the problem is time. So yeah, I haven't even started. I also know for sure that Felix did some discovery on that topic. He was presenting it at the UX SIP meeting, but also the conclusion that it would require a lot of time to make it happen. You'd have to wireframe a lot of it out. People build insane pipelines with parallel blocks inside parallel blocks, inside nested stages. So we'd have to make some decisions around what use cases are supported for visualization without supporting everything. That's right, and Bloat Ocean was pretty limited about that. Good support for parallel stages just one or two years ago. I remember getting excited when that came up. Okay, so were there any other topics from last week or new ones for this week that we wanted to talk about as part of this week's SIG meeting? It sounds like for the HackFest, we might have an idea around creating a landscape page and plug-in discoverability. We decided that most of those pages for the documentation don't map cleanly to the pipeline authoring SIG. Are there any other topics that we wanted to cover today? Maybe quick update from me. So I returned back to the development of Jenkins for the runner. One thing I did, I just basically restored all the functionality. So now you can really build and test the project. I plan to revive my Bini project for using Jenkins for the runner for pipeline testing. So basically integration testing framework based on that. And the separate topic which I am planning to do quite soon is to include pipeline as YAML plug-in right inside Jenkins for the runner. Because Jenkins for the runner is incubated project itself. So I'm pretty happy to do such a change. So I actually wanted to do it before this meeting, but I didn't get to that. But yeah, maybe the only weekend I will finish that. But yeah, for me it's just another way to try out and maybe to provide some feedback about pipeline as YAML engine. Let's see. Maybe I can update. That'd be interesting. So really what did you say? Maybe I can give some updates about the pipeline as YAML plug-in. Yeah, sure. So I implemented these special steps with their own code blocks like with MIMO, with ounce or with credentials and also directly step. So I released the 0.3 version. So my next step is to implement this UI converter. So I find a way to add my link to pipeline syntax page. So I'm going to work on it. And also I would like to maybe in the future enable pipeline in YAML in pipeline jibe itself. So it is only now available via multi-branch pipelines. But maybe in future if the community is happy to use this pipeline as plug-in, I can also implement the normal pipeline. Also I will have some other questions. Maybe I can just send you an email or like later. Is it okay? Yeah, that's perfectly fine. Okay, thanks. I'm just making notes. So yeah, for me it would be really interesting to get pipeline as YAML adopted in the community. So once you're ready to promote it a bit, I'm happy to help with that. Thanks. I mean, I just don't want to talk to you in the details, like when it will be the right time, what we should add. I mean, this kind of thing. Okay. Yeah, so my actual item is still the same. I tried testing that. Yeah, I've been cleaning up my release depth, like getting pipeline, yeah, Jenkins file runout, getting custom work packages for our flow back to life. But yeah, after that I wanted to work on the pipeline as YAML anyway. So hopefully I will do some testing there. I guess I can give an update on the 2.0 release for JTE just on the roadmap now. I can share my screen actually. Oh, like you'd have, can you make me the list again? Oh, sorry. Please. Okay. Maybe you should fix the pet missions in this Zoom call later. Okay. Yeah, I'll work with Marky. So the last time, since the last time we spoke, we've got Jenkins.io project roadmap. So we have a new roadmap item for the 2.0 release with a scope document that outlines all of the things that I'm working on as part of the 2.0 release. A lot of it is like internal code cleanup, so that it's a little easier. So it's, you know, remediating tech debt, but there's a ton of other features that the community has been asking for around this, specifically around like library resources. And because of how JTE works right now, you can't resume a pipeline that it works with JTE because of some dark magic associated with how Jenkins pipelines work. So I'm going to be working on fixing that and improving the integration between the templating engine and workflow of CPS itself. I made a very, very pretty picture that visualizes the JTE source code because, at least from my perspective, the hardest part for jumping into a code base and helping out is knowing where to get started. So this picture that I'll end up putting in the documentation really describes what is everything going on inside the templating engine, just to see if there's anyone in the community that's interested in helping out on the development side of the house to implement some of these features. So that's my update. My nights and weekends are working through a lot of these features and cleaning up a lot of the code. So look forward to making more progress on that. Do you receive a lot of external contributions at the moment? Not a ton. I have a ton of users that ask me questions daily, but not too many people that are contributing from a code standpoint yet. So if you have any advice around how to foster joint maintenance or feature enhancements, I'd be open to figuring out how to grow the maintainers. So the first and the easiest step is to have newcomer friendly issues. So in GitHub, you can create an initial label with a good first issue. And if it's well described, etc, users tend to pick them up because in GitHub right now, they do some tooling around this label. So for example, when a newcomer contributor looks at the repository, they get an offer that, Hey, do you like this project? Would you like to contribute? Or also they have top level advisory tools where I'm not sure whether it's a new different issue, but still, it will be discoverable by users even on the top level GitHub, because GitHub can make some suggestions like good first issue Java Jenkins, okay, if it's your interest, here is a list of good first issues you could try. That's a good idea. So I'll pick a few issues that are sort of easier lift than some of the more complicated ones. And I'll label those and then provide a ton of instructions in the issue for exactly where those changes should be, should be made to try to help people get started. About things you said, Oleg, so is it better to keep the issues on GitHub? Well, keeping issues on GitHub provides some advantages when you want to onboard contributors, because issues somewhat discoverable, they don't need to create accounts for basically Jenkins JIRA. Also, there are some tools like good first issues and other such special labels which help to promote visibility. Whether it's a must have, no, it's not must have. But technically for new projects, if you ask me, I would rather use GitHub issues. It's an intentional choice there because we don't have the complications that we have with plugins where we have to be able to do security releases and keep security bug reports hidden. We just don't get security bug reports to Jenkins.io. So for me, it's a great excuse to learn how to try to fit GitHub issues into the Jenkins project workflow to see where they fit and where they don't. Well, right now, if, so for example, if you, Steven, could make me a presenter, I could show how it works. So, yeah, Mark is totally right. If we talk about Jenkins.io, but even without Jenkins.io, it actually works pretty well these days. So for example, I'm playing Kenji. So here, if I want to create an issue, here I get, oh, I don't, okay. But I just get to pop up here, report the security vulnerability, check out the project security policy. So what happens? We inject metadata on the top level. This metadata basically injects file to allow repositories, which recommends the security reporting flow. It looks even better if you have issue templates. So for example, in this repository, we have issue templates configured. And here you can create bug reports, feature request, et cetera, and report the security vulnerability. It's here because again, GitHub has automatic processing of metadata and basically it shows you the same page here. Again, it pulls it from the Jenkins organization white metadata. So you just gave me an action item for right after I get off this call to go create some issue templates for the repository. Yeah, I was actually thinking about creating default templates across the organization. Yeah, it just didn't really act on that because it would require wider discussion. But for example, for bug reports, for feature request, a common template would make total sense. But yeah, so it's something I had in mind when I started bot on GitHub automation. But then I switched to other tasks and basically I haven't really touched that. But you could try. Anyway, right now you can just basically take these files and copy them in your repositories. So it's not something like the rocket science. Cool. Thanks. Yeah, I'm ashamed I haven't done that yet. I appreciate the reminder and doing it right now. Yeah, so I don't know if you want to switch to GitHub issues. Yeah, you could do that. I believe you have all permissions to enable that. So basically in any plugin, you just go to settings and just say that enable issues done. Okay, cool. Yeah, I was actually surprised when you said the meeting that you would try to go with Jenkins Jira. But yeah. I mean, that's what I used to. So that's why, but since GitHub is very also useful and also better. Yeah, why not? Some advantages. So the real disadvantage of GitHub is that you have difficulties with linking multi-repository issues and projects. For example, now on the Jenkins project, we have some multi-organization projects like these ones. But it's not that convenient as it is in Jira. But if your project is isolated enough, then in GitHub, issues is quite convenient. I think it will be enough GitHub. I mean, it's really much more easy also for me to manage the issues. Yeah, you can also create small dashboards, including Kanban with all the automation if you want. I will check it out. Okay, that's a separate story. So yeah. All right. I think this was... Go ahead, Oleg. Yeah, I just want to say that we did a lot of research about how to improve contributions before October 1st last year. And yeah, we also got a lot of data that basically GitHub, which is much more effective for promoting contributions than Jenkins Jira, which is slightly not surprising. Yeah, the issues always stare me right in the face, right? So if it's in Jira, I have to go somewhere else to see it. But if it's right on the source code repo, then I'm notified right away. And it shames me every day until I fix the issue. All right. So we're about 10 minutes left. But if there's anything left, we can wrap up today's SIG meeting. I think this ended up becoming very productive. Thank you, Oleg, for showing me some of those examples that I can go implement. Yeah. I'm going to cut the recording then, unless anyone has any last-minute topics for today's meeting. All right. Thanks, everybody. Thanks.