 Well, thanks a lot for joining our online meetup. Today, we will be talking about the online UIX Hackfest. And you can already see a first type on my slide, because it's not an only dot kickoff. It's just a common kickoff session. OK. Yeah, today, we will do a quick introduction to the Hackfest. We will discuss how to contribute, how to record the contributions. And then I will have quick introductions to project ideas and tracks by their leaders. And after that, we will have plenty of time for Q&A. If you're interested to find these slides, everything is open, everything is public. And I'm going to just post it in our Gitter channel. So you can find the slides here. OK. So this is our Gitter chat. It's open 24 slash 7. And if you have any questions, please feel free to reach out to them. And later, we will talk about more communication channels. OK. We have several presenters on the call. And I guess every presenter will introduce themselves during the presentation. So I will just do a quick introduction to the meetup. So we use Jenkins online meetup platform. And we will be using it for many training sessions during this online Hackfest. So main idea is to have presentations by contributors, for contributors. So we won't be targeting slides. Maybe many sessions won't have slides at all. Instead of that, we focus on live demos, on show and tell, on just sharing experiences. And everybody is welcome to contribute. So if you have any questions, please feel free to ask. You can raise hand. You can grant your voice permissions if needed. And you can use Konechat for any questions. So if you want to ask questions during the presentation, in Zoom, there is Kone feature. And please use that. Also, we will be organizing additional office hours during the Hackfest. Again, we will talk about them later. And for offline communication, we have Gitter chat and MediTips. So that's our communication channels. And let's proceed with the main part of the presentation. So as you probably know, we will have a Jenkins UI UX Hackfest this week. So actually, we plan to have a kickoff session today at 1 PM UTC and start after that. But we forgot to put time zones now in invitations. So officially, the Hackfest started yesterday. And we also had a number of contributions. So well, it's good news. So just to explain some context of this Hackfest, if you're an active Jenkins user, you may have different experiences with it. But one of the top feedback we get from Jenkins users that its user experience could be improved and specifically user interface documentation. And after some discussions, we started talking about UI UX Hackfest. First time it was discussed at the Contributor Summit in Brussels. And here we are. So we are doing this event. And we specifically focus on improving user interfaces, user documentation, and also on sharing the word about Jenkins. So any success stories and knowledge transfers are welcome during this event. And we invite all contributors to participate in the event of the event. We will be distributing some Schwag and prizes. And we will talk how to get them later. So yeah, this is a quick introduction. One common question is what Hackfest means. Because when we reference that, people start to mention Hackathon. So just all developers get together for one day, two days. Basically, Hack can sleep. So that's not what we are doing. Actually, we are doing quite opposite thing. We know that everybody has commitments. And we invite everyone to just spend as much time as you can or want. So if you can spend a few hours, it's fine. If you can spend a whole week, yeah, it's awesome. But it's quite unlikely. So whatever time you dedicate is fine. And we mostly focus on learning, sharing experiences, and having some fun. So we will be organizing a number of training sessions. We can do a talk KT during the presentation, sorry, during the event. And of course, we welcome any kind of contributions. The main goal, which we would suggest is to focus on your own user experience issues. So if you use Jenkins, again, you may have hit some issues. During the registration, we asked people to provide top three things that they would like to change in Jenkins. And we've got quite a number of responses there. Thanks, everyone. We will be processing these responses and publishing them later. But we definitely know that there are some UX issues we could address. Another point about this hack is that it's a newcomer-friendly. So you don't have to be an experienced Jenkins developer or you don't have to be an experienced developer at all. There are topics which can be handled by everyone. And if you want to just start contributing to Jenkins, it's a good opportunity to do that. So I would like to thank the entire org team, which made this event possible. So there was a lot of groundwork to make it happen. Thanks to Mark, to Tracy, to Tim, Mark, and Alisa, who helped with different aspects of the preparation. And also thanks to all special interest group members who helped to review the initial stories, project ideas, and who provided a lot of feedback during the event. Also thanks to our sponsors, because, yeah, we will be distributing cash work. We also use this online meta platform for presenting the event. And thanks to Continuous Delivery Foundation and CloudBus for making it possible. OK, so right now there is no questions, right? No. OK, so we can continue. I will briefly talk about participating to this event. And then, again, we will talk about topics. So how to get started? If you registered to the hack first, you have already received an email which summarizes the common steps. We also have it on the Jenkins website. And I will just quickly show it to you. So first thing, if you haven't registered yet, please feel free to register. You can do it at any moment during the hackfest. So for example, if you decide to participate on Friday, it's still possible just to do that. And this is actually a quite short form. It will have been short, I guess. But still, you can see my responses there. Oh, no. OK, so basically we ask you to provide your email address. We will need it for delivery of Shuaq because we need to contact you somehow. If you're not comfortable with it, you can just register in the Gitter channel. So just say I want to contribute and we will track that. Then specify your GitHub ID, which we need for information, your display name. And also we ask how much time you would like to spend, what area would you like to work on? Yeah, these three things you would like to improve. Yeah, please share your feedback. And after that, also some details. So once you register, the next step is to actually join our Gitter channel. Again, jgdci slash hackfest. Everything will be discussed here at least for the moment. Maybe later some teams will be using different channels. But for any kind of Q&A, please join this channel. So then, well, you're already participating in the kickoff session. So no need to spend time on this step. But we will publish the recording and make it available. And after that, you just need to take a look at the project ideas and to think about what you would like to work on. We'll get to that later. And after that, that's it. You can start contributing. So it's quite straightforward. And let's talk about how to contribute. On the Jenkins project, we actually invest a lot of time in maintaining the contributor guidelines. We have a page for participating in the review. And you can find guidelines for different flavors of contribution on this page. And many items are actually related to user experience. So for example, coding, documentation, but also design work, helping people, helping with liquidization. All of that can be a part of user experience stories. So for example, if you want to work on a code, you can go here. You can find some guidelines. You can find the allocations of our repositories. You can also find some guidelines for newcomers, including preferences to newcomer ratios, and useful links which describe how to contribute. And basically, similar information is available on all pages. So please refer to this website. During this hackfest, you can actually contribute to any area which is related to user experience. We have three tracks, but still you can do something else. Regarding development, if you know Java, if you know JavaScript, there is plenty of opportunities. If you want to write something, you can go. We also have projects like, for example, Jenkins Kubernetes separator or CLI in Go. You can work on that. And basically, you can find other ventures. For example, we have components in C-sharp, in C++, and a lot of development tooling is in various scripting languages. If you want to contribute to documentation, the most of our documentation is in documentation as quoted at the moment. So it's a GitHub flavor mug done or a ski dog. We also invite you to do user experience testing. It may be either testing of documentation, for example, installation guidelines, tutorials, and new documentation pages, or new features we are working on. All the reviews are also appreciated, as well as creating new content, like blog posts, videos, et cetera. And last but not least, you can just help others. For example, answering questions, pointing them to the communication channels. It also counts the contribution. So we do not really have to quote it during this event. You can do other types, and later we'll talk how to do that. We have three tracks. One is focused on user interface, improving look and feel, improving accessibility. We also have a major project for read-only configuration browsing, UI themes, some advanced projects for pipeline visualization. Later we will talk about that in details. Also, there is user documentation, which is mostly related to Jenkins IO or to the plugin documentation. And we have spread the word, which is a track focused on promoting Jenkins, sharing experiences, et cetera. What it was mentioning, that for example, if you want to quote something, yeah, obviously user interface, there is a lot of things you could do. But user documentation may also involve some coding surprisingly, because to our website, yeah, documentation is code, but it also has an engine. For example, it includes a lot of JavaScript for rendering and CSS files. Also, we have a plugin site, which is basically written in JavaScript, React, and other components. And again, code contributions will be welcome. Same for user interface, the new features we are working on may also include documentation. So tracks, just a lot of focuses. It doesn't specify what exactly you could do there. Every contribution is welcome. We're also well aware that user experience is not just user interface or not even just user interface documentation. There's a lot of other flavors of user experience. During this hack fest, yes, you can work on them. You can report these contributions. They will count towards the goal, but yeah, we just do not put them on the official list because we want them to be focused. But if you want to work on the developer tools, if you want to work, for example, to create new artwork, to create design concepts, for Jenkins, et cetera, it also contributes to the project goals and we would appreciate such kind of contributions. Okay, I said contributions maybe 100 times already. So let's talk about how to do that. So if you do code contributions is quite straightforward. You just pull a quest to proper locations. They will be reviewed. It's less straightforward. For example, if you want to publish an article or a video, if you do it on your website, it's also possible. And in order to support that, we created a GitHub repository which we will be using to report the issues. So for example, yeah, this is our website and actually just a lot of automation for the bots. And if you want to report your contribution, you just go to issues, click a new issue there and then you get the issue templates for various kinds of contributions. So for example, your UX enhancements, bug fixes, documentation, et cetera, et cetera. So in the morning, I presented an example of where I just did it myself. But for example, today we could try something else. We know that Olivia, one of Jenkins infrastructure officer and the one of active Jenkins contributor, he helped a lot with redirects for Jenkins infrastructure. So just a second, let me open that. Jenkins, Central, Jenkins, Central. So if you see, there has been a lot of pull requests recently related to redirects for plugin documentation. Olivia helped to review all of them and I think we should recognize it. So let's try to do that. So it's related to documentation and let's say thanks to the direct reviews. So something like that. So I'm just checking the login. So it's actually all work and yeah. Here, so all templates are more similar. We just ask everyone to summarize your contribution and then put some links and screenshots if applicable so that we can build reports later. So for example, here, as with effects. So I put some text, I submit a decision and voila, we get this ticket. So then what we can do, now somebody from work admins will process this contribution and we just use all contributors for that. So here, I'll put Olivia and it's for documentation and reviews. Fortunately, I don't have to worry about what exactly I write because it has a lot of magic under the hood to recognize text and yeah. Okay, so now we got pull request. We measure this pull request. So there is a lot of, okay. I'll merge that and after that, we have Olivia on the list. Done. And if you want to submit your contribution, basically you do the same so that we can trace this ticket and just create reports later. Obviously for core contributions, we can collect your pull request later, but we would appreciate if you follow the same approach so that we can collect the data. So Oleg, one of the things, if you could take us to submit a new issue, one of the things that was there, I thought was ingenious that you had pointed out earlier that someone who works for a corporation where they may not allow them to even contribute content, that UX testing row there, you can test, you can contribute by helping us test, even if you can't submit a single pull request. This issue report could be your way of saying, I'm testing this. So I thought that was absolutely ingenious. No matter the IP restrictions in your organization, you can still help this project. Yeah, right. And another part of this topic, which we again didn't mention that we don't have, we don't require a contributor license agreements from contributors. So yeah, we have the UCLA, but this UCLA applies only to contributors who get special permissions. For example, in Jenkins infrastructure or documentation, US contributor doesn't have to do anything. If you're allowed to submit code, you can submit code. If you're not allowed to submit code, then even in the such case, you can still do something. Okay. Any other questions before we move on? Okay, then I'll continue. So another question is about communication channels. So yeah, we have this GitterChat. If you're not comfortable with the charts, we also have mailing lists. So there are three mailing lists for user experience, documentation, advocacy and outreach. So you should write one mailing list. And for general questions, there is also developer mailing list. We will also organizing office hours so that it's just a common meeting in Google Hangout. In which you can join and basically discuss any questions or just chat with people about anything related to Jenkins. We will have daily sessions at 8 a.m. UTC. And we also have sessions at 2 p.m. UTC. So you are welcome to join any of these sessions if you're interested. And if needed, teams can create their own sessions on demand. If you want to navigate through these sessions, we have an event calendar specifically created for this event. I will click on the calendar link. So yeah, this is a browsing mode for me. So we just place everything in UTC right now because this is how my calendar is configured. But for you, it will likely display your preferred time zones or if needed, you can just change them. So you can see all the incoming sessions here. We will be still announcing more sessions to Thursday and Friday. And everyone is welcome to join and present something if you're interested. But yeah, this is the source of truth for the events. And we will try to keep it up to date. We experienced some issues with Google Hangout links because it's really difficult to manage them after the recent changes. But yeah, the most of the meetings actually happen in Zoom except office hours, which really happen in Google Hangout. Okay. Another further of meetings is online meetups. As we said, there will be a number of training sessions for different topics, mostly for developers and contributors, but there will be some user focused sessions. And if you want to find all these sessions, you just can go to our Jenkins online meetup platform. And here you can find a list of upcoming events. You have to go here because of this list currently doesn't fit the default layout of five meetings. But yeah, this is our sessions that we already have published and you can see that you can just RSVP and then join this session. You can add them to the calendar calendar. After that, you just welcome to participate. Again, if you want to host your own session, for example, you want to talk about user experience of particular component or you want to share some best practices, how to improve user interfaces or documentation, please let us know in the chat and we will help you to do that. Please let us know in the chat and we will help you to get this session hosted. So we have a number of, or that means who can help with it. During the event, please also be aware of code of conduct. We have one Jenkins. This code of conduct is based on contributor covenant. The main idea of that is just be nice. So we want to make this event a great experience for everyone. So yeah, there will be a participants of different level of experience, but please help them and please be content during the communications. And if anything happens, please let our organizers know, but hopefully it will be fine. So we have never really used the code of conduct during online events. And yeah, let's keep doing it that way. Yeah, thanks. Everyone, yeah, it was an introduction to the heart first. Before we proceed, are there any questions in the chat or anywhere? I had answered one online, Oleg, about the assignment process for JIRA issues that I think is covered. Other than that, no questions in the Q and A. Okay, so yeah, if you want to ask any question, just put it to Cornelio or drop it to the Gitter Chat or whatever is more convenient and we will discuss it there. Okay, let's proceed with project introductions then. So the first item on the list is user interface. And we have Jeremy on the call. So Jeremy, would you like to present it? Sure, we'll move to the next slide. So, well, first of all, I should introduce myself. Of course, I'm Jeremy Hartley. I'm a product manager working at CloudBees. I work on open source Jenkins and also on some CloudBees internal stuff. So, first of all, I'd like to say a lot of new work is being done on the new Jenkins UI. So we started work on what we call the new Jenkins UI at the end of 2019. Goals very briefly is to learn from Blue Ocean. So we abandoned that project a while ago. Learn from this really by being as inclusive of existing plugins as possible. So not just creating new interface that didn't support the rest of Jenkins but to really work with it. And we're starting the process of the new Jenkins UI by overhauling the look and feel of the existing UI. Next slide, please. So the work we've done so far during the first part of 2020, which some of you may have seen already is we started off working on a new edit bar, the breadcrumbs. We followed up by working on the footer, we're working on new buttons, we're working on new typography, we're working on a new navigation sidebar, we're working on new iconography. Next slide, please. And really, I just wanna make calls to action if people beyond this hack first are really serious about helping out with the Jenkins UI, please come and join us at the Jenkins User Experience Special Interest Group. We started this late last year, we meet every two weeks at 3 p.m. UTC. About 10 people join each week, not always the same people, but about 10 people, we're looking for more contributors that wanna work on the project. Do you wanna find out more? Just head over to jenkins.io6 and then you'll find a new accent there. So that was briefly just a kickoff and a small call to action. I mean, we're busy with the new UI, but we really need your help, whether that's today, this week, or during the rest of the year. Any contributions, welcome. Thank you for the introduction. I suggest we take a look at the project ideas. So if you participate in the morning session, we just went through the list and I suggest doing something like that. So we have quite a number of projects published for UI UX. So starting from the bottom, one of the items is what Jeremy described, just improving look and feel. And there is a number of related to newcomer friendly issues you could work on. We are using the jitter queries for almost everything. So, for example, here you can see that there is a number of issues, for example, related to Jenkins Core, to warrings and Gplugging, et cetera. If you want to find more issues, for example, this one, I just newcomer friend list and let's remove this label and we will see all the issues and you'll get something like 300. Obviously, some of them may be invalid, some may need some processing, but for this to be quite confident that they're relevant and you could work on them. If you want to start working on something, for example, you get an issue to folder authorization plugin, then one button doesn't work and I guess a beauty is already working on that because I've seen that there might be just a new UI for the plugin, but let's take, let's find something which is not assigned at the moment. Okay. I guess it's just default assign. Okay. So, Jenkins Core has no default assign. So, for example, if I want to work on this issue, yeah, you would need to have access to Jenkins Jira and after that you can just assign the issue to yourself, for example, well, I'm not really going to work on that at least today, but I can assign it, I can start progress and I can start working on that and then submit a pull request and everybody who visits this issue will be able to see that it's actually acquired. So, this is how you can modify that. For the components, yeah, sometimes you use Jenkins Jira, sometimes you use GitHub issues. With GitHub issues, our recommendation is to just put a command because you have to have right permissions in order to assign an issue. So, yeah, in our case, we just recommend putting a command and then it will be handled. Okay, so this look and feel updates. Another flavor of that is actually accessibility. There is a number of projects and the idea is to actually make Jenkins usable for everyone and it doesn't only include groups of users with disabilities or slow network connections, but also, for example, mobile devices. If you have tried using Jenkins on mobile device, you probably know what I'm talking about and there is a number of projects which could help. One of the major projects which we have ongoing is changing Jenkins integration UI from tables to leaves. So, this is an ongoing project and there is a staged pull request for that and we would appreciate contributions, user experience testing and also adapting plugins. Tim, would you like to briefly speak about this project? Sure, so since the beginning, the Jenkins layout has been done using tables which back when it was originally built was how layout was done for a long time since then that has not been the standard and it's made modernizing UI quite difficult. So, Josh Soef about a year ago, no more than a year ago now, started working on trying to modernize that. I think there's been one or two previous attempts as well but this is the one that's gotten the closest. So, what we have now, she won the first, oh, you got it. So, they're all the stop on pull request. Yeah. So, we have a fully functional conversion from tables to divs and it's possible to do that because most of the controls are all inside of Jenkins Core. So, plugins use either jelly or groovy usually and don't write much HTML directly. So, because of that, we've been able to change all the central controls and we've made a few UI improvements as part of this as well. So, you see that element that only just had opened, they just closed. You see there's now a visual indication when something is associated to a parent. So, you see the source code management is a child of modern SCM and then Git is a child of source code management. So, it helps you associate the elements to the UI. It's kind of works in the current implementation because they're all moved over to the side but some of them, it doesn't work so well on others. Some other improvements is that mobile works really well on this without any effort for it. So, this wasn't done at all for mobile but it just works out of the box for a lot of functionality. So, that's what the configure page looks like and just in general, most of the elements can move to the top and the fields on the bottom. So, what we're mostly looking for is any testing. Well, the biggest issue we have right now is we just wanna get a good amount of testing done on it so that we're confident in shipping it. Any fixes or improvements in other plugins to be useful. We have made some changes to a few plugins and the plugins that are likely to break are the ones that write the UI themselves directly. If they include the table tag in their plugin somewhere, it probably won't work. And we have bridging codes and there's examples and there's a how-to guide in the documentation for how to do that which I'll just show you at the moment. And the others is JavaScript that is tied to the current implementation of the UI and that needs to be able to handle both approaches and there's not a lot of JavaScript in Jenkins and most of it isn't quite central plugins. So in general, it's not such an issue but those are some of the most likely cases to break. I think we've probably tested most of the default plugins. So in Jenkins, there's a default plugin concept or recommended plugin concept. When you first started up and you just get the default plugins, but there's probably some other popular plugins that we've missed and that's where we'd like some help. And so any kind of testing will be much appreciated. Yeah, and for you back in general. Yeah. Okay. There are also some other issues related to user experience and accessibility which are fairly minor and somebody is welcome to start working on them. For example, we can see that Roman has already started working on one of them. So feel free to take a look and if you hit more issues, please report them so that we can also process them during the hard test or later, because it's a larger project for user experience seek and there is a lot of service to be handled. So the next big project for us is system rate permission. So why it's important. There is an ongoing adoption of Jenkins configuration as code. It doesn't mean only JCask plugin and maybe also, for example, Jenkins operator for Kubernetes, Helm charts or just all style configuration management tools and Groovy hooks. All of that basically allows you to manage Jenkins as code and there is interest also make a better user interface for that. So for example, that admins can browse configurations or you can browse agent configurations, access diagnostics and formation without having opportunity to modify something and then intentionally break something. So this is one of Ranger iris. Thanks to team for driving Kajap 2.4 which is a foundation for system rate permission circuit system. So team, would you like to introduce this project as well? Sure, no, I've unmuted myself. Yep, so there is a blog post which we should ship right after this meeting which is an announcement which basically takes us through what it is. So if you're interested in that, take a look at the blog post. Basic introduction is, so there's two sides of it. Most of what I've worked on is the system read but there's also as part of this read only Jenkins as a whole came in. So previously there was some older commissions, extended read for jobs and extended read for agents. Extended read for jobs was there but didn't change the UI at all and it was confusing to users as they could try and save it and it wouldn't do anything. Extended read for agents didn't actually do anything. So as part of this, what we've started from system read but extended to read only Jenkins as a whole. So it's basically about allowing your users to consume Jenkins from all the levels. So they can see if their build goes wrong, the user has all the information available to them. They can see at the system level, they can see the logs, they can also contribute to your Jenkins as well via configuration as code. They can see what plugins are installed. They can see the current configuration and they can also see who's allowed to do what. So they can know who to contact. They can see who the admin of the instances, all that information that's just not available out of the box. So turning this on allows you to basically have a full read experience. Quite similar to a lot of other CI systems as well. That's basically a short introduction. So we have a blog post which will go more detail into it and what's currently there and what's supported. And there is a how to guide as well for how to convert a plugin or a core component to support it. That should be, yep, that link coming there. So there's the three different permissions for system, agent, and jobs. There's how to adapt it. And I've tried to put guidance for Jelly and Groovy as it's quite similar, but if you're not used to them, it's slightly different. That took me a bit of time to figure out Groovy especially because there's a lot less Groovy examples which makes it a bit more complex. So please follow these guidelines. And again, any kind of experience and feedback would be nice. So the difference is that this feature basically lands in the weekly release. I'm not sure whether it beats out or not but it will definitely happen in a few hours. So you will be just able to take the recent weekly version and start using that for tables to diffs. You will have to use Jenkins built from the pull request but still it's quite straightforward to set it up and get running. Well, last thing on the system read is there's a epic which has a number of open issues in there. So there's a couple of bugs and the number of enhancement requests. So two things we're looking for is more ideas for what should be covered and what's currently missing and someone to pick these up and implement them. A lot of them should be quite straightforward to do. Right, so I'm just opening or we fixed everything here but we will probably report more. And here there are some tasks which you could take for particular components. Okay, thanks team. So other topic, we'll be finishing the UX part soon. So other topic is about themes. So many people use different themes in Jenkins and they can actually improve user experience quite a lot. And we invite contributors to contribute to improving existing teams to make them aligned with the recent changes delivered in Jenkins. There is also a high demand for example in dark theme for Jenkins. So everybody is welcome to work on this topic. Personally, I'm planning to spend at least some time on that tomorrow. On Wednesday, we have a training session for themes. So if you're interested, you can take existing ones, create new ones and also there is an ongoing project, the idea about creating a micro-set for themes because right now what we have is just a simple theme plugin documentation which lists some themes here. But obviously we could do much better like in GitHub by your side with some links to existing themes with information about which Jenkins versions supported with some screenshots, et cetera. So that themes can be easily accessible by users. Okay, so I guess that's all about themes. We also have an advanced project for pipeline visualization. As Jeremy said, low ocean was a part of story for pipeline visualization. It's still a part of the story but there is demand to improve something around that. And if anybody is interested to contribute, you're welcome. So there are multiple directions which it could take including creating new browser and computing capability for example as a plugin or maybe doing something else. Unfortunately we do have new camera friendly tickets there but if you would like to work on this area and improve this, let us know. We will try to help as much as we can. So we also have some stories for credentials, UI improvement. It's a story submitted by team because credentials management in Jenkins is quite complicated and not always trivial. So if you would like to improve something can be said, please do so and pretty much for almost every other plugin. If you see something uncomfortable to you, if you submit a pull request, we will do our best to help it get landed. Last but not least, the developer tools. In order to help Jenkins developers to create better plugins, we need tools. So for example, we have a plugin for UI samples. Which includes examples of common themes. So, well, this plugin doesn't even have read me. So definitely there is a lot of opportunities for improvement. And if you want to create a new samples, for example, today we'll be doing a presentation about how to improve user interface of plugins with various JavaScript libraries. So if you would like to create some examples based on this presentation, you can just put them here. Thank you. Other examples would be welcome. Also, there is an idea about improving IntelliJ IDE plugin for Stepler. So Stepler is a framework we use in Jenkins for REST API mapping and for object mapping for request handling. And a lot of development happens using Stepler plugin. For example, well, this plugin also includes Jelly Framework and the Guru Framework support, which we use for many Jenkins UIs. And if you want to create new archetypes for JavaScript-based plugins, so basically boilerplate templates, everyone can copy and create their own plugins based on that. You're welcome to do that. So this is just a list of stories we have on the table. Again, this list is not complete. So if you want to work on something else, please do so. And yeah, this is just a guideline and a set of project ideas. Okay, any comments before we move on to documentation? Okay, so yeah, then I think we could spend some time on the documentation. So Mark, would you like to speak about that? Sure, I'm Mark Wait. I'm the Jenkins documentation officer. Trying to coordinate and share with people how they can help us improve the Jenkins documentation. Next slide, Oleg. So we've got several different aspects of improving the documentation. One is that the user and administrator documentation has many areas that you can improve just by reviewing and renewing it to be sure that it reflects the current behaviors and the current look and feel of Jenkins. You could also, if you're a JavaScript coder or interested in looking at how documentation lays out, you can improve the navigation. Help us have tables of contents that are better suited to users who need to find what they're looking for. Likewise, if you're a JavaScript interested, you can consider improving the look and feel. Also, maybe you're a mobile user and you want to look to see how could we help this documentation be more readily used for people on mobile. All available. Next slide. Now, in addition, we've got an awful lot of very useful content that over the course of the many years of Jenkins development has collected in the Jenkins Wiki. What we're doing now is we've got a project as part of this hackfest and ongoing afterwards that wants to convert content from the Jenkins Wiki into Jenkins.io. That conversion process lets us use the knowledge that's been captured in those Wiki pages, refine and improve it, and place it into the official destination on Jenkins.io. The Wiki exporter tool that's hyperlinked here will give you assistance in making that conversion from Wiki format into ASCII Doc. Here it is. What you do is into the top field, you paste in the URL of a Wiki page. Change the convert output format to ASCII Doc, and then press the convert button, and it does the conversion for you and gives you the rudimentary ASCII Doc ready to go. So that Wiki exporter will help you as you help us make this transition. In addition, if you wonder, oh, which page should I work on? Well, we've placed into GitHub issues the top 50 most accessed Wiki pages as issues. So you can choose one of these Wiki migration issues and start working on that page knowing that it is in the top 50 pages accessed from the Wiki in the last roughly 90 days. So GitHub issues, easy to navigate, easy for you to find. When you find one that you say, I'd like to work on this, you just open that issue and place a comment in it which says, I'm working on this. That's enough. We just rely on each other to read the comments, to not pick up something someone else is working on. So that the Wiki migration project is a good help. Let's go on to the next slide. That was great, Oleg. In addition, we've got user experience improvements that we're looking for in places like initial installation or in the experience as you work through a tutorial. Both of those are places where you could help users by assuring that the installation works the way it's described and you can run Jenkins on lots of different places in lots of different ways. We also have tutorials linked here included both the guided tour and a number of language specific tutorials that we want to be sure still are working correctly and well-behaved. Each one of them takes you through a series of steps. We have things from how you might use it with Maven, how you might create a multi-branch project, how you could do parallel testing, all sorts of different ways to work with either Python or Node or you choose it. We've got lots of interesting tutorials that could use validation and safety checks that they're still working well. Yeah. I would also like to add that Jenkins is an automation server, so such use cases are really important because if you develop something with Jenkins, most likely you want to automate something. So real world experience for different tools is essential for users. It could help a lot and it could save them a lot of time. So if you're willing to write new tutorials for tools you use, it's welcome. And also we have solution pages, which basically also described various use cases from user side. For example, if you work with GitHub or if you develop in Java or if you develop in C++, you can find something here. And here you can see two of your issues, one that we could have much more solution pages. So they would definitely benefit from something specific and if you have technology you use is just submit a pull request. If you want to talk about practices like continuous integration, devops, continuous deployment, whatever, you can also write specific pages for that. And for existing pages, they also would benefit from some improvement. So for example, if you go to Java you can see that layouts could be improved. Also the content is probably a bit obsolete. So if you want to improve pages, it would be much appreciated because this is something Jenkins users would like to see when they look for their use cases. And it's impressive the number of times we receive requests to the Jenkins IO site asking for a C tutorial. If you're a C or a C++ programmer, don't be shy at offering a tutorial that how you might use Jenkins to do C and C++ based development. It's a very common need, lots of people would love to have it. Yeah, and right now we have a very extensive tutorial here. So definitely something we could improve. Yeah, these pages were created for Jenkins Studio Zero and we could do a lot more here. So if you look for more issues related to the documentation, we actually have a number of queries. So for example, what Mark presented on Jenkins IO and maybe we also have queries about plugin documentation. So should we speak about plugins then? Yes, yes. I think that was next on the list. Right, so plug as part of the effort, special thanks to Gavin Mogan. The plugin site has been revamped and is significantly better. That change has brought us the ability to do plugins and host their documentation in GitHub as code instead of hosting it on the Wiki page. So what you're seeing right now that Oleg is showing is plugin documentation extracted straight from GitHub and placed into the plugin site. It makes life much easier for plugin maintainers when they can maintain their documentation at the same time that they're maintaining their code. They maintain it in a simple markup file here and it gets automatically published. I just wanted to say that we need your help with migrating these pages but I'm pretty sure that is exactly what Mark was going to say. The migration process is in progress, right? There are over 1,500 plugins in Jenkins and with available and that many plugins, there are a lot that need their documentation migrated. Here is the list that you can see of plugins and their various migration states. So as you scroll further down, we eventually reach a point, oh, here are some plugins, the nice white rows that have not been migrated yet, they're to do. If you'd like to work on one, you just click that plugin and you can see how to approach that from this exporter page and it will offer a prototype converted wiki page to you, ready to go and you can use this to submit a poll request. Yeah, we also have the table guidelines, how to process that referenced from the hack test side because yeah, this is just a skeleton. Usually the documentation pages require some copy editing. When we migrate documentation, we encourage contributors to actually improve the documentation as they go because there might be obsolete terminology, there might be just obsolete screenshots, we still see screenshots, which use Hudson interface from 2007 or so. So all of that could be improved and when you do the migration, we will appreciate such contributions. All right, and as a personal note, the process of converting documentation from wiki to GitHub for a plugin I maintain made all the difference in the quality of that documentation. So it's good that when we do this transformation, we apply brainpower to it. Now, tomorrow, Oleg's going to take us through a live demonstration of how to convert a plugin documentation and yes, it will be the Chuck Norris plugin. We look forward to Chuck Norris being converted from wiki to GitHub based documentation. Yeah, that's my plan. And we also have a session by Mark, which talks about the JNPCIO documentation. So again, if you go to the list of the events, so we have a session today with Uli, then we have a session today with Alisa and then a number of sessions tomorrow, including two documentation sessions and the system with permission by team. So please feel free to join any of these sessions if you're interested in documentation and we will do a deep dive there. And Oleg, I think that was it for my topics. Yeah, that's reminder that the sites are there, the links are there. We'd love to have your help. Okay, yeah, that's right. So any questions before we move on? Okay, then really a short introduction to the third track, spread the word. So having content, having documentation is not enough. You also need to make this documentation, this information visible. And it's always good to share the stories and to celebrate the achievements in the project. And we really rely on Jenkins users and contributors. We invite you to share these stories. Several weeks ago, we have launched the Jenkins's the Way program. So this program basically invites you to share your user story or case study. We start publishing case studies from different users here. So for example, there is a story by T-Mobile, et cetera. You can go inside and read the details. And if you have an interesting story to share about Jenkins, please do so. You can just submit a story on this website. And we will appreciate that. So later today, at least we'll be talking about Jenkins's the Way program in details. But you can find all the details here in the announcement blog post. And you can also write stories, for example, for Jenkins blog. You can go to Jenkins website and here you can find our blog. We have a lot of announcements here, but if you submit a case study or submit any worst story about Jenkins, you will be happy to review that and help to get published. Same you can do it on external resources. For example, if you use medium.com, you can do that during the hard test. And you can also just post about your experience and new features which happened during this hard test or which has been recently released. And if you want to record a video and publish it, please also do so. It solves the health of Jenkins users. So this is basically the track. Anything which helps to promote Jenkins, to make it more visible and to help users to find proper solutions to their automation cases. Please feel free to publish that and also report that because many of these stories do not require GitHub. And this is where this guidelines from your UX hard press come in place because this is the way how you can report them so we can process them, discover them and repost them when possible. I continue to be impressed at the number of people and the number of ways that Jenkins is used that I think are fascinating. I talked just last week with somebody who's doing audio engineering with Jenkins. I happen to have a family member who works on robotics with Jenkins. And we would love to hear your story about how you're using Jenkins. Don't forget that the way you're creating software is interesting novel and probably distinct from the way others are doing it, Jenkins supporting it. Thanks very much for being willing. Thank you. And actually it was last slide. So if you have any questions, we can discuss them now. We have something like 27 minutes reserved for this session. And we have one hour till Uli Beginski's presentation about improving user experience for Jenkins plugins. So any questions, any comments? Does anyone want to talk about other stories? There is a question. So there is a question regarding C-sharp development. So from Philippe, what am I going to do there? Just grant Philippe permission to speak. So Philippe, now you should be able to ask your question or maybe in the chat. Hello, can you hear me? Yes, we can. I was doing almost a year ago. I was doing a dotnet development using the dotnet call. It was part of a master's degree thesis. And for that moment, I was considering to use either KITLAB CI or Jenkins. I inclined more to Jenkins. So all of the automation was done with Jenkins. But I found a couple of issues regarding some local plugins that were not working properly. And it was actually quite hard to dive deeper in the testing use cases because we had some issues with the unit testing frameworks. Yeah, we were assessing whether should we use as a test or as a unit or any unit to test our applications. But we encountered an MS test plugin. The MS test plugin actually worked with some other plugins like FlexUnit and the unit, but it was only optimized for MS tests. So in terms of performance, we concluded that MS test was the slowest, one of the three frameworks that we tested. But when we tested it from Jenkins, it was actually the fastest. The question is, I haven't been developing this particular project anymore, but I wanted to know if making a next unit plugin or an end unit plugin or making some actual, it's making more plugins to be available for the community to use to develop with .NET is actually something that you consider or if you don't incline that much towards .NET development. Yeah, so to answer this question, if somebody wants to create a plugin for .NET, it will be more than welcome. We have quite a number of plugins, as you may see, we still have some problems with targeting and discovery, because for example, MS test plugin doesn't appear there, it should. And we welcome contributions. But for .NET, we have historically one issue. If you want to write a plugin for .NET, you should know .NET and you should know Java because Jenkins plugins are basically created around Java, JVM ecosystem and JVM languages. You can run a write a plugin in Kotlin, but generally you need something specific to Java. So historically Jenkins has a much stronger support for JVM stake than for .NET, but personally I've been using for Jenkins for quite a while. And if you see a specific plugin which is missing, yeah, I think it would be great to at least report the issues for that. For example, if you're interested to contribute, you could start from creating solution of page specifically for .NET, because again, we are missing that. So you could accumulate the existing plugins and the report graphs which are missing and probably we could facilitate some contributions to this area because yeah, .NET is quite popular use case and .NET is the smallest open source these days. So yeah, distributions are welcome. Okay, thank you, thank you. In some sense it's not even just open source, it's also a multi-platform, right? I mean, there are .NET frameworks from Miguel Acasa and others that give me more than just one platform. Yes, yes, .NET is quite for the runs on Linux and Windows, it works perfectly on either one of them. That's why we chose to actually develop some of the applications in that language. Yeah, so if you want to contribute to .NET part, actually we have some .NET in Jenkins, we have Windows services and all the Windows services are managed by Windows Service Rapper. So Windows Service Rapper is a component which is written in a C-sharp. Actually it includes distributions for .NET and also .NET Core with native executables. So we should do not require the .NET panel on the instance. Right now we have a number of projects there which actually relate to user experience. For example, verification of the configurations and supporting YAML configurations because right now it's on the XML. So if you're interested to contribute to this area, you're also welcome to do that. So documenting use cases for .NET C-sharp, it's covering cases which I'm missing. Just contributing some code is also welcome. Okay, thank you. Okay, any other comments or questions? I don't see any, I'm just going to shake for a while. So any additional comments from the panelists? Oleg, are there ways that contributors? So for instance, just this week we've got new arrivals on the user experience in the weekly build. Are there any things we need to forewarn? People who are interested in testing, hey, try this in the new weekly build. So they just be looking at the change log. What are there's any specific guidance we should offer them on particularly Jenkins 2.238? Okay, so let me share my screen again. So if you want to discover new features, the easiest way is to go to the change log. Your change log doesn't include the release which is happening right now. But here, if you scroll down, you can see some enhancements there. So red ones are bugs, blue ones are enhancements and improvements, for example, the style, the health button, a number of permissions, a number of improvements for system rate, et cetera. So you can find such areas in the change log. This is one of the ways to discover issues. Another way is to actually go to the Jenkins roadmap. So it's a work-in-progress roadmap where we publish key ongoing stories. And for example, there are stories which are likely interested to help as participants. For example, pipeline is YAML. There is working prototype and integrated project for that. There is also projects for Git performance, HAPA authentication for look and feel improvements, a lot of projects for administration and also some other projects like Jenkins Kubernetes separator, Jenkins file runner, various Docker images. So if you want to try something, you can take a look at this column. I guess all of these projects would benefit from some user experience testing and feedback and all of these projects are available for trying out at least in some sense. For recent releases, you can also refer to the Jenkins blog. Major stories we encourage contributors to publish their stories. So for example, here, Windows Docker images, general availability. So we have just released it. If you want to try it out, if you are using Windows in Kubernetes or in Docker, it's definitely something you could try out. Rename and key images, also GitHub HAPA authentication support, which has been released recently. So team was working on that. And now we have a GSOC student working on follow-up projects like for example, integration with GitHub checks API, then for example credentials for Azure, et cetera. So if you just go through this list, you can discover a lot of recent stories. And if you see missing features, you can actually write about them. Because in Jenkins, we have around 40 to 50 releases every day in terms of Jenkins core plugins and other components. And most likely in these releases, you can find something interesting to you. Okay, does it answer your question, Mark? It did, thank you. Thanks very much. Okay, any other comments or suggestions? So we have 45 minutes before the next session. I would like to thank everyone who participated in this call and who's watching the recording. Have a great week and we are looking forward to work with you in the Jenkins project. If you are a newcomer contributor or if you experienced contributor, we hope that this event will be a great experience for you. If you have any questions after the event, again, please ask in the Gitter Chat and we will be able to continue the discussions there. So thanks everyone. And I guess I will stop the video recording. Okay, if I find the button finally.