the SID display week with RealDME and who are you? Hi, I'm Eric. I work for RealDME in the Oxford office. We are working on technology for individual devices that be licensed to device manufacturers. Everyone knows the problem that if you are using video conferencing the other person seems to be looking downwards. So we have developed technology to adjust the gaze to make you look upwards while you can still look at the screen. So the idea is that the other person can't see whether you're paying attention or not because you have to see your own screen. So what we're doing is we are following the other person's face and then if you look now at my eyes I can adjust my eyes to move upwards and downwards at the click of the button and this runs in the background just on the just basically on the image from a standard RGB camera so we don't need any kind of special hardware. So yeah it will be hard to see here and we have it on different platforms as you can see here. Here you can actually see the different different positions the landmarks that we get and now show you the correction if you look in there you can see your own eyes being adjusted. Nice. Life and in real time so this is ready for deployment. It runs at a high frame rate on very standard camera. So you have a very good what's called recognition of face and eyes and everything? Yeah we are definitely competitive with the industry standard here and actually it's a very recent algorithm that we have developed with our computer vision folks in in Oxford and it tracks up to four people in real time on a standard iPhone or iPhone 6 or 7. So this could be used as as it is you can use this for live streaming on YouTube. Yes you can. When you are always wanting you want to look at yourself but you don't want to look like you're looking down or something. Exactly yes you can use it for live streaming if you want but our licensing model is actually to go to the hardware manufacturer because we need to know the position of the camera with respect to the center of the screen so then we can optimize the performance of this of this approach. Is this something you can calibrate if you have a webcam outside? Yes you can calibrate it yourself. So you can you can use it with any camera and it just calibrates? Yes yes so it works with any camera any resolution in real time on multiple heads so we also target video conferencing providers who are then able to provide the same kind of performance in their end user devices. But you can if the eyes are closed you can't open them. No this is impossible so one of the secrets of our approach why we somehow bridge the uncanny valley is that we are not inventing any pixel lines. We are just shifting pixels around and we shift the pixels around according to the user's eye shape so we're not moving pixels as in some other kind of gimmicky applications but we know exactly what kind of eye shape the user has from a huge database that we use for training and then use this to look up the adjustment we have to do. How many different eye shapes are there in the world? Oh well you have you know of course children and elderly people have different eyes than middle-aged people female male and then you have all different kind of ethnicities so there are quite a few our database is quite large and I think this is probably also a big part of our IP that we have collected this data set. If you have strange eyes it can still work? Yes yes it can so we have no kind of symmetry constraints so we have some people who basically have you know a laggy eye also and it still works because and glasses no problem. Glasses is not a problem either yeah. You fixed that? Yeah we fixed it. Right cool so this is the company that's the main product or would you have lots of other things? We have other things so we also work in the display field so we have a booth in the main main floor that presents display technologies a steerable backlight in particular that allows you to send images into eyes individually so that you have a glasses free 3d screen or that you have a privacy display that allows you to see the content just when you're there and nobody else behind you.


song that Megan made you. Yeah, some bad. Yeah. You're the one rapping on it.  Well, I don't know if that's an appropriate thing to say on camera. Well, I don't think that's... I don't think it is any. How old is any? Because you know a lot.   Well, when I got Benny, I just assumed he was over 15 because he looks it. You know, like 15? Oh, like when they're eight, they saw that baby face. Yeah, I know baby face.  See? Your wings are pretty, Vinnie. So, take it out and let's take it off. He's always in your dreams. Always. All the time. You said that there's like two, two birds that are always in your dreams? He's always in your dreams. You? Yeah, did you? You know, I look us in here and you know that today I saw a birdie on YouTube that wants to be your girlfriend. Dior. Dior. Dior wants to be your girlfriend. What do I have to say about that? Yeah, but Dior wants to meet you and Dior was fancy looking, fancy. And you know what? Gangsters need a side chick. Yeah. New age stuff. What do you think? He always does this when we talk about girls. You know? You want to talk about gangster stuff?


Now, let's talk about how we actually improve some data use. There is an old adage in information systems that has always been true, and that's garbage in garbage out. If we are making it very difficult or burdensome to capture data, then it's almost assured that the types of analytics that we are going to be able to get out of the system are poor quality or very limited. Here you see two examples. The first one on the back is showing how health facilities are being forced to record virtually all zeros. The act of having to put in dozens or hundreds of zeros into the system every month is very burdensome. It puts a lot of effort and strain on health facilities. You can imagine a scenario where it becomes very easy to accidentally put in a one in front of one of these zeros. And so what was meant to be zero becomes 10, or what was meant to be zero becomes 100. It becomes very easy to make mistakes. Why are we forcing everyone to enter zeros? It needs to be reduced. We need to reduce the burden as much as possible for data entry. The other one is registries. And you see an example here from Zimbabwe where health facility workers are required to update many registries on a regular basis, on a monthly basis, or even a continuous daily basis. This reporting burden is, again, detrimental to data use. We force all of these potential data users to spend all of their time and energy to actually just putting data in. We need to streamline data entry as much as possible. We also need to standardize the tools and reports that we're using. We need to make sure that new partners are not coming in and introducing new tools all the time. We need to make sure that programs are aligning and harmonizing with each other. We need to make the tools as simple and as efficient to use. We also need to make sure that our electronic data capture forms are supporting either matching or supporting the workflow of our paper tools. Many countries are still using paper to capture the data initially and then transforming that or transferring that to the electronic data sets. And it's important that those electronic data sets look as similar and follow the same workflows as the paper forms so that you're more easily able to transcribe the data from one to another. The biggest reason for data quality problems is transcription errors where a person sees a number on a paper form and then puts in a different number on the digital form. It's very, very easy to do this and one of the ways to minimize that is to make sure that our paper tools look very similar to our digital or electronic tools and that our electronic tools are supporting a workflow that eases data entry in them. A next key point for improving data use is data is only as good as how it is presented. Here we see a picture of a pie chart that is more of art than it is useful analytics. It's very easy in any kind of analytics tool, including DHS to to make very poor analytics. Arguably, it may be easier to make poor quality analytics than it is to make good quality useful analytics. Here's a few best practices to help improve or ease the development of good quality analytics. The first one is keep it very simple. If you produce complex analytics, it's almost a guarantee that they won't be used. When we say keep it simple, we mean simple bar charts, column charts, line graphs, single value charts, very, very simple pie charts. Not this, what you see here is an example, the opposite of this. Sometimes we think of the six-year-old rule. That means that if you can explain it to a six-year-old, then it's a good chart to put onto a dashboard. And it's not to say that we should treat everyone like children. Of course, there are many professionals, many experts out there using these. But the point is that people are pressed for time. People have limited capacity at any given moment. And we have to make these analytics as simple to understand as we possibly can. Not because they have the capacity of a six-year-old, but because they are being stretched very thin, especially in the health sector. And we need to appreciate that the simpler we make it, the easier it is for them to use it. The next one is that we need to target our audience. Again, we appreciate that there are different data needs at different levels by different users. We need to make sure that our analytics that we're making are speaking specifically to those users. And we're not just passing down analytics in an assumption that those analytics that are used at higher levels are also useful at lower levels. The third point here is we need to be careful about choosing the appropriate chart type. We see this to be a big issue and we've done research that shows that it's very common for users to choose inappropriate chart types. What exactly do I mean by this? Well, here in this example, you see a pie chart that is completely unusable. But if this was converted to, say, a bar chart or column chart, where each one of these health facilities was represented as a bar instead of represented as a slice of the pie, then we would be able to much more easily understand that those facilities that have higher RDT positive rates and those that have lower RDT positive rates. We could even sort them and we can see the lowest ones or the highest ones. We also see a very common issue with the use of line charts. A line chart is meant to show a trend over time. It is not meant to show a trend across multiple localities or or units. We see it very often used for the latter, showing a trend across multiple org units. Of course, there is no trend across multiple org units. That's not an accurate comparison. So line charts should be used as trend analysis over time. The next one is appropriate indicator pairing. You need to show data on a dashboard or any kind of analytics output that is comparable to each other. It's typically not good practice to put in random indicators or maybe indicators that are loosely associated with one another in the same analytics, the same bar chart or graph or pivot table. It becomes confusing. We need to make sure that we are putting in analytics that are consistent and depending on one another. They are related. They are in the same health program. They have related outcomes and impact. And then finally, we need to use easily interpretable legends. We see this as a big problem. In DHS2, you have the flexibility to define your own legends. You can make any kind of color range color path that you would like for your legend. That flexibility sometimes brings in problems. For example, having a legend that doesn't make any logical sense. There's no progression. One easy rule of thumb is green is good. Red is bad. The progression of red to green means something is improving. Going from green to red means something is getting worse. So when in doubt, just use a simple red to green legend. The final point here that's in the box at the bottom is countries have to establish routine data analysis and presentation, refresher trainings for HMI staff. The use of analytics is something that has to be nurtured. It has to be supported. You have to continuously train users on new analytics tools, refresh them on using the existing tools. There needs to be a way at which users at all levels are receiving some kind of refreshing training. And you're able to monitor the progress and uptake of those trainings. In DHS2, there are applications that can be used to walk users through a training for their own analytics. Those applications can be found on the DHS2 app hub. For example, a country can build in a training and then launch that training down to users at all levels that takes those users, walks them through their own dashboards, walks them through how to build a chart and data visualizer. The trainings can be tailored to specific end users, specific programs, and specific levels within the hierarchy. Now training has to be done physically, but it's important that whether you're doing trainings physically or remotely, that you are able to monitor progress and make sure that users are actually completing those trainings in a satisfactory way. Now focusing a little bit on dashboards, just a few quick tips on how to improve dashboards. The first one starting on the left is when a user logs into DHS2, it's good practice, as we see in this example here from Sierra Leone, to make a landing dashboard. So as soon as they log in, this is the first dashboard they see. You can see that Sierra Leone has titled it notice. And on this dashboard, they have some simple instructions and information for all users. So how to improve your experience or use DHS2, some contacts, some guides to different standard operating procedures or user documentation, some links to some analytics, some standard charts or standard reports. Just different useful things for health staff. So again, the first landing place is maybe not necessarily showing any data. It's giving some support to users to actually use DHS2 to use the analytics presented here, to give them some guidance on how to troubleshoot issues, contact details. The second on the right side of the screen is providing a description for each dashboard item or analytic on the dashboard. This is very easy to do in DHS2. And on the dashboard, as we see here in the example of this bar chart, and on that bar chart, there is a description. And this description defines how the dashboard item should be used, so how this chart should be used, how it should be interpreted, and any specific actions to be taken based upon the data that is presented. So you can build your standard operating procedures directly into the dashboard. And we find this to be a really good practice. People forget over time exactly what they're supposed to do when it comes to standard operating procedures. So give them a constant reminder. When they look at this chart, they're going to very easily see that, oh, this is what I need to do with this data. If the data is looking like this, I do this. If the data is looking like this other way, then I need to do this other thing. One additional point is that when we're making dashboards, we need to make sure that they include, again, our standard operating procedures and our targets. So we may have a standard operating procedure for an individual chart, like we saw in the previous example, or we could have a standard operating procedure for how to use the entire dashboard. And this is what we see in this example here on the screen. We see this is an immunization dashboard. And right there in the middle of the dashboard, we are providing the EPI focal point standard operating procedure. So this is just a very simple example. Obviously, these can be much more complex. But the point is that the user of this dashboard, who is an EPI focal point, is able to quickly see this is how I use this dashboard. Now, also on this dashboard, we see, especially in this column chart, targets. And it is extremely important to include targets and legends that clearly indicate how things should be performing. Good or bad, on target, off target, above target for all of our analytics. Don't make people guess if they're doing well or not. Clearly indicate to them. And you can see here in this chart where we have a very clear target line, and we also have a max acceptable value. The max acceptable value there is to indicate any issues with data quality. So anything that's above that max acceptable value is probably a data quality problem that has to be investigated. We also see a little bit of a scorecard in this screenshot. So again, red, bad, green, good. And you can see a very clear progression from red to green illustrated on this scorecard. We also see a little bit of a picture of a map here as well. And you can see a very simple legend to understand there as well, starting from a wider shade into a darker shade. The last point to make here is that in DHS2, you have the ability to send messages to users, and you can also automate messages to be sent to users. Messages can be sent internally using the DHS2 messages application, or it can also be pushed to people's emails or phone numbers via SMS. Here we see on this dashboard, on the top left corner of the dashboard, the automated messages that are coming from DHS2. Here we see just one message, but these messages could be whatever you define them to be. They can be alerts and notifications to data quality issues that are found. They can be notifications or alerts to different kinds of situations that need to be followed up on, for example, a disease outbreak or a stock out. Again, the point is that you should bring the job to the user, not force the user to interrogate a lots of data to figure out exactly what they should be. DHS2 is smart enough to automatically detect many things, and this is highly configurable. You can configure it to detect different things, and then you can make sure that once that thing is detected, it sends a notification to the person who needs to respond to it. And we can put those notifications as we see here directly on the dashboard. One of the practices that we see that has a very big impact on actually using data is the monthly district data review. In many countries around the world, there is a policy that district health officers will meet at some routine interval, for example, monthly, or maybe even weekly, and review the data for key program areas. In this data review process, they will look at the previous activities that have been done and assess if they had any impact. They will also make plans to review plans for new activities, assign responsibility for those activities. Here you can see some pictures of a district review session. All your district health officers for different programs, sitting around their computers, looking at data, discussing things, coming up with plans and strategies, asking questions. This process right here is, again, how we go from just analysis of data to actually knowledge and data use, this human process of sitting together and working through various analytics. We also see a picture here of an individual presenting a dashboard and talking about the current status. Are things improving? Are things getting worse? How was the impact from the previous month's activities? What do we need to do this month? You know, they're presenting the dashboard live. They're using the dashboard as a tool to communicate how health programs are performing, how they're going, and what needs to be done next. To find the picture, we see an example of an M&E framework for key performance indicators. So this is a monitoring and evaluation framework. This is a critical tool for district data reviews or just data reviews at any level. In this, it defines what are our key programs, their indicators, how their indicators are calculated, what the baseline was, what our targets are. And the data source and responsible person for each one of these. Again, it's extremely important that everyone understands the targets. What are we working towards? And those targets need to be achievable. They can't be outrageous. They can't be something that is completely unattainable. They have to be achievable. They have to be easily understood. And they have to be communicated in the dashboards and the analytics in the reports that are produced. Again, we have many tools to help communicate targets, such as target lines, legend sets in DHIs too that can facilitate this process. I mentioned this previously, but I want to re-emphasize how useful it can be to create district and facility communities of practice. Here in this picture is an example of the community of practice in health facilities in Rwanda. You can see that users in this community of practice are posting questions, pictures of DHIs too. They're asking for insights. They're helping each other answer questions. This type of communication forming this support group has been shown to be extremely valuable. And here in Rwanda, in this example, you have dozens of health facilities all tied into this WhatsApp group where they're all able to just support each other, ask questions, provide answers. And it's also a place that maybe their supervisors can also monitor. And so they can know maybe who's participating, who's not, but they can also see the common issues that are coming up. And it's the responsibility of the supervisors to support the work of those that they are managing. So if there's a common issue, say around data entry or using a dashboard, then the supervisor can also respond saying, we're working on this, we've addressed it. And when they have fixed it, communicate that fix out through the community of practice as well. So it's not just for users at one level, it's maybe also the users and their supervisors in the community of practice. We have two very good case studies on this, again, one from Rwanda and one from South Africa, links provided here if you'd like to go into more detail. Here I want to again point out that one of the issues that we have with data use is missing or unreliable data. And I just want to point out that over the last couple of years within the DHIS2 community in partnership with various other organizations like the World Health Organization, UNICEF. Here I also want to point out and reiterate on a key point about missing and unreliable data. Over the last couple of years, the University of Oslo and the DHIS2 community have been collaborating with some key partners. For example, UNICEF, WHO and Global Fund as well as some other technology providers like Grid 3, Crosscut, WorldPop to explore alternative population sources. So again, one of the key issues that I've mentioned previously is that we have unreliable population statistics in many countries. And those population statistics do not go down to low enough levels. For example, health facility level or community health worker level. There are many organizations working to address this. And within DHIS2, we are trying to bring all of the insights and innovations around missing or unreliable population sources into DHIS2. So working with partners like Grid 3 and Crosscut, FlowMinder, we've brought in new tools for building facility population catchment areas. For example, having multiple population sources that can be used for calculating different indicators. These are now available in DHIS2 and we have a webinar explaining some of these here that's linked on the slide. And again, we also need to make sure that we're getting data from all the various sources. Supply data, maybe education data, especially for doing outreach campaigns for immunization or vaccination for children at schools. Of course, community health data, HR data, disease surveillance data, and then this can go on and on depending upon the various health programs provided in the country. Real quick summary of what we've gone through in this presentation. There were some core data use principles. We talked about the virtuous data cycle where data quality and data use are connected together. And if we want high data use, we need to have good data quality. We talked about some reasons that data is not used. Sometimes data is not accessible. It's not available. It's not reliable or systems are overloaded with too much metadata and they're not able to find the data that they need to actually use. We talked about some improving data use practices, making data capture very simple, making presentations very specific to users and keeping them very simple. We talked about how to get data out of DHIS2 through dashboards and notifications. We talked about some data use best practices like having good standard operating procedures for your data use processes. How to use data in meetings, having district action plans or routine planning cycles where data is being used, and of course having standard, excuse me, communities of practice of users who are able to share experiences and insights around their data using like WhatsApp or other messaging services. We also talked about how to address missing data. So some data quality processes to identify outliers and address those. Thank you.


Hello, welcome to the Jenkins documentation office hours. Today is March 7th, and this is the US edition. At the moment around the table, we have myself, Kevin Martens, Bruno Verakhtin, and Pranav Singh. Welcome, Bruno and Pranav. Appreciate you being here. And if anyone else joins, we'll welcome them in, of course, as always. And yeah, we're recording, so the video will be available afterwards as well. For today's agenda, I thought we'd touch on the next LTS release, which is 2.440.2, the latest contributor spotlight publication, weekly release for this week. Yesterday, we had a security advisory, so I want to make sure we note that down. Just another reminder about the contributor summit recap, some notes on Google Summer of Code, the Jenkins Community Awards, just again, noting the JIRA upgrade for issues.jenkins.io, some housekeeping regarding Asia Docs Office Hours, the version documentation for Jenkins.io, the tutorial revamps to use Docker Compose, and lastly, on the agenda, I have the sponsor attributions page, which we've been discussing. Is there anything other topics that we want to make sure we touch on or discuss today in Docs Office Hours? I'll think from my side. Thank you, Kevin. OK, so first up on the agenda, again, so on March 20th, we anticipate the release of Jenkins LTS 2.440.2. The back ports were just made available on Tuesday. I've already created the change log and upgrade guide pull request here, so I do want to just touch on this real quickly. But it's not a large change log and upgrade guide this time around. However, there were a couple of different updates that I've been touching based on with Basil Crow about. Specifically, there were two Jakarta plug-in updates. The activation and email APIs were both updated. If they're not updated at the same time or one after another immediately, there is going to be a breaking change. Similarly, there was an open JDK update in the upstream that's also caused a breaking change. So I wanted to make sure that we alert users to these things. So I'm including them in the upgrade guide. As you can see here, I've added in a note stating that these updates are not specific to the LTS release, but they've happened in the last week and they are crucial, so I do want to make sure they're included in the upgrade guide. This was the original version of it that I took a screenshot of. But I've updated it since to put that note at the very top of the upgrade guide for 2.2. I don't want to have any confusion, so it's probably best that it starts it off and then change the updates to upgrades since it's the upgrade guide, not the update guide. So just a couple of things to note there. This is, like I said, it's ready for review. And I will be unavailable for the next two weeks. So in the meantime, Markweight will be available to check on a couple of things and handle some things for me. So like Docs Office Hours, when he's available, stuff like that, and reviewing the upgrade guide before merging it for the actual release. So yeah, just to put on your radar, like I said, it's ready for review. I'm open to as much review as possible. I will be here or I will be available for the next 24 hours still. So I'm still available and can help with anything and make any updates needed. And then just a small note here. So as a result of the upgrade guide for the .1 release, including some code that ended up causing some issues, we're just making sure the upgrade guide and the change log both have screenshots to make sure that they're both rendering and loading properly. So something to see from here on out. Next up on the agenda, so again, we've had our contributor Spotlight going for a few months now. Yesterday, we published Stefan Speaker's Spotlight. So thanks to Stefan for collaborating and providing his insights. It's a really great story. And Stefan's a really wonderful contributor. It was really nice meeting him in Brussels at Fosdham and the contributor summit. So just thanks for being part of the community, Stefan. And yeah, if you have a chance, check that out and learn more about Stefan. The weekly 2.448 was released successfully on Tuesday. If I recall, there might have been some issues in the back end of things, but everything went smoothly, the release went well. There were just a couple of pickups that needed to be addressed, I guess, on the back end, but nothing serious or worth noting here. There was a security advisory published yesterday. So thanks to Jenkins security team for all of their work on resolving these things, taking care of the advisories, publishing these things. Really, really great to have that be part of the process. And it was specifically for plugins. This did not affect Jenkins core. And so as such, the weekly changelog is just the weekly changelog for 2.448. It was not a security release in that sense. So yeah, just something to be aware of there. So we published our contributor summit in Fosdham recap just on the 28th of February. So just about a week ago now. Just a nice recap here that I was able to write up going through the presentation. We've got a link to the slide deck here so you can review it and read through it, follow along. And just, yeah, just really nice experience. Thanks to everyone for their contributions, for joining, for participating, for coming to Fosdham, for just everything. What a great experience and what a wonderful contributor summit we were able to have. Next up for the Google Summer of Code. So just a couple of weeks ago, we were officially accepted as a GSOC organization. So we have a blog post in the carousel on Jenkins.io has been updated to reflect that. We have nine draft proposals thus far. We've got a couple of returning GSOC contributors now as mentors in Harsh and Vandeet Singh. So thanks to them for coming back and joining. And we've also got a new mentor from Lara. So welcome to Lara. And thanks for joining up. Appreciate it. Really great to see new folks coming and joining the project and participating in Google Summer of Code specifically. The contributor application period is gonna start on March 18th. So a couple of weeks from now. And then the application period's gonna end on April 2nd. So be aware of those timelines. The blog post that Alyssa and Jean-Marc have put together has a lot of the information and timelines and key dates in there as well. So this is really crucial. This is a great place to just keep track of things, get that information. There's also the Gitter channels. We're very, very active in the Gitter channels at this point in time. Lots of activity. Chris Stern is one of the org admins and has been replying to everyone that they possibly can and doing all the work they possibly can. So thanks to Chris for everything that they do because it's not just limited to Google Summer of Code. But yeah, just a lot of great actions are being taken, a lot of activity. We're getting submissions. There's still plenty of time to work on these things but things are looking good here. Bruno, any notes on GSOC that you wanna share? Any insights that I maybe missed? No, nothing really important. We have begun the review of the nine first proposals. So it's not yet official. It's some kind of discussion between the contributors and the mentors. So we are reviewing the proposals and telling them, sometimes you have to dig deeper or it should be more precise or this is a good idea. It should be more developed and so on. So it's nothing official for time being. It's just a time where we give some advice to the contributors with their first proposals. Not all of the projects have received a proposal yet. I think, for example, of Valentin de Lé project about open rewrite recipes for Jenkins. And there is a lot of activity in the GitHub channels regarding this project but not a proposal has been submitted yet. Which is a good thing because I think that potential contributors are working on their proposal. If you want to get good proposals, of course people have to spend some time on crafting them. So all is good, we're still on time. You can also onboard new potential contributors. We still have plenty of time for that but I would just give an advice to potential contributors, take your time, build your Jenkins muscles. Yeah, take your time, do something good. Yeah, take your time. Sorry, I'm repeating myself but take your time, do something good and that will be better for the whole community. Great, thank you very much Bruno. And I think it's nice that we're getting that activity in the GitHub channel. People are curious, they're interested. That shows a lot of initiative from the contributors and from mentors like this is just, that's great to see even if the numbers are not necessarily as high as we had hoped for, it's quality, quality, quality, quality. We're only gonna have so many projects anyway so we're gonna end up filtering some things down but that excitement, that interest, that activity is huge and really shows just how important, not only Jenkins but Google Summer of Code participation for the organization is huge. It is. Great, cool. Thank you very much Bruno. And oh, are there any scheduled meetups coming up that we should note or is it, we're kind of like figuring things out and that will alert everyone when we have the next meetup scheduled? Yeah, I don't think we have a date scheduled. Yeah, no, not yet. It will come when it will come, I guess. We presented, I think, most of the projects in the last two meetings. There are still one or two projects, I guess, but nobody showed interest for them so I think it will stay as is. So no, no meeting scheduled for the time being. Okay, great. Thank you very much Bruno. Next up on the agenda, so the Jenkins Community Awards, this was announced recently enough towards the end of January, yeah. So the nomination periods have closed but the voting period has been open from the 22nd of February. It's open till March 22nd. So if you have the time or if you have, if you wanna check out the candidates, you can go to the individual award issues here. Each one will take you to the pinnedissue in Jenkins.io's GitHub repository where you can see the nominations and then there is a voting form that's available and this is also in the announcement blog post that Alyssa put together. So you can access the voting form from either one but it's gonna be a voting form specifically for the Jenkins contributor awards 2024. The voting period, like I said, we'll go to March 22nd and then the winners will be announced and awarded at CD-Con this year, which is in April. I wanna say 18th to 20th, they're 21st. I forget exactly what the end date is but yeah. So same as last year, last year's winners cannot win again this year. So the nominations are a little different and then there's also a voting form for the complete CDF awards outside of Jenkins project. So this is where they'll have CDF ambassadors, contributors, stuff like that. Mark, Wade, did decide to nominate me here for top documenter. So if you wanna vote for me, what's that for? Vote for Kevin. Yeah, you can do that. I don't wanna talk about myself but we've been over this. So that's the thing, you can vote if you want to. I would appreciate it. I don't know if I have to go to CD-Con at that point but we'll see if that's if I'm a winner. And Kevin, sorry to interrupt, just one question. I know who can vote for the Jenkins awards. You just have to be a contributor in a way or another. But what about the other ones, the CDF one, who can vote? That's a great question. And I'm sure the CDF foundation would be more excited if they are all project contributors, Jenkins, Tecton. I don't think that part matters as long as someone's a contributor to open source in some way, shape or form. I think that's more their concern but they advise that there's some kind of connection but I mean, if people are coming to this meeting, they're interested in some part of open source. So I would hope that there's some connection there. So let's see if we can vote. That's okay. I think as long as you vote for Kevin, you're allowed to vote. Yeah, that's exactly what we're going for. No, I think it's just a matter of as long as you're part of the open source community, you have every right to vote in open source presentation or whatever that might be. So yeah, next up. So JIRA Upgrade for Issues.Jenkins.IO, this is the status page to let everyone know that there's gonna be some downtime on March 12th from 11 p.m. UTC to 2 a.m. UTC. So it will be down for a few hours but the upgrade shouldn't, this shouldn't cause any sort of disruption in service or anything along those lines. This is specifically for your issues.Jenkins.IO. So users of Jenkins shouldn't run into any problems or anything like that. It'll just be more if you're trying to report bugs or anything along those lines. And so this will happen. This is really just to note, be aware of it. There will be more communications as we get closer to it, maybe an email blast, but yeah, just I'm gonna be aware of and keep in mind shouldn't have too much direct effect unless you're up at that time and trying to get on the shoes.Jenkins.IO. Next up, the docs office hours for this evening is canceled. So Mark's not available to host as am I. So next documentation office hours for Asia will be the 15th. The version documentation build site for Jenkins.IO. So just to a quick recap, this is the result of 2023 GSOC project to build Jenkins.IO with an alternative build tool. The tools selected were Antora and it's a combination of Antora and Gatsby, Gatsby specifically for generated pages and some flexibility and more customization options. So Kristen and Vande Singh have been working on this. I've been helping Chris and Vande with review with finding any issues that might pop up, anything along those lines where I can assist with their, the blind spots they might have, I'm in the site a lot more than other folks.  And then Chris and I met with Daniel Beck who's part of the Jenkins security team to just go over the generation process for security advisories, make sure that they're comfortable with this update because it is gonna affect them as well. And we were able to reassure them that this is gonna be a great move, that it's more powerful, that it's faster, that it's just a better experience overall. And so Daniel Beck left pretty happy. So we had a great session with him and we were able to, yeah, just absolve a lot of the fears and like concerns that they had. So that was fantastic. Chris and Vande are continuing to work on this. This isn't totally ready for production yet because we're looking at cost saving measures for Azure still to some degree. So once we get all that figured out and I think you were getting to the point where it is figured out, this will come back into the discussion and part of the infrastructure milestones that we'll be working on in the coming weeks. And then additionally on top of that, Daniel Beck actually created a pull request and submitted it, suggesting that we potentially have generated pages for each individual changelog. So instead of having an anchor link that takes you to the changelog entry, but then also loads the rest of the changelog, it would be a separate page for each release changelog notes where it's just 2.426.3 and nothing more. It's a faster load. There's not as much noise going on that the user has to either sort through or just kind of like put up with. I think it's a good move. I think it's a really nice and easy solution for something that could be very, not something that we necessarily consider a lot but could be very limiting or detrimental to the user experience in some way, shape or form, just having to load that whole page, scroll through, find stuff, et cetera. So, yeah, everyone seems to be pretty on board with this idea. So I think it's something that will eventually get implemented, but we're not there yet. So time will tell. But yeah, I think it's a good idea. Next up, so we've now got the Maven, Python and Node.js tutorials all revamped to use Docker Compose, amazing. Again, this is the result of another GSOC 2023 project being seen to completion. Thanks to Harsh and Bruno for their work on this. This is great. And yeah, we still got some work to do, multi-branch pipeline tutorials next. There's a couple of things there that need to be taken care of and addressed before we can really incorporate the Docker Compose properly and have it working, I guess. Unless there's been some change since we last met Bruno in that sense. Not really, in fact, I have a new pull request for the Node sample source code because something is wrong, but I guess we will have to wait until Mac comes back to merge the PR. It's nothing important for the same being, it's just a problem of port 3000 instead of 5000. And then I will have a Node code change also within another PR, but nothing really important. So it's almost ready to be reviewed, at least when my two PRs will be merged, then we'll be able to have the tutorial that reflects correctly what's happening in the sample source code repo. But yes, it's near completion, I would say. Great, and as the other, I had this note from last week, Bruno is the React code, the other piece of it that you're waiting for the PR to be merged on or is that something separate entirely still? No, I haven't created yet. The code has been created, but I haven't created the PR yet because I think no one is there to review and merge it. So no hurry on that side. I have made a PR on another thing, just support number that is not correct. And that's all, yeah. Okay, great. Thank you very much. Appreciate it. And then the next thing on that too is that once we get the tutorials revamped and get the documentation sorted in those areas, we're gonna look at incorporating Docker Composer to the installation docs. It's a better experience overall, it's a lot more secure. And frankly, those two things alone are reason enough to update the documentation accordingly. So I'll be working with Bruno on that point and he'll be showing me the ropes so that I can get the Docker Compose integration going for installation. And last up on the agenda for today, the adding the sponsor attributions. So to recap this one, we've been discussing for a little while now, but essentially JFrog wanted to make sure that they're attributed as a sponsor for the Jenkins project. We said yes, because that makes absolute sense. They are, they should be attributed as such. However, we wanna make sure that we're attributing them properly. And that led to a larger discussion of right now the Jenkins.io site only has a sponsor attributions at the very bottom of the main page here. So we were discussing adding a complete sponsors page that would showcase all of the sponsorships of Jenkins. So that's now, but that process had been started. Basil Crows created a sponsors page draft. We're looking at various levels and how to attribute sponsorships from anchor all the way down to bronze, mirrors a different kind of sponsorship. So it's gonna be a separate category in that sense, but we're looking at what kind of services, credits, cost, like there are varying types of sponsorships and ways to sponsor. So we have to really take a look at all of that and figure out what that equals out to essentially and like what level that means for each sponsor. Cloudbees, for instance, is an anchor sponsor. And AWS just granted us 60,000 credits to Jenkins. So like that's one of those things where we have to see, okay, AWS is clearly a very large sponsor. Does that make them anchored? Does that make them gold? What kind of levels does this get attributed to at that point? On top of that, did the lotions donated both last year and this year, Microsoft's donated. And just recently, Ampere has donated two ARM64 servers. And these are physical servers that are located at Mark Wait's house. It's our first time sponsored, getting, being sponsored by Ampere, but it's been in the works now for about a year. Thanks to Bruno for all of his work and keeping in contact with Dan and, or no, not Dan, was it? Aaron Williams, but yes, that's my pleasure. You know what? We also discussed with pine 64 CEO at Fosdame, TLM. And today I received in the mailbox a few boards for evaluation for Jenkins. So that's pretty cool. We got, I haven't opened the pocket yet, but we got as far as I know, two ARM64 boards and one RISC-5 board. So thanks a lot, pine 64 for your support. And I, it's been a few months, but I've been working with a program called Pioneer Dev Board Program. It's some kind of consortium between RISC-5 and MILK-5, who happens to be, I think, a hardware maker or something. And they should send Jenkins RISC-5 board. It's not a server. It's some kind of workstation, but that would help if ever we wanted to make the move to RISC-5. So yeah, I don't know if we need a label, a special label or something for hardware donors, but they are sponsors. That's a really interesting angle to that end, Bruno. Because that doesn't necessarily fit into one of these. Obviously, maybe there's like a monetary or value component we could look at for like what that would look like. But at the same time, maybe there's a better way to categorize that sort of sponsorship. Like you said, like maybe mirror, maybe we have another one for hardware or like something along those lines. Because the servers would technically fall under something similar to that, I would imagine. So, yeah. So I think there's definitely room for discussion on that front. I would say if anything, it might be worth like, maybe commenting on it and just like, it's good. They didn't ask for any kind of compensation or you don't want to be cited or whatever. There is nothing they want from us, but I think it's unfair not to tell about their support. Yeah, I mean, at the end of the day, we don't have to necessarily attribute them as a sponsor on that page, but we could also- Somewhere. Submit a blog post, like saying thanks for the, or a series of tweets if we wanna do one for each of them or like, I don't know, we can figure something. That can all be determined at another point, but yeah, I think acknowledging it and highlighting it is something that we can definitely do, but yeah, maybe it doesn't fit on the sponsor in this scenario. Maybe it's meant for something else or like I said, we'll figure it out. But yeah, I'm not opposed to writing up something, doing a blog post, doing some kind of highlight for them, that sounds like a nice idea, so. Thank you, Kevin. Yeah, of course. Okay, and we've reached the end of the agenda for today. For now, do you know any other things that we didn't talk about or that you wanna discuss? Nothing on my side, Brad. Nothing on my side, I see. Okay, great, thank you very much. So in that case, we'll go ahead and wrap up now. The recording will be available in 24 to 48 hours, as usual, I'll make sure to post it on the community discourse site. And then yeah, I won't be here for the next couple of weeks, so thanks as always for joining, I'll see you soon, and in the meantime, take care, stay safe, and yeah, say hi to Mark for me next week. We'll do, thank you, Kevin, bye-bye.