We've heard a lot about migration both historically and in the contemporary period and we've also heard a lot about aging populations But what happens when we think about these two issues together? The world's population is aging but in our interconnected and mobile world a lot of people are growing older in places They might not have imagined Individuals families and communities are embedded in networks that span multiple places What we're interested in looking at are the implications of growing older across borders in an inter-globalized world How do older generations and their families construct a meaningful life in these contexts? Until recently aging and migration have been addressed in separate scholarly debates The study of aging for instance is understood as a process that occurs in place While migration studies have tended to focus more on younger generations Our aim is to look at the links between these two processes and to look at the joint Transformations that they have on our societies. We take for example the experiences of older refugees of Diasporas who are aging abroad of people who move to a new place in retirement Or who return to their country of origin and we also look at the stories of people who don't move But whose family members have migrated abroad In all of these migratory contexts, how do people reorganize and think about questions of care health family home and identity Geographically, we are looking at regions of the world that are aging the most rapidly But that have been less addressed in policy and scholarly agendas namely Asia Latin America and parts of Africa in all of these cases. We are looking at how migration shapes the experience of aging And also what a focus on older age tells us about the migration process We are interested in how these larger-scale processes play out in people's everyday lives Specifically, we look at different groups of migrants or people who are affected by migration To see what it really means to be aging in a context of migration This could mean working with a group of migrant workers It could be working with older refugees or people who have been displaced It could also mean speaking to people whose children are far away. And what does that mean for their care? In order to do this, our primary methodology is ethnography or qualitative fieldwork-based research This means that we spend several months immersed in our field sites in conversation with the people and communities that we study We conduct in-depth interviews with them to understand better their biographies their motivations Their emotions and their aspirations and we also do participant observation Which means that we observe the day-to-day activities and routines in our field sites Observing how people live and what they do doesn't always match what they say they do Our fieldwork is also multi-cited Which means we follow and we trace these migration connections across different places Some of the spaces of our fieldwork include cities, villages, spaces of worship, parks, shopping malls, community gatherings and Increasingly digital spaces because that's also where people hang out We complement our ethnographic fieldwork this micro focus on stories and biographies and narratives with a larger scale analysis of archives, of policies, of laws, the things that shape the historical, political and economic context that affect the lives of our research participants. We also look at cultural texts such as songs, films and poetry that depict the themes of our research We have four key findings that relate to diversity, inequality, social policy and Agency. Let's start with diversity. Even if we think about aging as a part of our collective future and as a universal biological experience There's far more diversity in experiences of aging than popular representations might convey. Aging is not just crossing a specific numerical threshold But there are culturally and locally specific expressions of this They are reworked in context of migration and they are also affected by political, social and economic factors Secondly, there are significant Inequalities in aging and that's why it's very important to look at the category of age in conjunction with other social and historical markers of difference, such as race, class and gender People who have experienced structural discrimination and exclusion over the course of their lives are likely to face difficulties in accessing care social services and livelihoods at a later stage of their lives and this can also affect the next generation. The politics of migration here also matters. The extent to which people are able to cross borders, the rights to citizenship It matters in terms of what kinds of social support older people will have When they get to that stage of their lives Some groups with privilege are able to cross borders more freely and purchase particular lifestyles in retirement While some people will still struggle to make ends meet The third key finding has to do with social policy and the ways that social policy In relation to care or health or pensions are not in sync with the realities of transnational living They tend to assume that people stand stay in one place We also find that ideas about welfare and retirement are not shared in all contexts In some cases state-based forms of social protection are being cut back And people are having to rely increasingly on informal Or privatized forms of social support in other cases people work as long as their bodies are still able to They don't follow this institutional definition of retirement age And this is especially relevant in contexts of social and economic insecurity Finally and importantly Our findings reveal how people respond creatively and with agency to these challenges Migration generates new meanings of care of family of home and of aging itself We find that people find creative ways to take care of each other across long distances They use digital technologies increasingly and good care does not rely solely on physical presence Contrary to assumptions that older generations are merely passive or sedentary recipients of care Our findings demonstrate the multiple ways in which they participate actively in household decision-making In politics building new communities and pursuing desires and aspirations of their own Our findings are relevant on three levels conceptually in terms of policy And also in terms of public perception Conceptually the findings are relevant to both the study of aging and of migration In studying migration the lens of aging allows us to think about the passage of time The importance of a life course perspective and the intergenerational impacts of migration We can think about migration as something that changes over time Not a fixed or linear journey that simply goes from A to B and then stops In terms of the study of aging the transnational lens pushes us to think beyond a nation or place-based framing of aging An anthropological perspective here can illuminate what we take for granted or what is assumed and to reveal a far more complex reality The findings are also relevant in terms of social policy if we think about policies relating to care and to health And how a transnational optic can allow us to reimagine these policies In a way that makes them more flexible to the needs of families and communities Whose lives are stretched across multiple places and countries Finally the findings are relevant in terms of shifting public perceptions As we've seen older people are not merely intrinsically frail or passive or unproductive or less valued members of societies As aging, ageist stereotypes might convey Similarly, aging is not an alarmist demographic crisis Nor is it a grand success if we think about the development interventions that have contributed to longer lifespans, but it's something far more ambiguous Similarly representations of migration that we might find in the public sphere Tend to overlook a lot of the nuance What we find is actually multiple generations of migrants whose journeys have fundamentally shaped the contemporary societies that we live in today Until now we have brought anthropological perspectives from different parts of the world Especially those parts of the world less represented in research agendas to understand the meanings of aging and migration What we need to do next is build on this. We need more comparative research looking at perspectives from the ground up so that we can better understand commonalities and differences across different contexts And also so that we can make sure that the experiences of one part of the world Don't automatically come to represent The whole of the world that are not taken as universal. So we need to nuance the more Eurocentric dominant framings of both the study of aging and migration Secondly, we need to further our interdisciplinary conversations so that Anthropologists and geographers and sociologists like us are talking more to gerontologists To demographers to scholars working in social policy and migration policy Only then can we really understand the innovations and also the blind spots in different disciplines And to come to a better understanding of the multifaceted nature of these social issues Finally, we seek to take our conversations beyond the academic sphere Because these are issues that are timely and relevant in terms of how we organize think about give visibility to and represent questions of care Intergenerational relationships and older age in a globalized world here We're looking to work more with visual methods to communicate our research to a wider audience


Welcome, it's documentation office hours. This is the 4th of August. Thanks for being here topics on the list include Google summer of code. Open pull requests of interest. DevOps world tour and possibly canceling the meeting August 18th. Any other topics you'd like to add Chris. Okay, so let's talk to Google summer of code first. Version documentation for Jenkins that I also, as I understand it, Vandy will do a demo. Demo the, the status at UX, the 14th of August is that right. 60 August 16. Yep. Great. Now I apologize, I won't be there I'm out of the office that day. Congratulations. That's great. How's it going? What do you want to show us a demo? Do should I let you share the screen. Maybe not today because like there's some issues with the effects. Because I still chase Vandy to complete like, before into a demo. All right, no problem. Because I think there's some broken lines to do as of understanding, but not, not sure. Okay, some perfections. Great. So let's see us. If I look at Vandy. That's here if I remember right. And so here's 2.1 and two. Okay, so, so versioned is working. Good. Very good. And edit this page takes me to his page. Nice. And still the much better expansion and contraction on the left. I do have some questions about like, what we should do regarding existing versions. Because we have to come they all up to where. When you say existing versions you mean what should be in the pick list here. Yeah. Oh, see, and I would think we own, we would say. The only baseline of LTS versions would be my assumption. And maybe then only the most recent one now, just do 2.401. And call that good enough. And then when 2.414 releases, we could create a, create a snapshot or create a branch for 2.414. I wouldn't, I wouldn't do more than anything finer grained than, than the long-term support releases. Okay, cool. Yeah. It's a good question. So, and that's certainly a good question to ask in the. How many versions. Should be in the documentation in the list of versions. Or maybe we say it this way, which versions. Should be in the list of versions, right? Yeah. And my thought was. Mark thinks. LTS baseline. So 2.401.1. 2.414.1. Dot, dot, dot. Or maybe it's 2.401.1 represented by. 2.401.x. Okay. Yeah. You know, that's, that's the concept. Dot one is probably more accurate because we'll certainly take the snapshot. We'll create the branch at the dot one branch. But it'd be understandable to say, okay. Dot X. That would be fine with me either way. Okay. So I. Weekly seems too frequent. And. And won't have many changes between wouldn't have, would not have many changes between branches. Okay. Because we're not. We're not evolving that quickly. And if we look at. Command like it, they release every three months. And when they release every three months there. Their documentation has, let's see, let's go look at the reference. So here's one. Yeah, they do. Oh, they, they do. They do even their dot releases. So they do even dot. Dot two compared to two dot 37.0. Interesting. I'm, I still think. LTS baseline would be enough. May. What, what we're discussing here is this is Vandit sings. Google summer of code project proposing to rework the Jenkins documentation so that the user handbook is versioned. So we're up here in the top right hand corner, the 2.1. Let's make it big enough to read the two point run here in the top right would become two dot 401.1. And 2.2 would be two dot 414.1. So that it matches with the long-term support version numbers. The, the thing we're trying to match is something like what command line get does with their documentation that is has been changed pages for their documentation. So I can always go back and see what was two dot 25 actually doing. So question Meg for you is. Do you think it would be okay if we just limited this to the long-term support version so that it won't change more than about once every three months. Oh, you're muted Meg. Shoot there. Can you hear me now? Yes. I'd be comfortable with that. I mean, we don't, we don't have that many changes, right? That. Correct. And it's, I'm thinking that in the last majority of the cases, the changes to the docs for release aren't related to software that changes. Right. They're just improvement. So yeah, that's. It's always, I mean, it's a temptation to be really, really precise about it, but also that becomes mind boggling that I, you know, it's a lot read easier to remember 2.1, 2.2 versus 2.138.3, you know, or something, the longer numbers. Right. Well, and my worries is if this, if this menu has. 150 entries in it. The reader will get lost. Right. It's just too many and already with for a year. If we, if we were to do all of them, we should not. I think we should just start where we are. But if we were to do all of them, we would have. LTS is what that would be 10 years at four per year. So this would be a 40 entry. 40 entry menu. So that, that would still be a very large menu. And to look at gets theirs is probably 20 already. Yeah. Yeah. I'm thinking we should cap the number of versions available on the drop down to that. That's probably another good eight. Well, and, and I like their pattern here. I always this one. No, I thought I'd seen some version documentation sites where they'll give you a, we'll show you the first five and then give you a more link or something like that. Now you are looking at the reference stuff essentially man pages. What is it? They've got a book thing. What are they? There. So the book actually is a real book. And so that one, I'm not sure they do. It's, this is, this is a representation of a published book. Okay. And so it's, this is a physical book that they, for whose source code is intentionally open source. So they actually do not have like how to, they don't have guides as part of their documentation. They have the reference. Well, they've, they've got the book. And the book. The book is, and the book is very much a how-to. Right. But I mean, it's a published book. It's not like online. Well, it's also available online, right? You can get it as a pub or PDF or read it here. But it's not being updated with each new release. Yeah. Well, right now it's on its second edition. So, so yeah, there, the book has, has had, had multiple revisions. And I assume every, every so often. So right now it's, oh, it says it's 2014. That's pretty badly dated in the world of get. Yeah. Yeah. They've made major improvements since then. But I see that. I mean, that's, that's an old theory that I subscribe to. You do these reference things and those you keep up to date. Also because it's a fairly small effort. If you add an argument or, you know, rename those, you know, you can do that pretty quickly. It's not like rewriting prose. It's very clear. And so this is, if you really need to know the up to date stuff, you go to the reference and then the other is conceptual. Get the big picture. And that certainly matches. The book is very much conceptual here and the, the reference materials are, are very detailed. Uh-huh. As they should be. Okay. Good. All right. So. Uh, so Meg agrees. That. LTS baseline is enough. Thus. Four times per year. Which will still, and then recommended, or is there a way. That we can cap. The number of. Releases initially displayed. Well, not just initially displayed. We're assuming that the world goes on. Right. Okay. So, I mean, if, if we say no more than four releases, what have we got for now? We're going to say we're going to do four releases now. What are we going to have in a year and a half from now? Yeah. Are we going to, as we add a release, are we going to take one off? I assumed. I assumed that. Oh, go ahead. No, I'm done. So Mark assumed, keep all the versions available. But only show a subset in the menu. Allow. More or something like that. Now, no idea if that's even possible in Antora. I don't know how what, how Antora thinks about this. Chris, do you have any idea what does Antora do with regard to many versions? I'm not sure. Probably have to do some manual. Okay. Great. Any other topics or questions on the version documentation for Jenkins.io. That is a concern actually I would put in as we go through implementation to keep an eye out for how much of this becomes a manual effort. Because it seems to me it's the sort of thing that really needs to be. You know, I don't know if it's automated or maybe that changes how much you do it. Well, so when you say, say, manual effort, I'm assuming Chris, maybe you can, you can certainly help. I've missed the, the presentations that I've on date. With vacation and whatnot. Is. Is it dependent on just a branch and then it will build everything from that branch. So 2.1 in this example. I think so. Yeah. Okay. Excuse me. So Meg, I think, I think to answer your question, how manual is it? It's easy to create a new branch. We just. Get check out minus B of the branch and then push it to the central repository and probably add an entry in some configuration file that says read from this branch in addition. Yeah. I don't have, but I don't think this is reasonable. Is a star for a release where this document changed from the last release. Okay. So, so some indication of. I mean, I have one of these things rewritten for five years. You know, just to know that at this, this thing changed at this. Yeah. And I don't know if Antora's got such a concept. We've, we've intentionally been guiding Vandi to stay, or at least I think that guidance has been stay with Antora base functionality where we can, which makes sense. Yeah. Chris, go ahead. I think we may be possible that the feature, I think I asked us to next to the assertion might be possible. We need to investigate. Yeah, possible and worth the effort. Yeah.  And that'd be nice. I mean, it would be handy for Mark. To open up and look and see. You know, and then you could see that something has not changed for the last four LTS releases. And you know something about what's been in the releases and you're like, why is that not changed? Okay. Good. All right. Good suggestion. Anything else on that topic, Chris? Um, probably not. Much except for the fact that it still has exams. So we have to wait until he comes back maybe next week. Okay. So, so Vandits offline also this, this week. Great. That means I. All right. No problem. Very good. So. We continue then. I mean, it, it looks, it looks very attractive. Yeah. Yeah. What's your sense? Is it, is there. Any hope that it's going to be ready for merge at the end of the project, or more likely there's going to be a lot of work yet to do. I think, I think it might be possible. It depends on the schedule. Because I'm, I'm kind of worried like there might be some, like some other like integration. Issues that may crop up. Yeah. Yeah. Yeah. Got it. Okay. Great. Thank you. Thanks very much. Oh no, I had missed that we have build status. I need to remember that. That glossary entry is a good thing. Good. Okay. So we've talked about version documentation. Docker compose for tutorials. I was, I was hoping as your talk should show up. Well, so we did a demonstration last week. With us. For 45 minutes. Okay. And then I saw a demonstration. A five minute demo or a demo today from Bruno. And he'll do another demo. Bruno will, we'll do a more detailed demo. In office hours Europe. Next week. So it's, it's looking, it's looking quite good. I was, I was thoroughly impressed when we worked with it last week. Meg, what was your sense from being involved in that demo? I'll make may have slipped off. Okay. So I was, I was really very pleased. It's, it's now. I'm sorry. I muted myself because I was being noisy. I thought it was very, very nicely done. I was impressed. And the way he presented it, it was. Yeah, I just to give a, to give an indication. So I've got to show the thing that I just went through about 30 minutes ago to, to test drive. A change of version in one of our tutorials. So let's go look at this tutorial. Here's the Python tutorial. Right here. Click, click, click. So in this Python tutorial on my Linux thing, first thing I had to do is paste this command. Then paste this command. Then scroll down. And paste this content to a file. Then paste this command. And then. Paste this command. Okay. So you can see that there's this long horrible experience for the user. Copy and paste an awful lot of stuff. And keep track. So you don't skip something. Right. Don't skip. Don't miss a line, et cetera. And finally, after all that, you've reached the post install wizard. Well, what, what Bruno's. Has changed this whole terrible thing into three commands. Get clone. CD. Docker compose up. Oh. And it's that simple. And, and. Now inside the Docker compose. It's actually running. Two Docker containers. It creates a dedicated Jenkins agent. That's used for, with. The tool for the particular particular. Demo so in there for the particular tutorial. So in this case, because it's a Python tutorial. The agent has Python installed on it. The controller runs no jobs. So big win. Because this one, this demo. Actually relies on running jobs on the controller. Yeah. Do as we say, not as we do. Yeah. Right. Exactly. This. The Docker compose thing. Takes away some of the shame that we have hiding in this thing. Okay. So any, any questions there. I am, I am truly pleased with how it's going. And so I was impressed last week. Cause, cause Mark was playing with it. And he kind of tried to break it. He was trying to do some things. I think he was ready to explain to him. He's like, Oh, that works. So I thought the kid, the kid had shown that he, he's playing attention knows what he's doing. Yeah. Yeah. So it's, it's looking very good. Really. And, and it's a nice, nice improvement compared to what we've got. Okay. So, and it's not just, you know, when we say, oh, well, you know, it's installing Jenkins in the Docker environment can show that as well. Here's how you do it with Docker compose. Instead of this long horrible sequence. And by the way, the Docker compose thing converges Linux and Windows to use the same command. So instead of two entire sections. In the documentation on Mac OS and on Windows. You just on both of them say Docker compose up. Okay. Yeah. Nice. Yes. Any, any other questions or concerns on Docker compose? Nope. I've got one more Java 11. 17 here. I'll just copy it from earlier. I've got one more topic that I want to be sure we include here. And with the two of you here, it's a good one for us to be sure that we cover. Okay. Good. So. Docker compose next one is get lab plug in modernization. So here Mark has lots to test. Yeah. And I believe we're scheduled to meet meet in about, what is it about 12 hours? So, yeah. So I hope to have some testing to report then. We'll, we'll go forward and discuss there. And then the week after that, we'll go ahead and talk to you. Okay. Plug in health score. And so Jagruti seems to be, seems to be proceeding. There's some concern there. And they're discussing and seeing how, okay, what's next, how to help, et cetera. So. Moving forward. Good. Okay. Anything else on Google? Summer of code. Okay. Upcoming dates maybe, right? Yeah. It's for the final. Finally, valuation opens. August 28 closes September. Right. Yeah. Have we already done the midterm evaluations? Yeah. Midterm evaluation all four past. Okay. Oh, that probably why you are on vacation. That's why I didn't get updates and elsewhere. Yeah. Yeah, I don't remember. I, I definitely submitted my midterm evaluation. Okay. Chris, anything else on GSOG? Um, maybe the, also the final presentations. So, right, right. Yes. Yes. Yeah. Having them in mid September. I think. Yes, very good. Post evaluations. Okay. Anything else? No. Okay. Next topic then was open pull requests of interest. Here we've got some, some kind of cool news. So. Bruno Verachten. And I have checked that is in fact, how he pronounces his last name. Verachten, not Verachten. It's not German. It's French. Oh. And so Bruno Bruno has implemented. This feature that automatically updates that automatically submerged submits pull requests. Pull requests to update tool versions in the doctorate. Oh, so what we've got to look at is things like this. The one that I just tested. I've got to show you because this is really, this is such a nice capability because we were so erratic. On doing performing these types of updates. Yeah. Well, and, and you've got to track them, et cetera. So what Bruno submitted was a tool used to a tool actually authored by Olivier Vernault. So our free former infrastructure officer. And this tool. Let's submit pull requests to perform updates. And here's the one that I just merged. So the tool. Detected that we needed to change the Python version from 3. 10. 7. To 3. 11. 4. And it targets it on Alpine 3 18 and make sure this is a valid container. And I just ran through the entire tutorial using exactly this setup. And it worked great. Oh no, this is a fun one. This is a dramatically better setup. Okay. This one detected a. A badly outdated Python. So Python two. And. Correctly gave it a, a modern Python, a Python three version. Oh. That's cool. That, that actually is very cool. So. And this is the tutorial that I ex, that I, that I ran. And that tutorial works great. Very nice. So special thanks to Bruno for his work on, on a project. And thank you. Thank you. Very nice. So special thanks to Bruno for his work on, on update CLI, on using update CLI. We've got one open. Because we've, this one. Proposes to increment the node JS version, the node, the version of the node. But it proposes to change from using the long-term support release. To using their, their most recent release. And Damian to portal suggested, Hey, we should probably stay on this one with, with their LTS because. We don't do enough validation. And we certainly don't have automated tests that tell us if these tutorials still work. So choosing LTS for this one, when they have a concept of LTS is probably better. Although it might be good to find out if there's a reason for that. Well, and, and that's, that's a, that was, okay, you just voiced what, what my thought was, but I think the more I've considered Damian suggestion, the practical problem here is this thing could update every month. And if we don't test it, we have broken tutorials. Whereas if it stays on LTS, it updates every three or six months. And the odds of things being broken are much less. Right. But that, but okay, what actually what decides what version it's going to use of something. I mean, is that, is it doing that itself? It will somebody going in and saying, you know, this is what we should use for this. Yeah. So what I think what, what updates CLI will be taught is use something that has a base of 18. And then only increment the things after the 18. So if there were an 18.17, it would, it would choose it. But 19 or 20, it would not choose because those are not LTS's. So the, the initial configuration, at least that's how depend about works. You have, you tell it, I don't want things for to go any higher than this. Okay. Thank you. Then yeah, the one, I don't know, the one concern is once in a while, you get something where the LTS has a security problem. And there's a later release that's not LTS. It's just security feature fixes for that other one or something. Yeah. And if, if that occurred, then their LTS users have something that has a known vulnerability and that's, that would be rather uncommon. Yeah. I would expect just like Jenkins LTS when, whenever we patch a weekly for security fix, we also patch LTS. Okay. So that would be the 18 point something would be exactly 18.16.5 would be released if dot four had a, had a bug, had a security issue. Great. So I hate to disagree with Damien. So a very wise choice. That's good. He's, I like his ideas. So that, that looks really, really quite good actually. I'm, I'm truly thrilled. Next. Next topic on the poll requests of interest is this. Is this Kubernetes outline from Tannous Sharma? And right now there's been no additional, no additional progress on it. We've given our feedback and Tannous has, has not been back to it. So we've, there've been four or five commits that I did that Kevin Martens did of things we thought would help. But needs needs Tannous to come back before it. It, it gets more time. Yeah. Anything else on open poll requests of interest? Okay. So next piece and Chris, this one for you as, as in your role as release lead. I started a conversation with the release officer. With all the Jenkins officers and the board using this. Document as my oops. Using this document as my framework. So the concept here is that. Java 11 will reach end of public support in October of 2024. Right. So. So the first one, the version, the platform we use is October. Red Hat also October. Microsoft actually ends theirs in September of 2024, whereas Oracle will go all the way to October of 2026. If you pay them. And Amazon Coretto will go to 2027 and you don't have to pay them. So there's, there's a range. So we're based on Tamron. And so my proposal to the board and to. Tim Jacome and to Damian and to Kevin Martins was, let's declare that the Jenkins project will stop supporting Java 11. When Tamron stops supporting it. At the end of October 2024. And they were generally receptive to that. I said, yeah, that makes sense that follow that's consistent pattern. Then the next proposal was let's enable a Java 11 end of life admin monitor during October. So that of 2023. So that people who are running weekly have. A little over a year of warnings that hey, Java 11 will reach end of life for the Jenkins project. In October of 2024. So that would then mean it will appear in the December LTS. 2.426.1 or 27, whatever number it is. Any questions so far. Okay, so then the next piece of the story is. Okay, what do we do about upcoming releases? We've got Java 21 coming. In September of 2023. We've got about six weeks from now. Oracle and Eclipse and red hat and. Amazon Coretto and Microsoft will all deliver their builds of open JDK 21. And the, the, this end of support for them commonly goes as far as 2028. And potentially even beyond. So, Eclipse said, Hey, we'll support it till 2029. Red hat says six years 2029. So the proposal that I made was let's plan to release a Jenkins weekly version that supports Java 21 before the end of October 2023. And Basil Crow has agreed to do infrastructure work or not in to do core and tooling work if necessary. I mean, and the infra team have agreed to do the, the work on infrastructure and Kevin Martins has agreed to review and write documentation changes as needed. Any concerns from either of you on that plan. Sounds good. Okay. Then the next piece of the proposal was Java 17. Where here. We'll start active promotion, but we want to encourage people to go to Java 17 because Java, the Java 11 end of life admin monitor will appear in October. And we want to move people along. Okay. Now, if we look at the picture. Here's the picture of the current picture of JVMs. By Jenkins version. The green line that you see going up and then coming down is Java eight. And the green line that you see going up and continuing upward is Java 11 and this purple line here with now something like. 20 or 25,000 installations is Java 17. So even without the admin monitor, we're already getting adoption of Java 17, but our, we would like to dramatically improve this. And start tapering Java 11 off. Okay. So here's another question from, from Damian to portal. What about Java eight in our Jenkins infrastructure? Java eight is already not supported by Jenkins, but we keep it Java eight in the infrastructure because. Old plugins still need to use it to build. We don't want to break their build process. And what the status quote. Okay. Let's, let's maintain the status quo by continuing Java eight updates. Until Java reaches end of life, Java eight reaches end of life. In October, 2026. Open JDK will stop delivering versions. The other is if there were to come a time when Java eight updates became just too painful for the info team, they could tell us and we'd drop it then. So if this is just for tooling and just on Jenkins infrastructure, Jenkins still does not support job eight and will continue to not support Java eight. Okay. Yeah. Any concerns on any of those. Yeah. I mean, I'm wondering about. Any plugin that by. What two and a half years from now or something is still using Java eight. Yeah. Yeah. Yeah. Good question. So the plugin health score. Actually sees that already today. So if we were to look at the plugin health score. We can, we let's search for what should we search for? How about it? We'll search for plugins related to get. And here we see. A plugin called get parameter with a relatively lower health score. See if I can find one even worse. How about. Get hub organization folder. This is a good one because it's also a deprecated plugin. Okay. So we see here that on its score. It's got. What are some of its negatives? It's got. Oh yes. Here you go. Jenkins version. 1.642.3. That tells us. It's Java eight based. And so it's already being scored down. It's already having its plugin health score. Decreased because it's using Java eight. Yep. And then the other things that are diminishing its score here are part of the fact that it's, it's just not maintained. And this one is not maintained because it's deprecated. Okay. So if we were to look at its page on the plugin site. You see this big deprecated bar at the top. Yeah. So did that answer your question, Meg? Yes. Nice. Nice. Okay. So plugin. I'm thoroughly, I'm really thrilled with plugin health score. It is a very nice addition that Adrian has done for us. Yeah. If I don't look at anything other than the health score. But I see that, you know, those lower numbers, I might want to think twice as, you know, to have all this mealy mouth look and see if anybody's maintaining it. Right. Right. Exactly. And so what we've done is we've, he has codified. Checks to see those things that we used to say, please check to see if there's a maintainer. Please check to see if there are a bunch of bugs reported against it. Please check all those things. And when you, when you go to the health score, it will tell you these. Oh yeah, there's a reason it got a 44 out of a hundred. Yeah. So, or, or, okay, there's a reason why this one got a 98 out of a hundred. Right.  Here are the things that are aren't as good, but didn't diminish its score. Yeah. Good. Okay. Anything else on the Java story. Good work. Good work. Okay. Last topic on the agenda was DevOps world tour. I am pleased to announce that I am speaking. Mark is speaking in New York. And in Chicago. And what is Mark speaking about? The top topic that was approved is. Let's see how I got to remember the exact title. I just was, was creating the slides. So it should be right on my mind. So I'm going to talk about business benefits of open source contribution. And so I'm going to talk to people about why their business will do better if they will intentionally choose to contribute to open source. Oh, nice. Yeah, it's a, it's a fun sort of controversial really. You're telling me I can, I can improve my business by giving things away. And the answer is absolutely selectively giving things away can really improve your business. And I'll talk some, some reasons why, et cetera. I mean, it's a, it includes several stories from my life of highlighting, oh, here's why we did this. And it was specifically because it was benefiting the business. And here's why we did this. So it's. It's got some of Mark weight is old enough. Mark weight is experienced enough to remember some things. Okay. Any other topics for, oh, one, one last topic. I'm out the week of August 14th. Are you okay? If I just cancel this meeting the 18th, or do you want me to see if somebody else could, could run it? I'm good. I'm good. It's cancellation. Yeah. Okay. Consider the meeting. Not the same without you. Yeah. Anything else for today? Nope. Nope. We have some testing to do in the next 12 hours. Yeah. So I've got lots to do. All right. Thanks everybody. Take care. Thanks.


Okay. Hi everyone. My name is Monica Granados. I am one of the inaugural fellows of the reproducible research fellowship from the frictionless data program as that is part of the Open Knowledge Foundation. I'm also a policy analyst for the government of Canada as well as serving on the leadership team of Pre-Review. Lily, would you like to introduce yourself? Hi everyone. I'm also a fellow with Monica and I'm a marine science PhD student at UC Santa Barbara in California and I study how coral reefs and coastal communities are affected by global environmental change and I see research reproducibility and open data science as a tool for helping us to speed up the ability of scientists to improve resilience in these systems and understand issues faster. Great. Thanks Lily. So the two of us are frictionless fellows and we wanted to tell you a little bit about what our experience was like as part of the inaugural cohort and tell you a little bit about two really important tools that we learned about during this fellowship and how we've applied it in our own work. So when we do science, like Lily and I, we do a lot of data collection. So I'm a trained food web ecologist. I go out and collect data on crayfish. Lily has collected some data on the octopus trade and that data gets put into some form of data entry. So at least in the ecological field a lot of us just use spreadsheets like excel that output CSV files. When we start to talk about our data, whether it's in a publication or maybe we put out a tweet about it, we might get a lot of interest about the data. You know, people will say, well, I'd like to use your data or part of your data would make a great addition to a meta analysis that we're doing. Okay, so we get people who are interested in our data. How can we share that data? So there's been many ways that we can share the data and ways that we've shared data in sort of the history of science and scientific publishing. We could, you know, you could send it by carrier pigeon or by snail mail or by the pony express or by computer email.  And that's because a lot of the data that you have if there's sort of like innate parts that you understand yourself, but that might may not necessarily mean that others are going to understand that data. So when they open that CSV file or that spreadsheet, there's going to be columns that you don't understand or blanks that you don't understand, or sometimes the NAs or Na slash A or, you know, hashtag 99 has been one of my favorites. And it leads to, you know, a lot of confusion and frustration. So what if we could make it easier to share data? What if we can make it easier to give the information that we've collected, and instead of just sending an SESV files, that we put some context into this data? So that's what we learned through the reusable research program. We did a series of journal clubs and seminars and blogs, and we learned about two important tools that are part of the frictionless data program, data packages, and data validation. So we're going to give you a little sneak peek into data packages and data validation. And then at the end of the presentation, we'll give you a link for you to learn more about these tools and how you can implement them in your own research workflow. So starting with data packages. Okay, so what are data packages? I felt that as someone who is, you know, pretty committed to the open science movement, I was doing a really good job of making my data available. So my data for a particular manuscript that I published last year is all available, the codes available, as well as the CSV files where the raw data is in. And so you could go to GitHub and grab that information.  But the truth of the matter is if you don't really have any information about the column headings, you're not going to know what anything means. You don't know about units, you don't know how I collected that data. And so through the program, we learned about data packages. And it's I'm going to I'm going to tell you a little bit about the web tool. So if you go to the data package creator, the URL is at the bottom of the screen there on the bottom right, what you can do is upload your raw data. So you can upload either the CSV file, or you can upload the resource path. So I can actually take the data that was already in my GitHub, upload it. And then what's really neat about this tool is that it lets me give context to all of my columns, basically. So all of that information that I have. So I've got some column headings that are day, trophic, species, mesocosm, that may not mean a lot to you if you just open that CSV file. But through the data package creator, I can give you some context, and then make it easier for you to take that data and then apply it in ways that you may may find useful. So here, it's just a screen cap of once you load the path of where your resource is, it'll find your columns. And then you can give information in the title descriptor, and then give information about the data type. So all of this is using information to generate a schema, a table schema, basically some information about how the data is structured and information about the data itself. So I can add information about, so what did you mean by experimental day, or by day? Oh, it's the experimental day. And then I can give information about how long that experiment ran, for example. And then I can tell you information about the data, the datum itself. So what this does is once you've inputted all of that information, you can then download the data package as a JSON file and send the JSON file to your collaborators or to any interested party instead of just a CSV file with no context. You can then also receive other JSON packages and then upload them here on the data package creator. And you can see all the information that your collaborator has provided about the resource or about the data. Now there are other ways that you can use the data, like to use data packages in a more reproducible workflow. So you can use Python in our libraries that have been built around this as well. But I just wanted to give you a little taste of the power of sharing your data as a data package. I'm now going to turn it over to Lily. She's going to tell us a little bit about GoodTables. Hi everyone. So GoodTables is the second reproducible data science tool offered by the Frictionless Data Program. The tool was developed specifically to help with data validation and it's available both as a web tool and then through the command line. So let's walk through the web tool version and try to validate Monica's crayfish algae and snail data frame. So first we have to navigate to the Try GoodTables web browser. So let's say you are using just the raw data and you can do this step before you create your data package or if you don't have a schema which is made with the data package this is still a great tool just to check for structural errors of the data frame itself. The way you do this is you upload your data and check to see if there's structural errors such as missing entries. You can either upload your file from your local directory or you can insert the URL where your data is stored. For example up there we can add Monica's raw version of her GitHub data and then you hit that button that's in gray right now that says validate and then if there are no structural errors in your data frame you'll get a pop-up that says valid table but let's say that oh but here in this example we see that there wasn't there's actually one error structural error that we found content error that we found which is that the density column variable we had it marked in the schema file as a numeric or as the integer variable when actually it's a numeric variable. So I'm going to go back to that schema slide part of the data package creator JSON file that you make with that includes the schema so you have to make sure that you pull out that part of the JSON file and so a schema makes it possible to run a more precise validation check on your data so you're not just looking at the structural level but also at the content level. So then you just copy this part of the JSON file which is the schema and you have to make sure that you include the curly brackets. That's the problem I always accidentally run into. So then you go back to the good tables web browser and you insert the schema and then you hit validate and that's where you will be able to validate the content as we showed before and so in order to fix that error that we saw on the density variable column you can either make a change in the data package tool or you can change the JSON file directly and then after you update the JSON file and you reupload it on the good tables web tool and hit validate you should get a notice saying that everything is valid. Yeah and then so I guess we just wanted to end by saying that this is a short introduction for these different tools and if you want to learn more about them we're hosting a 90-minute hands-on workshop on May 20th and we'd love to see you all there and then the Open Knowledge Foundation is also accepting applications for their next cohort of frictionless data reproducible research fellows. So if you're an early career researcher and interested in applying we would highly recommend it and would love to talk with you about that more. Great. Oh go ahead sorry didn't want to catch up. No I'm just gonna say no thanks so much thanks so much Lily and yeah you can look at those the top URL is the where you could actually follow the syllabus of the data package and data in the schema you can learn a little bit more about frictionless data yeah and at the bottom you can you can learn a little bit more about what the fellowship is like and how to apply for the next round. Great yeah I just there was a lot of comments and questions in the chat about how this all fits together and it works and I know there'll be a lot of questions over in Slack for sure. I just Vicki actually just put a question in or a comment into the chat that I was I had in my mind as well which is it'll be really great if we can mandate this type of analysis or or review of tabular data before it goes into repositories. A lot of data repositories are full of tabular data that are missing columns or poorly documented and I didn't know if there were any discussions that you've had with data repositories around integrations on ingest or QA for in that sense. Yeah I we haven't asked the fellows but I can actually tell you a little bit about some of the work that I've done through my my like day job that is you know we deal with a lot of data environment and climate change and we actually did a hackathon to see if we could have someone build in like a checks that has like data got fed into a repository they would check to see at least for some really basic things like you know like empty cells or you know like characters and so you know even in like a weekend hackathon they were able to the students who were working on that were able to come up with something so it is certainly something that big organizations care about and would like to see happen and so that at least and that the researcher isn't necessarily the one that's doing it but that at least there's some kind of process to ensure that that actually does those checks do do happen. Yeah definitely yeah I agree. So another question was what advice do you have for scientists that are trying to integrate these tools into their workflows for the first time? So some advice that you'd have for the science scientist community? Yeah I think definitely there's a lot of video tutorials on that link that Monica shared and then coming to the workshop where we're actually going to work through it all together and I think both of those would be really great. Yeah okay great well thank you both we have a lot of the questions here we will move over to Slack people can interact with you there and we appreciate you walking us through it. I had seen a presentation about frictionless data when it first was getting launched and it's very slick you've come so far seems like it's really you know hitting a lot of the original promise so congratulations.  Yeah great okay. Thanks for joining everyone thank you.