 Thanks everyone and welcome to the public Jenkins roadmap preview for contributors by Oleg Nanashov. Oleg? Yeah, thanks so much, Hujant, for the meetup. I will do the quick introduction and then we will spend the most of the time on the roadmap of Rio. So if it's your first time participating in the Jenkins online meetup, at this moment we host as a Jenkins community. We talk about anything related to Jenkins. So it's user stories, key studies, various features, plugin development, et cetera, et cetera. And if you're interested, you're welcome to join and you're welcome to participate in this meetup. The main idea is that there's a meetup organized by contributors for contributors. So we do not focus too much on slides and presentations instead of that we facilitate live discussion. We invite you to participate in this discussion. For example, you can submit your questions later after the presentation. We can have an open discussion. This is the main idea for these meetups. Thanks to Contissu Liberty Foundation and Kaldis who sponsored the meetup. And let's press it with the talk. So if you haven't met me yet, my name is Oleg Nanashov. I'm a Jenkins core maintainer and I'm one of Jenkins governance board members. I work on various initiatives including improving the Jenkins community, driving architecture changes, and I also maintain multiple plugins, probably too many, but I'm doing my best to improve the Jenkins system. At this meetup, actually I will be speaking of one of the efforts I was working over the past several months. It's public Jenkins roadmap. And it wasn't only me working on that. It was a joint effort by multiple contributors to the project in order to provide better transparency of how Jenkins evolves. And today I'm going to show a preview of the roadmap. So again, it's a preview. There are still changes going on, but hopefully we will be able to release it soon. So I mostly focus Jenkins contributors, maintainers, and advanced users who want to understand where the project goes and how it evolves and what new features to expect in the future. And especially if you can see the contributing to the project, I hope this talk will be interesting to you. At the same time, I won't be presenting any features per set today. So my main focus is process and overview of the roadmap in general. OK, if you have any questions during the presentation, please use Zoom Q&A. Mark is an event host today. Mark will be monitoring questions. I will be doing some breaks during the presentation to ask questions. And for the rest, we will do Q&A here at the end of the talk. After the meetup, if you want to discuss roadmap, there is a roadmap discussion thread in the Jenkins developer mailing list. You can find all the information there. And there is also a feedback form where you can share your feedback about this meetup and also feedback about the roadmap and the features you would like to see in the project. So if you have a few minutes to fill in this feedback form after the meetup, it will be much appreciated. All the slides are already available in public. There is a link, bit.ly slash Jenkins dash meetup dash roadmap. So you can just go to this link and find all the information there. OK, let's start the discussion. I will begin with a short history dive because Jenkins is a quite old project. It has been started more than 50 years ago. And there is a lot of things which happened in the project over time. I will reference Kosike's blog post from 2018 about shifting gears, where he referenced three main factors of success of the Jenkins project. So first one is extensibility. You can use Jenkins for any use case. It's basically automation tool, which can be just for your need, whether it's CI, whether it's CD, DevOps, et cetera, et cetera. Also, this tool is general purpose. So basically, you can apply it to any domain in the industry and also any automation use case. And last but not least, it's Jenkins community. Jenkins community is what is driving the project and what helps it to evolve. And this is a great experience for me and I hope for many other contributors. So what are the main factors of the Jenkins community? Firstly, it's open governance, starting from Jenkins renaming in 2011. Jenkins project has had open governance where everybody can participate. We have regular meetings. We have many at least. And the most of activities happen through these channels. Also, Jenkins evolution is largely defined by contributors. So what it means, the project evolves in the directions where we receive contributions. So it means that if somebody wants to implement a feature or implement a tool integration, if there is a contributor, then this feature happens. If there is no contributors, then, yes, this feature doesn't happen, but it is a separate site. But, yeah, this helped Jenkins to grow and to provide integrations with modern tools and with the quite ecosystem. Because again, everybody can implement what they needed. And you provide an open ecosystem for that. And it's open to any contributor. So whether you're an individual contributor or a large company using Jenkins and probably if it's an enterprise tool or providing support, consulting for that, you're welcome in the Jenkins community. You're welcome to participate in any meetings. And we try to improve this experience. At the same time, Jenkins community provides a lot of freedom. So if you're maintaining a plugin or another company, and basically you have full powers there. So you know that there are 1,700 plugins in Jenkins. But basically, every plugin maintainer is an independent entity in the Jenkins project. And they can make decisions about the evolution of their components, about rules, contributing guidelines, et cetera. So while we host these plugins, there is no strict guidelines. And everything is quite relaxed. This has been our approach in Jenkins from the very beginning. And for the record, I do not think that this approach needs to be changed in principle because it works really well. So yeah, I mentioned the 700 plugins. And there is a lot of changes in Jenkins. Over 15 years, we have become the most, well, basically the biggest automation project, at least open source project in the world. There are more than 250,000 installations. This is only one switch sub-interface statistics. And Jenkins project keeps growing. So every year, we receive more and more contributors. For example, last year, we had more than 5,000 contributors to the project. And after 15 years, the community grows. And a lot of changes happen there. It's not usual to see that in such old projects, but it's a pleasure to see it in Jenkins. If you want some comparison with other projects, for example, we have a diagram, which lists all the CDF and the Graduated CNCF projects. And you can see that Jenkins is basically the second biggest project after Kubernetes. And yeah, Kubernetes is huge, but Jenkins is also huge. And smaller circles there are actually pretty big projects with healthy communities, with hundreds of contributors. But yeah, Jenkins is really big. And it evolves in many directions. So you may have used the Jenkins for years, but you can see that there is evolution of the project. And there is a lot of new features being introduced. So just to highlight some which have been introduced relatively recently in the Jenkins project, it's pipeline as code. It doesn't mean on the Jenkins pipeline plug-in ecosystem. You can use other tools like jobless, sale, other plugins, but you can define your CI, CD pipelines as code. Also, configuration as code, which allows to build the entire system as code to apply infrastructure code and DevOps practices to Jenkins management. And along this pipeline as code, basically you can manage your entire instance as code. We keep introducing new plugins and integrations for many tools, how it happens. If somebody wants an integration, if they contribute time, then this feature happens. And again, for the most of recent tools, we are happy to provide plugins from the Jenkins update centers. Also, Jenkins doesn't stay as it used to be, let's say, in 2008 when there was a Warfile and several distributions. It provides a modern packaging, for example, for Docker, for Kubernetes, Wilhelm. Also, there is a new project which provides a Jenkins operator for Kubernetes. And there is a lot of other changes in packaging and ways how we distribute the project. And also, there are distributions for public cloud. So in many cases, you don't have to spend too much time on the configuring your Jenkins and to setting up it up because there are also packages which provide required plugins and integrations to quickly disrupt your Jenkins instance in the cloud. I just mentioned a few projects. There is a lot more of them. But I want to highlight that the project evolves well. And there is a lot of changes happening in the project. At the same time, there are some obstacles which we hit. And these obstacles are not exactly new to open source communities. We are no exception in this rule. And just to list a few of them. Firstly, taking the size of the project, we've put a lot of resilience in some Kubernetes. Again, having full independence in plugins is great. But at the same time, for example, there are common process and expectations from users. So security process. And we still need to deliver on these expectations. And when there are multiple communities, we should not frequently communicate with each other. There is a lot of disconnect happening. And again, we experienced it in our project. And we try to fight with it. Also, there is a lack of transparency. It's not because there is an intentional lack of transparency. You can go to G-Ray. You can go to Madein.js. And you can discover a lot of information. And also on GitHub. At the same time, you as a user, if you just go to the Jenkins website, you may struggle to find the information you need. So you do not know where to start. You do not know where the project is going. Yes, by investing a lot of time, you can find this information. It's hard to understand how some decisions are made, what are the plans, et cetera, et cetera. Also, it may be perceived as a lack of focus. Because again, as I said, Jenkins evolution happens in directions where we get contributions. And it means that if there are 100 contributors interested in different topics, then Jenkins may be evolving in 100 different directions. It may be good from the project diversity standpoint, but at the same time, for a standalone contributor or just user, it's hard to understand what actually happens in the project. And the same issue from another side, we have a lot of contributors, but if there is a big initiative or if there is a major cause in the project, for example, if we need to deliver a big feature like configuration as code, if you just want to address security vulnerability, which spans across multiple components and hopefully not announced in public, then it's hard to facilitate the community because it's organized in a quite different way. And it has been in change for us for a long time. At the same time, if you're interested to join initiatives, it may be also hard because even if there is a lot of initiatives, you can find information on how to join, how to contribute, and how to participate in a particular initiative. In some cases, you can find this information. In some cases, it's very hidden or implicit. Maybe it's to experienced contributors, but probably not obvious to the community in general. And with all these factors, with a huge community, Jenkins has a relatively small core team. What core team means, it's not Jenkins core maintainers, it's a team of contributors who are interested in the project and ecosystem in general, who invest their time to maintain the ecosystem in general, not particular components. And for me, these contributors are the backbone of the community because they help the project to grow, they help other contributors to join the project. They facilitate various programs, provide expertise, and this is critical for the open-source community. So these common issues for many open-source projects, I hope I do not provide, so there is nothing really shocking there, I hope. But actually, we are well aware about these issues and over past years, actually there was a lot of consolidation efforts in the Jenkins community. And it started long ago. So for example, in 2012, there was open governance introduced in the project, the governance meeting introduced, which allowed to discuss common project matters and to agree on particular decisions including strategy ones. In the southern 15s, there were teams and Jenkins officers introduced, so governance board that is generally consist from three members. We also added three officers. We introduced multiple sub-projects like infrastructure, Jenkins area meetups, later technical projects like remoting or Jenkins area green. And this helped us to create a group of contributors focusing on particular efforts to somehow coordinate these efforts within these groups. In the southern 16, we also started outreach programs with the main goal to onboard the contributors and to onboard not only new contributors, but also to onboard the contributors from our plugins and other peripheral sub-communities to the core team. So basically growing this smaller core team, which basically focuses on the sustainability of the project. Then into southern 17, we got Jenkins enhancements proposal process. So basically it's a process which allows to publicly propose changes including architecture ones, process ones. And this process by now got more than 40 JEPs submitted and many of them have been implemented. So it helped us again to become more transparent about the initiatives we have and to provide the venue for reviews and discussions. Into southern 18, we introduced the special interest groups. It's basically working groups interested on particular topics. For example, a platform special interest group was the first one to be created and there was cloud native special interest group, advocacy, Chinese localization, et cetera, et cetera. So these working groups focus on particular topics in the community and keep the evolution. They have their own plans. They try to facilitate contributors to their six and they deliver on various initiatives within the scope of interest. In 2019, there was advocacy and outreach seek introduced and one of objectives of these six is to actually grow awareness about the project, grow contributions and help new contributors to join the project and to be efficient there. This seek took over various events, outreach programs and also various things like contributing documentation and it helped us to get more contributors and to provide the support from the beginning for the contribution experience. Then into southern 19, we had the governance board elections. So our governance board group from three people to five we also restarted the governance meeting. We wish we were a bit dormant for a few months before that and the project started evolving in many directions because when we have more governance board members and when governance board members start getting involved in particular initiatives and start facilitating these initiatives, again, we can have more focus on particular areas. So this is the current state. And actually if you can see the Jenkins community is cares, it's not. There is a lot of various community entities available in the project and these entities grow, they have plans. So from the project standpoint, we actually do have some plans, we do have some transparency, we do have ways to contribute, but there is still difference between a project and a community because community involves Jenkins users, adopters who are not fully involved in the project, et cetera, et cetera. And since we have some transparency inside, maybe we could also provide some transparency outside so that we can help users understand what's going on in the project. So, yeah, it was a quite long introduction, but yeah, are there any questions before we move on to the roadmap? I haven't seen any, but I was particularly impressed by your observation on the transparency. It was becoming public about our plans makes it so that people can see very rapidly where we're going, not just having to do an awful lot of research to go find the direction in amongst all the public resources we have. So, I love this for that reason, it makes it consistent and consolidated so that people can find it readily. Exactly, yeah. Okay, let's move on and let's finally talk about the roadmap. So yeah, a public Jenkins roadmap is the way we should put in full feasibility of initiatives happening in the community. And we started discussing public roadmap for real at Fosnum 2020 Contributor Summit in Brussels, in Brussels, it was in February. Before that, at the Contributor Summit, we were implicitly discussing roadmaps like by Jenkins Goals, et cetera, but we haven't ever put effort to communicate a wider roadmap. We were talking about particular features, particular initiatives, but there was no 1,000 feet overview of the Jenkins project. So the idea of roadmap is actually to provide that. We started working on that in February, much we created the Jenkins enhancement proposal which basically recommends a roadmap process. Again, it's a public process so everybody was able to review and contribute to this roadmap and the process. Then we published the first preview and in April 2020 we had the first roadmap meeting. Hopefully in July, maybe in a few weeks, hopefully next week we will be able to publicly release that. And this is an objective for me and the today's meeting to provide heads up contributors about what's going on there and what to expect and how to contribute. Okay, just to spend time a bit on the roadmap, I'll probably just show it to you so that we're not just talking about the roadmap concept without anything. So this is our roadmap preview which is currently published on Jenkins.io. This roadmap is publicly accessible. It leaves various initiatives. It's a focus on Jenkins users and the community. So we focus not on a particular specialist groups, not on particular entities, but on user use cases, for example, pipeline authorizing tools and integrations, user experience management or Jenkins on the cloud, et cetera. So we also list the initiatives which are a part of the community. So again, regardless of what is the area of initiative, you can put it on the roadmap. So for example, here we have developer tools and services, basically initiatives which help contributors to develop Jenkins. Also, we have initiatives focused on a contributor onboarding and facilitating Jenkins contributors on advocacy, on reach, and also on internal stuff like Jenkins infrastructure. So there are parts of infrastructure which are visible for you. I will just click this button. So for example, we have an initiative related to modernizing Jenkins mirrors. It's a part of user experience because it makes the infrastructure more stable. It provides plugins, it provides faster setup of plugins, but at the same time, some projects are basically hidden and have no user impact. Still, they're important for the project sustainability and for its evolution. So we list it on the roadmap. And last but not least, we have governance listed. So these are what we have and you can find a lot of items there. So for example, pipeline is YAML, there will be a presentation at the Jenkins online meetup in 10 days. Also, there are various initiatives like dark team which can already try out plugins like machine learning or gig performance and big hub checks and various community events. So for example, you may have UI UX Hubfest and you can find it here because again, it's pretty important to improve user experience and interfaces. And also you can find various changes related to the administration. So for example, system rate permission, also script security improvements, but management, various things like pluggable storage. So you can find all of that there. And same for the cloud, you can find some initiatives there. Again, the moment we don't list the entire, well, there are still some initiatives which might be missing and we invite contributors to submit the initiatives. If they're working on something big. So if you go to this link, how to suggest a new roadmap item, you actually find guidelines which describe how to do that. And this process is really simple. You basically go to Jenkins IO and submit a pull request against our YAML file. So this YAML file basically implements open data for the project and for the roadmap. And you can find a lot of initiatives listed here. So each initiative have name, some description, status, link to details where you can find more information contributing guidelines, et cetera. And there's some labels which help us to filter initiative. So if you want to contribute the item, you just create this roadmap and it is in a forks, submit a pull request and then it will be reviewed by the governance board and hopefully published on the roadmap. So this is a quick introduction of how it works. And I also want to describe how it works in principle. So the main idea is to have open process so that everybody can contribute decisions and the evolution of the roadmap are fully transparent and that you can access this information about these decisions and about why we need them. Also, there is open data, so everybody can access current snapshot of the roadmap and its history if you're interested in that and if you're interested to take it and use it for your decision-making process. So for example, if you're Jenkins vendor, you discover initiative like system read permission and think, okay, probably it's time to invest in supporting it for my users or probably it's time to prepare and to train my teams, it's also possible and this is why we provide the roadmap. As users, you can also see what's happening and you can prepare new features if you see new features in preview and actually we have quite a number of them. It means that you can try them out and you will appreciate any feedback you share and also you as user can explore them and for example, prepare to the adoption or the set whether you adopt them at all. So again, the roadmap could be helpful for users and everything is aggregated on a single page. So another thing which is important that everybody is welcome to contribute. So anybody can submit a roadmap item. We encourage special interest groups, teams and some projects to contribute items but in fact anybody can do that and we will appreciate the contributions by anyone. And the roadmap is fully community-driven so it means that if you're interested in something then the roadmap can help you to facilitate the process. You can try to find more contributors even if you find them, you can also put them on the roadmap start discussion as a special interest group on amenities and hopefully facilitate the change you need even if you don't try to put them on. It's how community works because you can facilitate changes without committing on your own. The same time, roadmap is a community roadmap so it means that there is no commitment on this and any means. Basically, Jenkins contributors work on that. We make no commitment on delivery days or for the record no commitment on delivery at all. At any time if there is no contributor then the initiative may die off then at some point somebody may take it over and it's alive again. It's a part of the open source process and we have no intention of changing anything there. So the roadmap will be developed on its own and that's how we work on that. I already talked about the roadmap. Meanwhile, did we receive any questions? No question yet. I do like and I like to remind people that physical maps of roads also only have a publication date not dates that look into the future. So I don't feel guilty that we publish your roadmap that doesn't have dates on it. Roadmaps are not supposed to have dates. There are different approaches in tech industry but it's a completely separate topic. Okay, I briefly summarized what we have on the roadmap and the roadmap process. So I will just give these slides and actually I would like to spend a few minutes about how it works in principle. So we haven't discussed these stages. So we have released the stage which is quite obvious. It means that the initiative is completed and that there is no major follow-ups needed to do that. They might be still improvements delivered afterwards but largely we think that this initiative in the review means that something is available to be used but it's not considered as general availability. So what it means might be a plugin which is in a preview state available through experimental update centers or experimental incubating project or the experimental beta API which is available but again may change or if you scroll down there might be preview processes, various things like tools which are available but still need some changes. For example, change log automation we started using for that more than a year ago and still in preview because we know that we need to update the process in order to address changes in how GitHub applications work and same for other items. So preview basically provides you a snapshot of what you can try and there are guidelines how to try that. Current is what we are working on. It means that there is something there, there is ongoing development. At the same time there is no trivial way to try it out but you're welcome to join this project to contribute and we will welcome any feedback. In many cases it's possible to try these changes out but it's just not trivial. Near term it means that initiative is planned to be worked on soon and there are contributors who declared they intend to work on that and we expect it to start soon. There might be some contributions, proof of consults but generally there is no ledger push which would say that let us say that it's in current state. So this is what we expect to happen. Let's say, well, it means future, no dates given. And future, it means that there is consensus in the community that we want to do something about that. At the same time we do not provide explicit timeline for when it would happen. It doesn't necessarily mean that there is no contributors who are interested to work on that but maybe contributors understand that there is no time. At the same time we want to list it on the roadmap to highlight that this is a direction where the project will evolve and there are directions where we invite contributions. So even if it's in the future you're welcome to join and start contributing if you're interested in this topic because that's how these topics would move. Okay. So, yeah, this is our roadmap. Since there is no questions in the chat I will briefly finish the presentation and then we can talk about the aspects of the roadmap. So what are the next steps for me? Firstly, to keep addressing the feedback and to update the Jenkins and Huntsman proposal to reflect the actual state on the roadmap but at the moment what we really look at is feedback so that we can improve visualization of the roadmap maybe add more details, add more roadmap items and it would be great if you're interested to submit your items. At the same time we do not let the project be blocked by that because again Jenkins and Huntsman proposal 14 documents not the roadmap itself documents the process and the ones that you've published the roadmap will keep evolving and on next week we plan to hold a Jenkins governance meeting where we will discuss whether this roadmap process is ready to go. We battle tested it, governance meetings full request reviews and personally I believe that it's ready to go. On the governance meeting we will vote whether it's ready to go or not so I'm not sure whether it will be published but we'll see. One of key contributors today is Alex Sal and thanks to him for becoming a BDFL delegate because it's not me who does the decision about publishing this job it's another governance board member so that we ensure that everything is ready and on July 15th it may have to be actually delayed a bit. Once it's published we will host webinars for Jenkins users so today is rather introduction for contributors we will also do social media blog posts etc in order to facilitate traffic and feedback to roadmap and again we will keep working on the content and improving that so that if you have something to share and any feedback it's definitely not on July 15th all the time. And we will keep regular roadmap meetings like recommended in the process so if you open this job you can find that there is a lot of items and one of the items is roadmap review meeting and roadmap maintenance guidelines so basically these are two sections which document how we go further and for roadmap review meeting we will be doing a quarterly public roadmap review most likely it's a part of Jenkins governance meetings later we have technical steering committee technical steering committee is on our roadmap so once it's there we may change the process but right now every quarter we will be hosting Jenkins governance meeting about that and it's not that we will be updating this roadmap every quarter it will be just a regular review meeting contributors are welcome to submit roadmap items and by pull request at any moment Jenkins governance board will be reviewing them at any moment just based on pull request and after that if there is some if there is consensus we will be publishing them if there is no consensus that we will go through the common process like voting for the Jenkins governance meeting where any contributor and community member is welcome to vote it's not just governance board members and that's how we achieve always to the right decisions of the board if you disagree with them so yeah that's all about process and hopefully it will help our users so two main takeaways about the roadmap so public roadmap should help all community members to get more insights into the project how it evolves, what are the destinations and what are initiatives happening with it and community members include users, contributors, vendors adopters etc etc basically anybody who uses Jenkins or when you use Jenkins they can discover where the project goes and at the same time from the community standpoint public roadmap can help us to facilitate the changes in the project because when we publish this roadmap items actually we have a good chance of getting contributors interested in this project or we could find early adopters who would provide feedback to committers etc etc so public roadmap not only helps our users but it also helps us to keep the evolution of the project and if you're interested it's actually a great time to contribute so if you would like to contribute to Jenkins we have which documents various kinds of contributions including code documentation, design localizations whatever you're interested in in a project of Jenkins scale I believe we can find something which could be could fit your interests and for example if you want to write code there is a lot of links there are links to newcomer friendly issues there is sections for newcomers where you can find issues you could start from if you're interested or if you want to contribute on larger scale yes there is a lot of time documentation for various items hopefully later we will do these items to the roadmap as well but you can find this information here and it's not only about code everything is valuable to the community we will appreciate contributions to any area whether it's content management whether it's documentation documentation for open source projects is really important and contact marketing if you would like to contribute and also reviews any kind of feedback helping users all of that comes so if you're interested to contribute please do so and yeah that's it if you want to help with roadmap specifically then what we have on the cable so firstly submit your feedback so the google form I wish it in the beginning of the meetup is one of the ways to do that the roadmap discussion is in the main interest you can start your own one or to join existing threads and again we will appreciate any feedback if you work on a big project related to Jenkins let us know and we will be able to work with you in order to get published on the roadmap and if you're interested to contribute to other initiatives which are already published please do so because yeah that's how the project evolves on a particular note if you want to improve the roadmap, the layouts again it's totally possible so for example add more details or guidance to roadmap items or improve your layouts I am not a web UI developer so I guess the top of my javascript skills was actually implementing this filtering but if you see some improvements for example adding search or providing better categorization it would be appreciated so if you want to contribute to this service you're welcome to do so again this roadmap implementation is fully open source Oleg there have been some comments in the chat channel that page you had up would be great would you be okay if I ask you some questions based on that roadmap page so I think there were some questions that might be highlighted by you showing people the information that's behind some of these these fields that it's not just individual blocks here words there is really quite a bit of detail behind any one of them maybe you could highlight for us some of the ways that that can help people understand more about some particular aspect of the roadmap okay let's take a look so for example here one of items which is quite popular these days is a terminology terminology so there was a lot of interest and a lot of questions of how Jenkins project transport on the terminology it includes obsolete slave terminology which was replaced by agents in 2016 also master blacklist, whitelist and for that we have two roadmap items so here agent terminology cleanup is in progress terminology cleanup for masters and agents is near term and for example here for near term thing I just have a link to the main list so there is no specific project page but if you're interested you can find a lot of discussions and context here so if you are not a member of this main list you will actually start from first thread and you will be able to follow the discussion and updates for items in progress you provide more information for example agent terminology cleanup if you're interested in that you click on that and actually in this case you just get to apic and Jenkins Jira and on this epic you can find some description summary you can find guidance how to contribute including newcomer friendly issues so here you can just start contributing from one click it was already presented with documentation seek also there is a full list of scope links to particular items documentations and if you log into Jira you will also be able to discover a list of issues which are shared with this epic I deliberately don't log in because that's what you see what common users see and same for others so dependent on the implementation so for example here system read permission it leads us to Jenkins enhancement proposal because Jenkins enhancement proposal is the best documentation includes motivation and includes guidance and includes references to existing implementations and Jira issues so here you just go here and there are multiple examples but basically we provide a lot of freedom about what's getting cleaned as long as it provides enough details to users who are interested to contribute some items just lead to the website so for example user interface overhaul just goes to a page of the special interest group which again provides information so any approach can define our main idea that users and potential contributors can discover information more easily thank you so one other question was what technology did you use to develop the roadmap here it looks like it's based on a YAML file but this is JavaScript what's the presentation layer okay so it consists of two parts actually this roadmap is largely applied by Bloo-Ocean roadmap which you may have seen several years ago, Bloo-Ocean roadmap was fully implemented in JavaScript for this roadmap we actually went with another solution and this solution is actually called HAML so Jenkins the website uses documentation as code and basically everything is written as code so roadmap page it's listed here so you can see that it's something like 80 lines of code in total including text listed and it displays the entire page after that it uses JavaScript to just render filters it doesn't do anything else in JavaScript and also it uses CSS in order to render well basically that's it and yep maybe you may not like HAML but this is quite short and it's quite familiar to Jenkins contributors who contribute to the website so that's why I made decision to place it with such implementation so I can contribute by just making I could modify the submit a proposal to modify the roadmap by submitting a HAML file and then it is processed by this HAML definition and presented to users exactly so yeah it's quite straightforward to implement it and hopefully it's even more easier for users because a HAML file is quite straightforward and for example I use Visual Studio Code to develop HAML files and actually even without HAML schema without all components Visual Studio Code is able to parse the structure and make some assumptions on the schema and without any plugins etc you'll get some warnings if you're doing follow pattern in existing components and yeah you can basically if you want to patch something there is edit button so you can just patch it even from the web interface even without testing because you will be able to test it during the review elegant so there was one other question that just arrived oh it was related to the plugin manager entry specifically on the roadmap so it may be more detailed than you want to go into but there was an entry for plugin manager and I know that Jenkins 2.235.1 did significant improvements to plugin manager I don't recall so I'm not sure I'm seeing what the question was referencing yeah there are two parts so improving plugin manager UX remap yes you can see that actually the link points to the roadmap itself what it means so that there is no data provided and there is no data provided by me because it's me who added this roadmap item and I promise that I will fix it by the governor's meeting next week but there is description somewhere in my draft so I just didn't submit that and this is why we need feedback because these items might be missing and if you see something missing actually here you can just click report a problem and then basically report a defect in GitHub issues for this page so that you can address it so thank you now and I see so for instance on the user experience row there are things in different stages or states is this an evolutionary thing can you describe how things flow from the right hand side towards the left hand side what typically happens as they move along the path okay so between near-term transition happens when somebody declares intent to work on this initiative in short term whether we know that there is something planned and whether there are experiments but basically it's a declaration of intent then from near-term to current when the work really starts for example when the repository is first pull request created there are going to develop many of these discussions because they need then it's in progress or current it goes to preview when something is released and available to users various ways for example this roadmap is preview it's published is available you can just go to the page but there is a disclaimer that's why it's in preview for other projects for example for machine learning plugin for data science you can install it from the experimental update center and you can try it out on your instance by plan as YAML it's available in common GenX update center like incubating project so it really depends on what means preview but general sense that it's something available for evaluation and for feedback and then transition to release happens when the initiative is considered to be largely complete thank you thanks very much for that clarity so any other feedback comments just a reminder to everyone could you bring up the link to the feedback form I think I've been posting a different link and so it would be good if the feedback form link were visible we encourage people to please use that feedback form that's a great way to help us do a good job of tuning refining and improving these kind of webinars if you'd be willing to post that into the chat to if the chat is conveniently available so for chat I didn't provide a specific link oh ok no problem I would recommend using advocacy and outreach specialist group a meeting chat because this is the umbrella and I wish we were working on roadmap so if you have any questions please use this chat great ok so if there is no more questions I suggest we wait a second I just we just received two questions that's ok yeah so let's see oh ok so the question one question is hey I'd like to propose that we use a consistent terminology whether it's agent or otherwise and where would this contributor put that proposal and how is I think the question that is being asked ok so if you want to make a proposal there are two ways one way is to submit a pull request to this roadmap when you know where it would go at least approximately where you already have documentation etc and another option is to actually start from developer mailing list because usually roadmap items include some references and documentation and developer mailing list discussion would be a good reference without reference roadmap item wouldn't be published anyway so you can start from submitting a proposal in the developer mailing list for example I want to unify terminology or something like that and we can start discussion there after that once there is some progress once there is some consensus or advice how it could be completed we can edit on the roadmap it's not necessary to follow this process but it will be my recommendation how to start thank you and then one more question came in which was how and I'm going to rephrase the question a little bit how do you see the roadmap interacting with the Jenkins Jira system is the coupling strong what sorts of how do you see the two of them sitting next to each other or interacting there is no strict coupling firstly because depending on the project it's not only Jira being used sometimes a bit of issues are used secondly initiatives may break down to multiple deliverables or they might be largely aspirational so for example we have documentation migration to Jenkins IO so this initiative has documentation it has Jira ticket but at the same time we don't create all tasks for documentation creation there anyway so probably we'll change this link later instead of that we actually operate through pull request there is a hub project for that but generally it's community driven effort which is coordinated by documentation seek and on the link you can find information but yeah this might be different it doesn't have to be Jira if you want to use Jira my recommendation will be to actually use Apex because these initiatives are usually quite big it means that there are multiple deliverables in such case I would recommend using Apex we don't have support for other kinds of grouping in Jira so if you want to Apex or something like that we don't support Jenkins Jira but at least some grouping you can achieve thank you, thanks for that clarification so I take that that I have the flexibility to use Jira if it's good for me or to use pull requests or GitHub issues whichever fit well with the thing that I'm approaching the thing I'm trying to do that seems to conclude all the questions Oleg thanks very much for your presentation anything else that you'd like to provide a summary just thanks to everybody who participated in the call and we hope that this roadmap will be useful to you whether you just use Jenkins or contribute to the project and if you have any questions please reach out to me in the channels we listed in the presentation thanks very much