 Hello. Welcome to our first online Jenkins governance meeting. Today is April 22nd. Usually we do governance meetings using Jenkins meeting CCHAT. But today we have special agenda and we decided to try out using Zoom and video calls for that, similar to how we organize Jenkins special interest group meetings. Today we have several topics for the agenda. So it's a discussion of Jenkins roadmap. As we agreed at the previous governance meeting you would like to officially call it a first roadmap meeting and to discuss public roadmap for the Jenkins project. Then we have a topic about Google Season of Dogs application report to software in public interest. It's our umbrella organization at the moment and also a request to use Jenkins logo. So these are all topics we have on the list and if you have something else, please don't hesitate to add it into the bottom. Okay, let's start from Jenkins roadmap. I could do a quick introduction. So historically Jenkins project didn't have any specific roadmap or explicit plans how it would evolve. Firstly, it's because of how Jenkins community also organized their community driven project. So basically the project evolves in the directions where you have contributors. But in the recent years we started self-organizing in the community. So we introduced special interest groups, we introduced sub-projects. And now we actually do a lot of continuity effort in the project, even though it evolves in the same way. And one of the usual requests from Jenkins users, especially from big companies using Jenkins and vendors who build products on the top of Jenkins, was to have a kind of roadmap which would show where the community evolves, which areas we focus on where we facilitate contributions. So I think that it's a good time to discuss that. During the contributor summit in Brussels, we had around 20 contributors there and this topic was widely supported. So I went ahead and drafted the Jenkins and Huntsman proposal which would document that roadmap process. So it basically makes Jenkins roadmap firstly public. So everything is public, including the data, including process. Everyone is welcome to participate. Everything happens through open channels. And also it's community driven. So basically we do not force roadmap or whatever as let's say Jenkins governance board or governance meeting. But instead of that, we delegate that to entities within the projects, including plugin maintenance teams, special interest groups, sub-projects and actually whatever other entity we have within the community and the ecosystem. So this is the idea. There is a lot of documentation here for which we could go. And we also have a proof of concept which has been developed over the past weeks. So one month ago we had a governance meeting and there we approved publishing roadmap as a draft state. And I can show you how it looks like. So we already started reaching out to various entities and we collected a lot of feedback about items that we would like to focus. So if you take a look at this list, you can see that there is a lot of items already. All these items are quite big and we try to put big initiatives on the table because we want to facilitate contributions. We wanted these efforts to be major but still there is a lot of them and likely we will get more once this roadmap is socialized because we haven't done any promotion yet except developer maintenance. And we know that not all plugin maintainers really follow developer maintenance. But still we have quite a good number of items. So how this roadmap is organized at the moment? Again, everything is a subject to change and that's why we have this meeting and a few other meetings to collect feedback and to adjust. So instead of grouping them just by entity, let's say platform special interest group or by sign offering, you try to group it by use cases. So for example, before that we had job management but now that is pipeline ordering and development tools. So we developed pipelines and Jenkins tool and service integrations and then user experience and interface. So not exactly new features but also, you know that user experience is really important and it's one of the top items when we collect feedback about Jenkins. And if you go down, we start picking areas which are rather focusing Jenkins administrators. So we put end users first, then we have administrators. So here we have management and administration, including Jenkins configuration as code including other changes like remote and cobalt web sockets. So this is for administrators. Also specific section for cloud platforms. It's mostly Kubernetes, cloud providers and other things. Yeah, we know that cloud native special interest group in Jenkins is dormant. I have a long standing action item to cover that but still we have some items which we discussed before and which I put a tentatively on the roadmap and hopefully we will have more details. And for more classic platforms we have platform C and thanks to all platform C contributors we actually have a lot of items here. So it's Java support, Windows support, a lot of roadmap items for official Docker images for different platforms because there is a high interest to run Jenkins somewhere outside Linux Docker images. And thanks a lot to all contributors. And then we also have documentation though maybe we should move documentation high because it focuses users. Let's discuss it later. And after that we also have project internal stuff. So what it means first infrastructure. So infrastructure is a backbone of Jenkins organization and a lot of changes are visible. For example, recently we made a plugin site to a static website. Then just a few days ago, thanks to all of you, we also moved it to fastly CDN and now just loads immediately, which helps users and there is a lot of other infrastructure I can switch and mission critical to the project. We want to highlight them on the roadmap. Then plugin developer tools, again important for Jenkins developers, important for the future of our project. And also community marketing countries, including all programs we participate in, like Google summer off code community bridge. Also, we drive agent terminology cleanup within this specialist group. So we have metups recently with the main Docker images, but there is a lot of such topics, which is currently here, but maybe we should move it to up to documentation. And last but not least Jenkins governance. So for example, here the item for public road map. So this how it looks from user perspective. Again, it may look that it's already packed. This is a topic to discuss because we actually still have color dimension here which we didn't use or currently colors basically represent the status, but instead of that we could use them for additional grouping. And we also could basically discuss any other topic about the layout. So everything is subject to change. How is the back end implemented. So originally the roadmap was inspired by blow ocean road map, which was hosted on Jenkins IO website for a few years. Currently it's removed. The portion of roadmap was implemented using Jason data files and JavaScript, which was loaded with Jason files and showing them. But after a few iterations we actually switched to another approach. So this entire roadmap is basically implemented using more classic website technology. So it's mostly Hamel. And this Hamel just gets data from my YAML file, like in the Jenkins IO repository. So basically we have open data everyone can access this file and download this for whatever they're on processing needs. And this file has full contribution history. So everything presented on the roadmap is basically supplied by this file. Yeah, it's getting quite long call really. So this is what we have with the roadmap now. Again, any feedback is appreciated. And my plan for this roadmap is to actually get more items more feedback and maybe within one month or so we'll discuss publishing. It is a final version. Everyone is happy with what you've got by that moment. But it's not an immediate thing. I do not expect us to approve it as a final map today. That's for sure. And I don't think it's right there. I think I just add something on this roadmap. I think it's really great. Can you hear me. Yes. I think it's really great. And it's really important for the project. But something that I would maybe try to emphasize is, I think the different components should be updated by the different leaders. So I think it's really important that, for example, there are some point for the infrastructure and yeah, there's something that we should all do like be sure that it's always up to date because I don't think it should be the rule of you are wanting a person to be sure that all the different components are correct. Yeah. So we got speaking of that we have a job 14, which basically documents all the process. And there is also an item for roadmap items like maintenance. Firstly, we expect the initiative side meters or managers to keep the roadmap up to date. Again, if you want to update it, you just submit a pull request against the CML file, then it gets reviewed. We also got all automation. So when you submit a change, it automatically requests reviews from governance of both members and text it accordingly. But basically this roadmap can be updated at any moment, but by any contributor, assuming it gets approvals and reviews. You also have roadmap review meeting documented in the job. So that's a regular scrap. Let's see this monthly and the document or maybe even less often we should be using just for additional adjustments and maybe for defining future things, but not for the status updates. I don't know what you think about that but maybe it would be interesting to specify the dates next to each category. So for example, it's the documentation. I mean, if we know that the documentation category was updated over the last week, some months, it can already give a good sign. And on the other side, we see that, for example, the infrastructure was not updated for months. Maybe someone should either ping the person or maybe take some ownership there because So currently we can do that at the governance meeting. So just by doing scrap, we can take a look with the activities of which items seem to be stored. Of course, there is a major feature there like blame, not to blame somebody but to see one of the things we updated. So we can technically check it from the website. Yeah, if needed to be could split it to separate files, etc. But I thought that at least for initial implementation, it would be better to keep everything in a single place. Yeah, yeah, I also think I'm also in favor to have everything in one fight. Yeah, your, your desire there was to see which, which items in the roadmap might not have had recent activity but isn't isn't the measure of activity really not so much an entry in this file as it is project activity somewhere else that's behind this thing. This is if if for instance we don't update a particular row record in this file. I'm not sure we've gained as much but if we fail to make progress on some something that we thought was on the roadmap with its back end efforts that seems like a more interesting piece of data I'm not is or is that have I misunderstood your idea. My, my idea is not, not more like we did is more like, if you are a contributor, if you want to understand if something is working, we need a way to know if some help is needed that specific area. And so for example, if you see that they are, for example, a specific category is not updated anymore. Maybe it seems that the person who was working that was maybe working on something else or maybe delay whatever and maybe it would be interesting not not to blame that person but just to see a can I help you and see how we can move this, this category forward and maybe that's, yeah, it's more like it's, it's not really in the idea of blaming on someone but more to see if someone can help and how to identify that. It's open source, there is no blame. Life happens or happens. COVID-19 also happens like we know now. So it's hard to predict anyone, anything. Here, yeah, firstly, many roadmap items actually tied to sub projects or six. So for example, here if we talk about infrastructure, there is a weekly infrastructure meeting. And it would be great if infrastructure team just some time, let's say every month to take a look at the roadmap and do strap on their own. So that we don't need governance meeting for that. Obviously, it becomes a bit more complicated when it comes, let's say to feature areas, because what is the weakness of the current roadmap. It's quite shallow in terms of features being delivered to users. Because we have a lot of infrastructure thing, packaging thing, but features have been developed in plugins, features are less coordinated at the moment, especially user facing ones. So, once we facilitate it across plugin ecosystem as contributors to put something related to plugins. So for example, I put promotion support for pipeline jobs. If you're familiar with the story, it has been around for three years. It's not only in the future right now, it's also in my personal hall of shame. So, but yeah, there might be such items, but we are still interested to collect them. We are especially interested to collect ones which are in current and near term, because these ones are what is moving the project now. So, we understand the concern, but I think that calm Jeff can address it. Okay. So, any other feedback comments. If now I have a few questions to you. Should I put them in the dog. So first question to you is, do you think that the current categorization is fine, or do we need to rework it somehow. I think it's fine at this stage. Since it's something that's just kind of getting started. It might need to be updated in the future, but I think it's good for now. Me too. I second that is our third that as well. Thank you. So, yeah, we might more at a bit more content here. So, today I sent a message to the GSoc public mailing list about GSoc project ideas, because apparently the most of our project ideas we have on the table here. Do qualify as potential roadmap items and current stated that we have some project ideas on the road, but not all of them. So maybe I'll just do another bulk update. And there is a lot of teachers there, which we could highlight. Let's see. If you have something in mind, if you work on a particular plugin or an area which is not listed. Please let us know. Just commented the developer mailing list or submit a pull request so we can edit. Okay. And second question to you is about relations, because current file basically has one category and all initiatives are grouped by this category. There are already hit cases where this approach isn't the best one. So for example, that is pipeline auto and seek and they have pipeline documentation in that roadmap for the future. But at the same time, I should go to the documentation. Pretty much the same for Kubernetes documentation, because it should go to cloud native Cp probably. So my question is, whether we would like to support multiple categories or whether we would like to keep things simple. I personally would like to see just keep it simple, at least for the first this first iteration. I think more what I would want to see is this get out to the public faster. And I think the way it is now is really good. We can iterate. I'm more the other direction that I would like multiple categories, but I'm prone to agree with Markey that I'm not sure there's enough benefit to delay making this available in favor of adding this support for multiple categories. This is already intensely valuable and focusing on my efforts, helping me to think more clearly so multi category won't won't dramatically improve that. Okay, so in the worst case, we'll just make a break changing the YAML file. I mean, yeah, I didn't expect anyone to really consume this file anytime soon. Okay, thanks. Yeah, another thing is about coloring. So firstly, thanks a lot to spinning connection, which helped me to fix coloring there, because original things were terrible. And actually, it also has mobile, you know, so it's one of the only on a few pages which look good on the mobile now on the website. We need to have more. But the question about coloring game does anyone want to try something else with categorization. So for example, special color for documentation special color for features. So really, because this coloring looks great, but basically it's inherited from Blue Ocean. It doesn't create anything on its own. No additional value. Would it be nice to specify the SIG or is it just because it's right now the different categories. I'm just an idea, but maybe it would be nice to have to know which SIG is working on that specific components. So we know which meeting to attend. So right now it might be a bit tricky, because it really depends on which item you click. Some groups, they have expressed links. Well, you can see that there is a description. There are descriptions that are links for all items. Again, we are still cleaning it up because the original version was just a brain dump and after all the discussions we added more and more links. So theoretically many items already reference something where you can get contacts. Also, there is metadata like this one, which is currently not represented on the layout, but it's in my to do list. So there will be some links to these channels when you go here. The same user experience you will see additional pop up here, which will link to the channels, etc. So for items, again, it really depends. For example, here you will go to JIRA. For some items, let's say like documentation or platform C to be created, landing pages right on the SIG pages. So for example, here if you go to, let's say cloud native Java support, here you land on the platform SIG page. And on the platform SIG page here you can find a contact. But yeah, this experience is also not very good. And some items just reference JEPs. So here, for example, if you click, you'll go to the Jenkins enhancement proposal and all our format for Jenkins enhancement proposals presumes that there is discussions to metadata. But again, your knowledge may vary depending on the item you click. If you want to have unified experience for that, I totally support that. And I open to suggestions. So just to be sure I'm understanding. So the idea there is, I'm a new arrival contributor and I would like to help with modernize mirror infrastructure or with user guide improvements. And so the idea that Olivier was proposing was some way of when I click on that thing of my interest, that it takes me to a way to reach out to others, which, which I think Oleg you were saying the chat channels is an example of how to reach others about that topic. Yeah, basically that was what I was suggesting. So I mean, an easy way because the Jenkins community is quite big, you have a lot of different initiatives. And it's not always easy to know if you're supposed to go on guitar, if you're supposed to go on RSE or whatever. And so I was just suggesting that if you want to participate, I'll just click here and then you have all the information. Yeah, to know how you can help basically or how can have more information about that specific components. Yeah, one thing we could do actually to support the drop down for components. So for example, it's something to the left. You click on that and you will get a list of potential items like contacts, project description, whatever else we add. And we can actually traverse these things. So you don't have to put everything to the YAML file, for example, how we do it for JSOC project ideas. Just to show an example, because for project ideas, again, we hit the same problem, each project idea right now the project has its own communication channels. And some communication channels on guitar, some on FC, some on Slack. And here if you take a look, there are links. So for example, here you can see that there is mainly increased which points to platform seat. There is chat which points to guitar for git plugin and there is meetings, which links to JSOC. So how it's handled actually there is some metadata injected in the project idea. And we just traverse this metadata with support inheritance. So for example, here you can see that the guitar is defined here explicitly, but the rest of the channels that actually come from platform seat definition. And regarding meetings, I guess there is a bug somewhere, because it should point to platform seat meetings. But yeah, so theoretically I could implement something like that. So we support seek or project reference. And then a website builder just rec restores all the links. Bonus points for new befriended issues, but it's maybe a big ask. Okay, so if it helps, I'll try to implement it. Yeah, I mean, if you have some time for that, I think would be useful. I think we have some time to finish roadmap. You'll see for me it's one of the most important items. Okay. So anything else about the roadmap. This is my first meeting and so I'm just trying to clarify some some issues about this, not issues but questions about this roadmap. There is current release categories and my understanding right now that if there is no background in the current it is not a button. And if there is like green in the release, for instance, if there is green background, it is a button which is clickable. I understand. Is it correct? No, it's not correct. Actually, all of that buttons. Not actually buttons is just whatever different combination is a lot of CSS around that. Yeah, you can see that there are some metadata. So for example, pop up description. Again, it comes from the YAML file. There is also hyperlink. But the behavior really depends on which date is supplied through YAML. So coloring is just status. So release the green in progress, a yellow, et cetera, et cetera. It's just status coloring. It doesn't represent any conflict in the moment. Thank you. So Vlad, did that address your question? Yes, I was a little bit confused about released and current categories because I thought that well, released, it means it's current, but I guess it is like all these categories define, I guess, the progress, how we're moving from left to right. Yeah, but yeah, but release mean it's done done where so it's more like you read from right to left. Yeah, so status is also documented in YAML file. So basically release that initiative is completed. There might be still some follow up items to be completed, but largely it's delivered. For example, like inside it's largely delivered. But yeah, you know that there are things to be improved. Even major things like CDN, but in principle, this feature was available to users and it was really working well. And same for others. But yeah, these statuses again, they're suggesting Jenkins enhancement proposal. So formally at the current state, they are not slated in stone. And if anyone wants to change them, please do that. You can just suggest a change in the job, or you can submit a pull request against the job is your suggested changes. And we can adjust. So everything right now can be changed. That's why we keep this job is in the draft state. And yeah, thanks a lot to Alex, because he's now officially a BDFL delegate in this job. So Alex will be doing final approval for that. Sounds good. Okay. So yeah, basically this is a summary of status. We are using the horizons. Again, because common feedback about road maps is whether you commit on delivery dates. Now in the community, we don't commit on delivery dates and we don't really commit on delivery at all. Because that's how open source projects work. But instead of that, we set up some horizons which are also a bit blogger sometimes. I still, I still remind people that maps of roads do not generally have dates on them. They just don't. It's a subject for long holy wars. Yes. Especially for particular people, but whatever. Okay, any other questions comments or should we move on. Sounds good. Thanks all for your feedback. And again, anything you have in mind, please comment in the mailing list so that we can incorporate these suggestions. And I noted the action items. Thanks for your feedback, Olivia. Okay, so we have something like 20 minutes left, but a lot of topics should be more simple. So Google season of docs. Mark, would you like to summarize it? I would yeah so Google season of docs is a project sponsored by Google where they encourage professional technical writers experienced skilled technical writers who may not have any experience in an open source community to assist the open source community by becoming contributors to open source projects. This year their plan is that they will host 50 slots for technical writers to assist open source projects in designated selected themes and projects for those open source examples. Well, the Jenkins project or the free BSD foundation or others like it have specific conceptual things that they would like to have a multi month effort with a skilled professional working on their project now these professional technical writers may not have experience with get or with open source workflows and so there's growth for the writer and growth for the the open source project. Did that did that give a good enough description there Oleg or are there things that you'd like to add. Definitely. So thanks a lot. One thing to mention that Google season of docs is generally a long time program being compared to GSOC. Because yeah for me and so GSOC never ends, but for students for mentors, it's several months. In the case of GSOC it's much longer time frame. So there are long projects which are up to nine months that are short projects but again, the full cycle is more than six months. And actually, it's quite good for the community because well Jenkins project we definitely would benefit from better documentation. We facilitated a lot of contributors to documentation over past years, thanks to and past months, thanks to plug in documentation integration project Jenkins IO enhancement. So what I reported in 2019 report we had more than sort of almost 200 contributors to documentation. But still we could use a lot of dedicated effort. And for us it's good opportunity. And yeah, I'm just screen change page, you can see that there is a lot of different open source organizations participating and they have a lot of success for GSOC. So, personally, I think that it would be great to participate. But we have a problem, because we need all that means we need mentors to run a project. But again, as Mark said that there are only 50 months. So it means that we need one mentorship mentoring team. We probably need one or admin. So it's not like a JSOC way scale. And we invite dozens of contributors to participate. But still it needs some commitments to get this project right now. And this is why I put it on the roadmap because also on the governance meeting because there is a thread. But in this threat right now, we don't have consensus. We don't have or admin. There are people who are interested to be mentors potentially, but there are some potential project ideas. And we need to decide whether we want to push to the surface or not. And we need to decide timely because the deadline is May 4. And we will we will discuss further in the doc sig meeting this Friday, but but you're right. I don't feel like I've personally got the capacity to act as an org admin. I'm open to be persuaded otherwise, but with Google Summer of Code and other activities, I'm feeling pretty loaded. It's quite similar to me. I'm ready to dedicate some time in order to create landing page. So for example, what we have in JSOC project. Yeah, JSOC. So we have basically JSOC documentation site. Within JSOC, where we have our own guidance, our own landing information for mentors for students. Also, we have a list of project ideas which are presented. I can create lightweight version of that for Google Season of Docs under the umbrella of Docs SIG. But regarding maintaining the program, I'm not ready to do it alone. So if there is somebody who is willing to participate as an org admin and who would be interested to mentor particular documentation projects, for example, Jenkins and Kubernetes or just the work of solution pages. Like we discussed a couple of days ago that our solution pages are really bad. We could improve them a lot, but we need people working on that. So if there is somebody who is interested to work on these projects, who is also a native speaker or at least a much English speaker than me, because all JSOC documentation should be in English. It's a strong decision by JSOC that it's only about English, it's not about localization. So if there are contributors who are interested to consider it, I'm ready to help this getting to the framework on the website. I would be interested to participate, but I'm not a native speaker. So question to you, Vlad. Would you be interested to participate as a mentor or as a participant? I would say for the beginning I would be interested to participate as a participant, because I'm not sure what are the responsibilities of the mentor. Which is already quite encouraging. The correct terminology for JSOC is mentor, right? Yeah, I think that's correct. For me, it's part-time or... Your audio is still breaking up, Sladen, sorry. Yeah, Sladen, I was interested to participate. So anyone else? So I could spend, Oleg, I think part-time as a mentor. The challenge is I don't think I can be an org admin. I just, I don't have the capacity for that. For instance, I'm reviewing Vlad's recent contribution and I'm delighted. It's marvelous, it's wonderful what he's done. That kind of role works great for me. Org admin feels more than I can take on. Okay, yeah. I'll see whether I could facilitate another part-time org admin, because I guess we still need two, four JSOC. And if I find someone, we could kick it off. What's the current deadline for this? May 4, so we've got about two weeks. Okay. But it's two weeks to get the application submitted or have a website in place. So last year we applied, but basically we applied this Google Doc link. And since JSOC assets only 50 projects, and last year there were more than 200 applications, obviously with Google Doc, we were not accepted. So yeah, we definitely need something better if we even want to try. Yeah, is the audio better now? Yes. Much. I switched on to my mobile. So yeah, so as I was saying, I would be interested to participate as a participant. But if the team doesn't have any, I mean, if it's difficult for, I mean, as an organization to get mentors, I would be interested in participating as a mentor as well. So I don't know. I mean, it's a bit of a confusion. But yeah, I would be willing to contribute in any, I mean, if there are enough mentors, I could participate. Are there aren't enough mentors and I would have to participate as a mentor. Yeah. Thanks a lot for suggestion. One thing we need, we need to clarify is about potential conflicts with JSOC. Because they apply to JSOC as a student. Yeah. So there's a lot of hidden stones there. Suggest we discussed it after May 4th. Yeah, no, no, no issues. Yeah. We still have to help you on the landing page. So let me know if you need any help. Yeah. Cheers. Okay. Thank you. Okay. So yeah, I'll take a look. But you can put me down for, you can put me down for a part-time or admin. Okay. I can, I can help you with that. Okay. Then we actually have a team. So if everyone is fine, I'm willing to give it a try. Yeah. So the, the, just to be sure that the scoping is clear in this one, it's, we accept that at most we would take on one mentee. We wouldn't want more than that. And we would frame that around a project to improve the documentation in some valuable way. And that's why we have Jenkins roadmap because we already have prioritized projects in different areas, which are related to documentation. And we use, can use this outreach programs to facilitate these projects. Pretty much like we do with JSO project ideas, though, there was no roadmap at that point, but all project ideas we had, they're really available to the community and to the Jenkins future. So we can naturally convert some of these documentation projects, et cetera to project ideas. And that's it. In terms of roadmap then, for instance, there are some topics that I think are smaller. For instance, then Jenkins on Kubernetes on this picture is for me a massive, but highly valuable. Likewise administrator guide, but, but I think there could be smaller things, the solution page rework, which it would be okay for that to be on the roadmap. Oleg, are you envisioning that that would be roadmap, roadmap worthy or is that too small? I would envision that because if you talk about solution pages, I believe that it's not really that small effort. So right now you have, so there is solutions page. It looks awesome. Again, thanks to spinning because there was a full request a couple of days ago, but if you click inside, right, there's almost no content and it's varying quality. Yes. Yes. So I think we need to rework everything. We also need to put more solution pages because yeah, there are some items, but these items can be their group. Strangely, because yeah, the technology ones, which are really important to have, but also use case ones like, for example, continuous delivery. But there is also only continuous delivery there that we do with it, how we group that, maybe how we add additional tools because yeah, the bucket server, thanks to contributors, they added that you could have the same for GitHub, for example, or we could have the same, let's say, for static analysis tools for security scanning tools and so on. So this effort may become a topic for multiple Jesus. Great. Okay. So it is a good fit. Thank you. Yep. So if you want to add it to the roadmap just to do that. Okay. I think it would be available. Okay. So next topic, which is quite small is about another report to SPI. So just to share some context, there was a request from SPI to share several paragraphs of what Jenkins did in the previous years. We have already created the draft and submitted it for review. So my question to governance board members and all other contributors is whether you're fine with the current wording. Basically, it's a short summary of what we have in the new year blog post which we published. So it just tries to condense it to a smaller format. Yep. If everyone is fine, I would just ship it to SPI so that they can include that in there in our report. Yes. Good. Good for me. I like it. Yeah. Plus one for me. It's within Chris. Okay. So. Yeah. If anybody has some point. I will wait till tomorrow. Let's say. Morning. U.S. time zone. And if not, I will, if there is no feedback, I will send me the current version. Morning U.S. time zone, but which, which side of the U.S. 2 p.m. UTC. Yeah. And actually submitted by whom. So you can just say Jenkins project. Jenkins contributors, whatever. Usually. So there is an example of this PR report. They put. Usually names. But they would rather prefer. To keep a project entity instead. But yeah, as others prefer, I can do whatever. For me, the Jenkins governance board would be a great. A great choice. But if you would prefer individual. Your name is also honorable. You, you created the vast majority of that content. That'd be great. Yeah, I agree. So Jenkins board to me. Oh, something else like advocacy. I think you should say your name. And then put your title as part of the Jenkins board. Yeah. Okay. We have no preference. Yep. Looks good. Okay. Thank you. So again, 2 p.m. last minute feedback and then I will ship it. Okay. And the image usage request. So we have five minutes left, right? Because zoom icons close the time. The clock on my windows panel. So that's why it takes so long. Okay. So there is a request from Chris or actually he forwarded the request from somebody else because Chris is a press contact. So he received an email and he followed it. And they want to actually request permission to use Jenkins logger in whatever configuration panel. So usually which we don't care too much. So what do we have? Okay. So we have a bunch of logos. Actually, we have more than that. And we still encourage contributors to submit the artwork. But it takes a while. But what is interesting part about it that all logos listed here, they actually listed the under creative commons license. Three to zero. So technically all these logos can be freely reused, modified, etc. But there is a caveat today because all these logos should have a reference. Should include distribution to the Jenkins project. According to the license, but historically, we didn't care about that at all. And to be honest, I don't see a particular reason to care, especially for Jenkins logo, which is pretty recognizable without any additional attributions. So Yeah, I'm a plus one. Yeah, I think we should just approve it. I mean, it says here that it can be used under creative comments. So, yeah, as long as they follow the license, I think it's fine. Plus one for me. Plus one as well. And not minding plus one. I thought that the answer there was I like the answer from Daniel Beck that said that. As far as he could, my interpretation of his answer was, they can use it without even asking for motion. This is not a trademark usage, which which really requires formal governance approval right this is something different than using the trademark. I think we just approve that just in case, but yeah, I think whatever. And other topics. So I have to, I have to drop by a hard stop for another meeting. Okay. Yeah, thanks for participation market. Yeah. Other next meeting, I guess it will happen in two weeks, as usual. I had one quick thing. Oh, that's right. So I just wanted to kudos to the release team. Having released the first, get it on the public recording. The first release into the new release environment. So a couple of them actually so that was that's pretty awesome just want to give kudos to those guys stated awesome. And I can't wait for the next one. Actually, it's a good thing to do. So at the seek meetings and project meetings, we start from news section. So maybe we should try to start doing it also the governance meetings. So just to highlight such major achievements. Okay, but yeah, really congrats to all involved and especially to all of you because it was something like two years so far. It required a lot of different changes across the project and it's great. It's fine. I think that ticket is even older. I mean the epic. I think I should just close the epic for now once the weekly for that. I think they keep it. Yeah, it's very old to get. Yep. Yes, when I joined the project in 2012, it was already actively discussed at the time. I'm not sure whether we had a ticket, but yeah. Anyway, so how do we do the next meeting like that in zoom or like before in IRC. Zoom works pretty well, I think. I think IRC works pretty well too. So I guess it's maybe if there are specific topics that we would do well with an actual voice or video communication. Maybe we go towards zoom if there are things that are just like a needing approvals. Maybe that's an IRC meeting. I don't know. I'm good either way. This meeting, this this meeting in IRC would have been a complete disaster. Zoom for these topics was crucial. I like Alex's idea. If agenda motivates it, we should use zoom. I'd also be fine if we use zoom all the time. I have no problem with zoom. I like this. The interaction. Personally, personally, I like to have this kind of meeting versus having those in IRC because I find those. I mean, I find this kind of meeting. I mean, I'm less distracted at least. So it's easier to just stay focused on the meeting and be sure that's okay. I would just follow what the discussion were on IRC. It's easy to work on something else. But yeah, that's a personal opinion. So my proposal, we wait for agenda items. So everyone is welcome to submit agenda items and maybe several days before the meeting, we decide whether we do zoom or IRC. And yeah, we've got a new zoom account. So we will be working on grant permissions to board members, seek leaders, etc. So they can host zoom meetings on their own like they used to do with Hangouts on Air a couple of years ago. So we will restore this experience for everyone. Okay. Okay. Thanks so thanks a lot for your time. Thanks everyone. Appreciate it. Bye. Thank you. Bye.