It's one o'clock on the east coast, so welcome to the future of democracy, a show about the trends, ideas, and disruptions changing the face of our democracy. I'm John Sands, Director of Learning and Impact at Knight Foundation. We've just come through a year that tested the fabric of our democracy, the COVID-19 pandemic, the rise of a movement for racial justice, and a polarizing national election have further exposed deep rifts in our society that are prompting national soul searching. Can self-governance survive in a world where political alliances and economies have been remade by networked information technologies, disease? How do we begin to find new common ground? Our guest today believes it starts with a renewed focus on the need for authentic conversation in self-governing communities and our society. She recently wrote, if the American experiment is to succeed, we must improve the quality of our conversations. Emily Chamley Wright is the president and CEO of the Institute for Humane Studies, where Knight is a proud supporter of the discourse initiative. Her expertise covers a wide variety of, a wide range of territory from liberal education and economic development to post-disaster recovery and campus-free speech. From 2012 to 2016, she served as provost and dean at Washington College, and prior to that, she was a professor at Beloit College. Emily, it's so good to have you with us. Good to see you. It's great to see you, John. Thanks for having me on. Thanks. Before we dive in, I want to invite our viewers to be part of the conversation. Please feel free to send us your questions using the Q&A function Zoom, or using hashtag Night Live on Twitter, or just leave a comment if you're watching on Facebook or YouTube. Emily, so let's get the ball rolling. I think we want to have just, you know, a kind of natural, authentic conversation. So I think it'd be helpful for our audience to learn a little bit more about the work that the Institute for Humane Studies does. So why don't you just give us maybe a little bit of an overview about IHS and some of the work? Absolutely. Happy to. At the Institute for Humane Studies, we work with scholars across the country who are interested in exploring the big ideas that underlie the good society, the society that is a tolerant and pluralistic society where individuals and communities thrive. What are the ideas that underlie that kind of society? And there are scholars across the country who dedicate their careers and dedicate their scholarly lives to addressing those questions and the tensions that are presented in liberal democracies. And how do we preserve liberal democracies and strengthen them? And those are the kinds of questions that our scholars dive into. Talk a little bit more about who these scholars are. Are they resident scholars? Do they come from different institutions? Is IHS kind of a, I guess I'm trying to get a sense of who makes up the Institute? Yep. So we have a team that is based at George Mason University. We are at the Arlington campus of George Mason. But we work with scholars across the country and we don't take them out of their environments. We leave them right where they are because that's where they're doing their best work is with their colleagues doing leading edge research, but also teaching students, which is an important part of their role as well. And so we work with those scholars by supporting them through grant making, but also by convening them. That's the most important thing that we do is we gather scholars together for periods of long weekends to dive into original texts, for example, or to explore a research area that might be new to them or they may be experts in and they want to share their ideas and their research with other scholars. But those convenings, those opportunities to connect in seminar and research workshop kinds of settings is really the heartbeat of our organization because it's there that we cultivate a thriving intellectual community that is subjecting their ideas to challenge and challenging other ideas and building on each other's ideas as well. So it sounds like you pull people together for a conversation. Right, exactly. That's what we do is we pull together people for conversations, both in-person conversations and written conversations. And you mentioned the discourse initiative. That's a major initiative where our work is informed by the classical liberal tradition We also work with scholars across the ideological spectrum, though, because we recognize that if we are going to really dive deep into those ideas and fortify the ideas that underlie a society that is both free and tolerant and pluralistic and recognizes everyone that we are one another's dignified equals, that kind of society needs intellectual support and no single group can provide all of that support. We want to make sure that we're connecting with scholars who are left of center, right of center, classical liberals who are excited about those ideas and fortifying those ideas and that's a big part of what the discourse initiative is all about. What does it mean to be a classical liberal? So it comes from a tradition that it's what liberalism used to be called, which is an emphasis on I think of the work of Adam Smith as being important where his insight was the liberal plan, the liberal society was one where there was a great deal of individual liberty, equality, and justice. And so that that recipe, that that is a liberal recipe of equality, liberty, and justice. And if you have those elements, that is that also then informed of the founding of the United States, of course, the Declaration of Independence is a kind of classical liberal text. And so those are the ideas that we explore at a deeper level. And also, how do we apply those ideas in a context where you mentioned the challenges that we're facing in 2020 and into this current year? How do we flex those ideas so that we can also be a part of addressing the challenges with respect to racial injustice, with respect to the unfinished liberal project, you know, liberal democracy, I think of liberalism as our compass, the founding ideas as being sort of a compass, but it's not a finished project. And so this is a living intellectual community, precisely because there are unfinished elements of the enterprise and of the vision. Talk a little bit more about this unfinished project because I think I wanted to ask a question about before you described it that way, I wanted to ask about whether you see any, whether the past year has exposed any kind of shortcomings of the classical liberal project. But I guess framing it more as unfinished work is more generative for conversation. So let's take that tack. How is the project unfinished? Where are some areas where you think there's work to be done? One of the things that happens in any kind of intellectual tradition is there'll be some moments when certain themes get emphasized at the expense of others. So I think of, for example, as I moved into my role as a provost at Washington College, that was in 2012. It was right when free speech on campus initiatives were, those issues were really starting to bubble up and to a fever pitch in some cases. And what seemed to me was happening was that people on all sides, most of, most people, not all, but most people actually did just want to have improved conversations, they wanted to have better conversations. But they were getting themselves wrapped around the axle by making it all about First Amendment freedoms. Now, everybody at night and everybody at IHS knows the importance and respects the importance of First Amendment freedoms. But that's just the starting point for good conversations. That's just the starting point which allows us to be in a self-governing community. And so that's the kind of thing I mean when it's an unfinished project is new challenges emerge in a complex society every day. And so how do we, or old challenges surface every day? So how do we go back to basics, start to think again about how is it that we can develop not just the formal mechanisms of free speech, for example, but those informal sensibilities that lend themselves to productive conversations in which we all feel smarter after having those conversations? So you wrote a piece recently that basically lays out a few design principles for a good conversation. And maybe before we dive into some of the individual ones, because there are some that I really latched onto, maybe be helpful if you give us kind of an overview of these design principles that you can come up with. Sure, sure. I think this is certainly not an exhaustive list. It's just really I'm hoping to start a conversation so other people can weigh in as well. But some things to start up. First of all, intellectual freedom is essential that if people are afraid that they're going to be imprisoned for what they say, you can't have good conversations. So that's sort of a baseline constitutional principle of what's needed for a good conversation. But beyond that, there are less formal rules that inspire good conversations, like for example, that for us to be in a conversation that's meaningful, you and I have to respect the personhood in one another, that you have dignity and I have dignity. You may have a lot more experience and you do on a lot of topics, John, but you also respect that I have standing in the conversation. And so similarly, other principles follow from that, that we should enter into the conversation with a spirit of humility, with the assumption of good faith. We have to have respect for the importance of critical reason. But also, even as we're listening for one another's reason to argument and basis and evidence, that we are willing to listen sympathetically to, that even if I can find fissures in the evidence that you're putting forward, I'm willing to set that aside long enough so I can hear what's behind, what's driving your intellectual project, what's driving your point of view that you're coming into that conversation with, and me being willing to have some, maybe being willing to listen generously to that point of view so that I can come to understand how it is that you are looking at the same world I'm looking at and maybe even at the same evidence and we're walking away with different conclusions. How is it that two reasonable, thoughtful people can come to different conclusions after looking at the same world? That takes a certain kind of not only intellectual but also emotional posture when we enter into conversations, and that's what I mean by informal sensibilities that are required for good conversations. You've hit a chord, I think, with this idea of us entering into a conversation looking at the same world and operating from a shared fact base, I guess. It strikes me that the last year has really heightened this sense of epistemological rupture, that they're in this incredibly polarized environment that is the people's approaches to fundamental questions about our democracy, about our communities. We're not actually starting from the same place anymore, and that technology is playing some role in exacerbating this epistemological schism that I certainly can see in the work that many of our grantees do, but that we see just in the newspaper every day that we see and the differences between how one media outlet covers the same story versus another. Those kinds of issues seem to be exacerbated and more visible than they have been in the past. I'm curious about your take on that and how we reclaim, I guess, something of a shared epistemology. Yeah, there's two parts to this, and I think there are two parts that are somewhat in tension with each other. First of all, I'm an economist, so I love the marketplace of ideas metaphor, and I like to dive deep into that metaphor sometimes, perhaps too much. But if we're in a marketplace of ideas, we have to be fair dealers. The reason why we have trust when we're in the marketplace is because our presumption is that people are going to be dealing with us honestly. The same holds true for conversations. Our markets would break down if we didn't have that basic baseline of trust. Similarly, we have to enter into and presume that others are entering into the conversation with the intent of being fair dealers. That means a commitment to honesty. That means a willingness to back away from a position. If you've been shown that that position is flawed in some way, either through a fracture of logic or the evidence doesn't hold up, we have to be willing to back away from our positions. At least long enough to say, well, I'll need to think about that some more. That's one piece of it. That respect for critical reason is absolutely a part of what we need if we're going to have good conversations. With that said, we can also abuse that language of reason. We can abuse the language of, well, it's all about the facts. Oftentimes, when someone says it's all about the facts, if they import into that to say, and therefore, the facts are very, very clear about what we should do next, that may not be true. There might be scientific grounding for a truth claim. But what we do next with that is not always necessarily obvious. And there may be trade-offs, for example, that hit different people in different ways. And thinking about public health concerns around how we manage COVID is a great example of how we can have a shared commitment to truth seeking about what the science tells us. But what the trade-offs are with respect to public policy around what we do next, that's an area where we can't just simply claim, well, the scientific authority is the only authority in that. There might be some lived experience on the ground that informs how different public policies play out in different communities that we need to be listening to. And so that's the other half of it, is that the world is a complicated place. And we have to enter into any conversation that's complex with an understanding that we've got a lot to learn from one another, that you're seeing the world from a very specific perspective, and I'm seeing the world from a different perspective, and we need each other if we're going to actually be collaborators in this truth-seeking enterprise. I was thinking just as you said that this is the underlying premise of Plato's dialogues that we only learn how we actually think about something in conversation with somebody else, that it's a process of refinement of, you may come into a conversation with a set of priors that's going to guide your understanding of the facts or the particular vision you bring to the facts, but that having an interlocutor, having somebody to bounce ideas back and forth with, and to hear some of the shortcomings of your own approach to things. And that's one of the real traps with people who love to think. Those of us who love to think, we think hard about our positions and we subject them to scrutiny even before we bring them out into the public oftentimes, and that's valuable, that's a good thing, but what that also means is that sometimes we can enter into a conversation with a very, very strong point of view. Again, not a bad thing, but it means that we're emphasizing some muscles rather than other muscles.  So it's a similar sort of thing that if you're really good at thinking through a problem to the point where you've overcome every objection that you possibly can, sometimes that disables you as a good conversation partner because you forget how to ask a good question. You forget how to say, okay, I'm now entering the conversation with John here, and I know that he disagrees with me, and I'm going to enter in ready to volley back every single one of his objections because I thought them through. And that might be a way for us to get at truth. That might be a very, very good exercise for us to do. We should also try it out. I should also try it out so that I stop myself short of that and I say, I know that John has these objections. Let me go in by asking questions that can help me understand why he has those objections. Help me understand what's informing those objections rather than coming ready to bear with the volleying back. Instead, I just want to try to find that way of finding the question so that I'm tapping the knowledge that has been informing your challenges and your perspective. That's a very different set of muscles, right, of intellectual muscles that we need to learn how to flex appropriately even as we're sharpening our own intellectual arguments in our own heads. So we've got about 10 more minutes and I want to save time for three things. One, I'd like to talk a little bit about the role that technology has taken in mediating our conversations over the past year. I'd like also to be able to spend a little bit of time talking about the changes that are happening on the ground in real communities and how that's impacting our ability to have substantive conversations. And I'd also like to find some time for some of the audience questions that are coming in. Let's start with technology. The last year for me has been particularly challenging because I feel like the bulk of the work I do moves forward through in-person interactions with people, meeting with grantees, meeting with folks who have great ideas, talking about those ideas in real time. And as a result it's been kind of a challenge for me to just personally to move the work forward. I'm curious to know what you make of the way that technology, we're now having a conversation mediated by who knows how many digital and intermediaries right now. I'm curious to know what you make of the shift in how technology has been mediating our conversations and what you think the future holds. Are we going to, is this model going to be with us for the foreseeable future? Yeah, I think that there are both dangers and opportunities with technology with respect to how we speak with each other and how we interact with each other. It was at a Knight Foundation function that I learned that there are malicious bots through AI that are designed to corrode social trust. Well, that's a terrifying prospect and people don't even know that it's a bot, right? You know, that's a terrifying prospect. But it also raises the challenges. The question can technology be aimed in the exact opposite direction too? So we can deliberately use technology to open up those spaces. There's been the emergence of online platforms like Clubhouse is I think a really cool experiment where we're using technology to use people's real humans engaging in real conversation with real voices with their names attached. And this is a kind of big social experiment to see if we can rebuild social trust with the mechanisms of technology. So I'm a half glass full kind of person. I tend to see that in moments of disruption, the human ability to sit to worry about that disruption and then say, what are the potential solutions? I don't know what all those solutions will be, but I do tend to have a lot of faith in human ingenuity to people care about this kind of problem. And that disruption is the source of new technologies and new solutions that we might not have thought of before because we didn't need to think about it before. So I'm mostly pro technology, even though I think that we need to have eyes wide open about some of the very real dangers out there. Yep. I'd also be interested in your reaction to this piece that I saw in yesterday's New York Times, which to me suggests that the physical conditions for conversation, at the same time that the technological possibilities for conversation are increasing, the physical conditions for real conversations are actually diminishing within our communities. This story said that it's not just that many voters live in neighborhoods with few members of the opposite party.  So this piece is based on some research by Harvard scholars, Jacob Brown and Ryan. So I'm curious to know what you make of the fact that we seem to be moving while technology is creating a kind of playing field for us all to be together. In reality, the reality on the ground is actually quite a bit different. And we seem to be moving more and more into siloed communities based on partisan data. The research is fascinating that you describe and that the article covers really well. And I'm not the expert in this field. I would love to have Brown and the conversation with this first question I would ask them is, is this really new? In other words, the technology allows us, the data technology allows us to map the neighborhood level. We can see these clusters of blue and red and that we didn't see before. And my question is, is it new or is it that the technology is allowing us to see something that was probably pretty much always there anyway? And the thing that the reason why my head goes in that direction is because I think say ethno-linguistic religious community clustering that we've known about forever, class clustering we've known about forever. So is what we're seeing here really just more a proxy for class sorting that we've seen across neighborhoods that probably feel much more familiar. But in another sense, it doesn't matter. It's still interesting for us to know that this is a reality on the ground. To me, it points to the tensions between what we want in terms of a healthy pluralistic society and also freedom of association. When you have freedom of association, one of the things we're going to do is we're going to cluster with people who make us feel comfortable. I think that's probably really important for people who spend particularly members of minority groups that are in a community, a work community all day where they're dealing with what we might describe as the dominant culture all day. It might feel really nice to be able to retreat back to the neighborhood and kind of take your hair down and feel like, wow, I can kind of just sort of be myself, have the same vernacular, have the same go-to cultural references, joke about the same stuff. So that's part of what it means to be able to have freedom of association is to live intentionally in this way. It only becomes problematic if I am living and working and congregating and all of my civil society interactions are always with the same cluster. I think that's particularly dangerous if you are a part of the dominant society because then you think of your experience as being everybody else's experience and in fact it's not, right? That there's a lot more nuance out there. And I think that that's also then where we get the polarization is people start talking as if their experience is everyone's experience and it hits the wrong note, it hits the wrong chord with others who say, well, that might be your reality, but it's not my reality. And the lack of trust that is seated in that kind, when that conversation goes wrong instead of actually bringing us together because we have lots of opportunities to connect and to educate one another about our lived realities, instead it ends up being more polarizing and we end up spinning society out towards the polls rather than kind of coalescing to recognize that there's some shared experiences and there's some things that we're going to be agreeing to disagree about. If we don't have any opportunity to have conversation that's where we should start to worry about the phenomenon that's described by Brown and Nino. That's a great point. So a couple of comments have come in in the chat and I'm curious about your reaction to one of them which is that someone has taken issue with I guess a characterization that we had and it notes that most citizens aren't at all interested in truth-seeking exercise. To the contrary, Americans are far more interested in emotional stimulation and thoughtless entertainment. Indeed, that's a fair description of today's electoral and social politics. What do you make of that? Do you really feel like we've moved to a point where Americans are no longer interested in the mechanisms that are required for self-governance? Truth-seeking would be the biggie for me. Yeah, I appreciate the challenge. I think the challenge is a good one. If what our barometer is is what we see on social media, I completely understand why that's the takeaway because it looks because there are mechanisms on social media that don't reward truth. They don't reward someone. If you post something and my mind is changed by it, oftentimes that doesn't seem to be the currency of what elevates your status on social media. It's more that you have more people who already agreed with you and you just found new words for them to have sharper, more powerful ammo. That is a problem and I do see that that is part of what's spinning out our conversations towards the polls and that is a problem. Let us remind ourselves, of all of the conversations that happen at the dinner table. All of the conversations that happen where we can hopefully once again happen, have unmasked conversations across the fence posts with our neighbors or on our patios over a glass of wine or a beer and talking about life in the world and not everything is about politics either. We engage in persuasive activity really more often than we do anything else. We're constantly engaged in persuasive activity. I love Dierdre Burkowski's work on this. She's an economist who writes about the liberal project but one of the things that she writes about is how so much of our commercial lives, so much of our work lives, so much of our family lives is really all about persuasion. It's all about sweet talk and sometimes we're in the mode of persuasion as an as an academic exercise but a lot of times it's nudging our colleagues or family members to see the world a little bit more from our vantage point and to see what they might discover there. If we start to look across all of the academy but also civil society and what happens in families and in neighborhoods and in workplaces so much of our work is about truth-seeking small tea truth. It's about I think that what our client base needs is this and someone else says I don't know I think it's that. That's still a truth-seeking enterprise even if it's a very casual conversation even if it's just battering across you know the back and forth that we the banter back and forth around you know what a good television show looks like with our neighbors. That's still kind of a because I think we're trying to get at the meaning of that television show and so I actually am more bullish on Americans being truth-seeking animals. We just have to make sure that we're looking for it in all the right places. Emily this has been a terrific conversation thank you so much for joining us. Thank you John. Yeah and I hope you'll come back and maybe we maybe we can do a clubhouse chat at some point. Yeah all right thanks very much everybody for joining tune in next week on hashtag night live for another deep dive into the dynamics of our cities on coast to coast. The night foundation show that explores building engaged communities in a time of rapid change as a reminder this episode will be up on the website later you can see this episode in any episode on demand at kf.org slash fd show you can also subscribe to the future of democracy podcast on apple google spotify or wherever you get your podcasts feel free to email us at the show fd show at kf.org if you have any questions and to send us home to miami songwriter nick county follow him on spotify thanks for joining have a good week


Thank you for coming to hear us talk about Bodhi today. And I'm Randy Barlow. This is Pierre-Yves Chibon. And Pingu, he doesn't like to use his real name. I'm Bola Vakesa, if you know RSC. And we're going to talk a little bit about what Bodhi is, although I see a lot of familiar people who I think probably know what Bodhi is, but just in case. I'm going to tell you a bit about the recent history, just sort of what's been going on lately in Bodhi. And I'm going to tell you about our immediate future plans leading up to Fedora 27. And then I'm going to hand over to Pingu, who will tell us a bit about a really cool idea he has for automating the packaging side of Bodhi to make all of your lives easier. So if you're not familiar with Bodhi, it is a tool that really has two primary users. The number one user of Bodhi would be Packagers. And hopefully, most people in this room are Packagers.  And everything goes well. You can submit your update to Bodhi. And Bodhi makes it easy for your users to give you feedback before the update goes out to the wild. So it gives the ability for people to try your package and report back, whether it worked or it didn't work. And they can say, leave a comment for you. And they can upvote and downvote. The other major user of Bodhi, however, is Release Engineering. And I think that's something that a lot of people may not realize, that there's this whole back end side to Bodhi that it's meant for the release engineers to use. And this tool creates, it's called the masher. And it creates the repositories that your system's all subscribed to and pull the updates down. And that's a major sort of behind the scenes piece of Bodhi, where we've been doing a lot of work lately. So I'm going to talk a little bit about that as well as we go through. So we're going to talk a little bit about the recent history of Bodhi to begin. So I am new around here. I'm not new to Red Hat. I've been at Red Hat for about four and a half years. I worked on the satellite product for a long time. And specifically, I focused on PUL, which is the component of satellite that distributes packages to satellite users. In June of last summer, I joined the Fedora team, which was an amazing opportunity because I've always been quite passionate about open source software and up streams and being involved in Fedora. And actually, I had been a Fedora contributor for a while. So working full time on Fedora was sort of a dream come true for me. And so I joined in the summer and I started making a few patches here and there and various pieces of our infrastructure. And one of the things I made a few patches for was Bodhi. And many of you may know Luke Macon, who was the Bodhi, he created Bodhi. Unfortunately, he moved on. And so when he sort of left Bodhi vacated, let's say, I was asked to, because I'd made some commitments, they were like, hey, Randy, you made some commitments on Bodhi. Why don't you work on Bodhi? And I was like, OK, it's on school. You own it now. Yeah, I touched it. I own it now, and Matthew said. So I own it now. And so I started looking around and trying to focus on some things. And I started talking with the release engineering team, the Fedora release engineering team, because I wanted to find out what are some challenges? What are you guys doing? What's the problems? And I heard a lot of feedback from them. And one of the biggest problems was the masher has a lot of stability issues. So I started immediately to start trying to analyze this and figure out what's going on there. And that was a very big piece of code that is difficult to test. So this is an interesting piece to work on. And so I made some commits. And then I started looking around and I realized that Bodhi had not been released for a pretty long time. I think the most recent release had been in February a year ago, almost a year ago. And so I said, we should release Bodhi. It's had a lot of commits since then. And so on one day in October, I think it was, I made Bodhi 2.2.0, which was a snapshot of the development branch. And I deployed it to production and everything broke. Yeah. That is true as well. We had migrated. The Bodhi back-end masher had been on REL7. And we migrated it to Fedora 24 at that time. That's right, to get rich and weak dependencies in the metadata because the, which piece does that? New RPM? Yeah. So for the recording, we wanted to use Fedora 24 for some newer dependencies so that we could get the rich and weak dependencies into our repo metadata. But the stability issues that resulted that day were difficult. And I think I worked 16-hour days for four or five days in a row because there are so many things that happened. And I think there are some lessons learned because after I finally got to sleep and things were mostly working again, I got to sit down and kind of analyze what happened. Why did 2.2.0 blow up production so much? And one of the things that's a lesson learned is it seems that there had been a lot of hot fixes placed into production that had not been placed into our Git repository. So by releasing 2.2.0, I erased a lot of fixes because they weren't in our repository. And I had not been aware that this practice had been happening. So one lesson learned is put your patches in Git. We all like it. Another lesson learned, I think, is that going a long time between releases also means that you've got a lot of code that maybe you've tested on your development box and maybe you have some automated tests for, but you don't have, it's not been running in production. And this is how development works. But the longer you go, that diff gets larger and larger. And the chances that something you wrote that passes all your tests doesn't work in production grows. So another lesson learned is that we want to release more often. And in fact, in October, I think I made four releases in three weeks, but those are all bug fixes. So those are some of the issues that I encountered when I initially joined the team and took over the BODY project. Why don't I say takeover? Started to lead the BODY project, let's say. Since then, I've really been, again, focusing on testing and stability. I personally have not been working on new features yet because these mashing issues and production crashing issues, I want to make sure that it is solid before we go and start adding new things and create more chaos. So I've been really focusing on automated test coverage a lot. When I joined the project, we were around 73% test coverage. And I have a personal goal of I've been trying to raise 1% per month. So I've got it to 81% in three months, which is a lot more than 1% a month. And I'll put aside a note. Test coverage isn't necessarily a measure of test quality, but lack of test coverage is a statement about test quality. If you don't have test coverage at all, you know for sure you're not testing that code. But just having 100% test coverage does not mean your tests are good either. So just to be clear. What does that mean? Oh, a percent of lines of code that the tests touch. So we're measuring, we run our test suite, and we measure, I don't do this. There's a program I use. But it will keep track of did this line of code get executed at some point during the test suite. Now this doesn't mean I have any assertions about to do something correctly. But it does help with things like catching typos that might explode or cause an exception. So there's some value there. Quality assertions are very important. And I assure you that I've also been making reasonably good assertions as well. But you can't put numbers on that. So I'm just going to promise you that I did that. I don't have numbers on the mashing reliability, but I will make the bold claim that is subjectively more reliable than it had been before. Especially with the 2.2.0 release, the masher was very difficult to get working again. And I want to give credit to Patrick Altrovich. And I know I mispronounced his name and it's in a recording now. But if you don't know him, he is an amazing engineer and admin and debugger. His debugging skills are unbelievable. And he's really, really contributed a whole lot to the masher. So I don't want to claim, I've done a little bit there, but he's really done the lion's share of work in that area. And I was talking to a release engineer recently who told me that the masher does work better today than it did before. It still has a lot of issues. One of the current problems is RPMOS tree often causes it to crash. And then Dusty comes talking to me and asks for what's going on. And then I'm like, I don't know. So we still have some stability issues in our daily mash. So that's an area of focus. And Dusty's been doing a lot of work, I think, on tracking down those problems. And he's been really helpful to me. I'm trying to make the feedback. Yeah, for the recording, Dusty said we're making the feedback loops tighter. So he's really been focusing a lot on tracking down these issues and helping improve the quality there. Because this is very important for the near future. So one of the things, well, actually, I'll get to that in a second why that's important. Just trust me, we'll talk about that again. So now I want to talk about what we're going to be doing in the short term. And for the short term, I'm thinking the next few months. I still want to continue focusing on stability, raising that test coverage. I think 100% test coverage is a good goal. I do not plan to do that in two months. But over a period of years, I think that's an achievable goal. So I will continue writing tests, continue chasing down production problems. And as we do this, I think everybody release will be higher quality than before. And then we'll have more confidence as we introduce new features. And speaking of features, you've probably been to many talks in this conference about all the crazy new things that are happening in the Fedora space. And there's a lot of things that are really going to affect the Fedora infrastructure team. Introduction of containers. And we already do OS trees, but we don't gate them with Bodhi and Flatpaks. So with these new content types, we want to introduce the ability for users to test those like we do with RPMs. So you can see a new version of an HTTPD container and try it out and report back that it worked or it ate your data for some reason or you can't find your cat since you installed it. So that's going to be something that I think we're going to be focusing a lot in the next six months. By the way, feel free to ask questions throughout the talk. I meant to say this at the beginning. I'm open to questions at any point. So, you know. So actually when you were talking about that actually, I'm assuming it's running like it's a separate service or self-service? It is, yes. Is it running on the same VM or machine? No, it runs on a question. The question is, is the masher a separate process? Is it running on the same machine? So one thing that's awesome in the Fedora infrastructure is we have FedMessage. It's a message bus that we use to actually almost everything that happens in Fedora emits a FedMessage. This is how you get badges and all kinds of awesome things I really like badges, by the way. I'm obsessed with badges. In fact, the only reason I submitted a talk here is I want the badge. So the way that the masher works is there's a CLI tool that the release engineer will use. And they will say, I would like to mash Fedora 25 updates testing. And it will query the database for all the packages that have been pushed to stable basically, either through karma or through manual pushing. Then it will present a list of those packages to the release engineer for them to review. And the release engineers like to study this list to look for obvious mistakes. One example of that might be if they see a GCC update, but not a lib tool update, they don't want to release that. So after they hit yes, that emits a FedMessage with this huge list of packages, there's another process on a back end server that is called FedMessage Hub. And FedMessage Hub is a plug-in sort of system. So we have a Bodie plug-in that sits there. It receives this message and then starts the process and create the match. It runs the CLI. It actually runs its own instance of FedMessage that's isolated on the box and doesn't talk on the main FedMessage bus. So it's, well, it's separate. It's one thing. The front end, which is what you interact with, is one box that talks to DB and then there's the back end. Yeah. So Jinnah said the comment that the CLI tool is used on the same machine as the back end mashing. So that's another interesting detail. So you said you said you're going to focus on stability. When are you finally going to fix the workflow for auto-comedy sabers? There are two old bags that have been opened for months. And before that, it was already broken. There was a bag that was open for even more months. And it's still not working. And basically, it doesn't work at all if you disable auto-cama or you always have to wait for the time out. They cannot put anything. Yeah. So the question is about auto-cama. There are some issues where when auto-cama is disabled, there are several issues, actually. I've seen these. One of the biggest problems with booty, and we're going to talk about this on our last slide, is manpower. We don't have very many contributors working on booty. There are a few of us and not very many people that are full-time focused on booty. And the release engineering has been the biggest focus because if the release engineering is broken, we can't release any updates at all. So that's the highest priority issue. And that's what I've been putting my time into. Not that this issue is not important. It's very important. In fact, I think all of your issues are labeled high priority in GitHub. And that really is high. But we really need help. And we really would appreciate poor requests from anyone. Well, Pingu has also been asking me this question. It's just that we haven't migrated to Pagura yet. We do plan to do that. Two? So the remark for the video is that two, three years ago, Pagura was very new. Well, I'd just like to correct that two, three years ago, Pagura did not exist. Oh, really? Yeah. So I think it's just history. We want to do this. But again, we're manpower, right? That's a task. Someone's got to do it. And yeah. But yeah, we seriously are doing a lot of work. It's just there aren't very many of us. So I'm going to move on to talking about release engineering automation, which goes back to what I told Dusty I promised I would talk about the OSU stuff again. So one of the things that I think would be very interesting to do with Bodhi is to try to reduce the amount of time that release engineers have to spend with it. And I think that most of them would be happy to spend less time with Bodhi, especially given how much it used to crash in the past. And to some degree, it still crashes today. So Patrick Alterovich, who I have now pronounced twice, probably incorrectly, has done this amazing thing, where he has made this tool called RoboSignatory. And RoboSignatory signs all of your packages when you create a Bodhi update. So this is also Fed message driven. So when you create a Bodhi update now, a message is emitted. And RoboSignatory receives this message, and it goes and looks at your RPM build from Koji. It signs the package. And then it can go into the update and be pushed to updates testing. This is a very recent change. I think this happened in November or December. And before that, it was impossible to automate Bodhi because the release engineers used to go and sign all the packages because we didn't have RoboSignatory. So this enables us to consider automating everything about Bodhi because now we don't need a human to go and sign all these packages. So we started thinking about Bodhi push, which is that script that runs on the back end that you asked about. And the main thing that is blocking us here is that this is the stability issues. The RPMO is tree that Dusty's been working to stabilize is probably the number one issue we hit these days where the match will crash and we have to go look at the logs and figure out what happened. So I really appreciate Dusty, your efforts there because that's probably the number one thing. There are other issues as well, but I think that's something that we'll be focusing on in the coming year to try to free our release engineers to focus on tasks that they would probably rather be focusing on instead of focusing on our tracebacks. So that's a area of automation focus. I'm now going to hand this cool clicker over to Pingu, who's going to tell you about a very awesome idea that he had that he would like to present to you. So thank you, Randy. So one of the things that the Fedorange infrastructure team is meant to be is the place where we can actually research and develop on how to make your life as a contributor easier. We get to actually work on your crazy ideas that you don't have the time to work on and we also get to work on our crazy ideas to still make your life easier. So one of the ideas is how can we make the life of packages easier? And what are the tools around? So we should start by looking at what we want to do and now it's going on currently.  My work is done. And so basically I want to be able to go from this git directly to update testing and it doesn't, I don't do anything with it, it just happens.  Then you need to trigger the build in Koji and then you wait for the build to be finished and then you actually go to body and you create the new updates and then you wait and then for engine engineering, you pick it up and push it to update testing. It is possible to do the update from a common line but whether you actually click to go to body.rearproject.org or do Fed package updates, you still need to actually do it. So. The problem is you have to wait, you can't do everything at once. So Till just pointed out that's one of the issue in that process is that you basically need to wait. So you do a git push, you need to wait to trigger the build, you need to wait that the build is finished, you need to create the update and wait that this update gets created. And then, well, if we actually want to do auto pushing, basically, we actually want to have some testing in there. We want to make sure that the update that you just pushed is not going to break the entire repository. So we definitely need some testing and that's something which we already have in place these days, it's Taskotron. And so once we have our updates, body update created, once we have our test run, relaunch basically takes it up, mash push and since landing update testing. Well, we can actually do part of this automatically nowadays. So I'm going to introduce you about the fiddle build idea and then so that would be, you know, the big new, the new hotness number two. Then we have Taskotron, so that's already in place. We have unit tests and then we have the body part that Rondi already just spoke about that can actually already try to automate the push, try to make the relaunch life easier and try to spin things up a little bit. So what is fiddle build? So the idea is fiddle build is not to change your current workflow, but to make your life easier if you want to. I mean, if you like your life the way it is, I'm perfectly fine with it and you just keep on going the current way it is. So the way we introduce being this entirely opt-in and just on a volunteer basis, we introduce a new file in this git which is going to be named changelog.yaml. So it's a yaml file and it basically needs two informations, it's named the NEVR, so name epoch version release. So it needs to know basically which package you're building and which updates you're creating. We could actually drop the name part of it so it's still working progress, so we might change a little bit that. And then it needs a changelog. While you're going to complain, why does it need a changelog? I already have a changelog in my spec file, I already have a changelog in my git repository, why do I need yet another changelog? Well, this changelog is actually the one that you're going to expose to the people that are accessing the update in body, it's the part where you want to actually tell your tester, well, I've been updating these packages, it has this and this change, so this is what you need to test. This is the important piece, the fact that you update to 1.0 doesn't matter, what matters is that between 0.9 and 1.0, X, Y and Z were changed, so this is what we need to test. So. Can we change that to say something else? Matt and Sano are proposing that we change the changelog terminology, I'm definitely open for that. End user release notes or just release notes. We can backshare about the terminology afterwards, that's no problem. We can vote even if you need. And, but yeah, this is basically what we can. I've added a third field here, which is the update type, because body can support security updates, announcements updates, new package update. These are only, the two fields that are mandatory is the NEVR and the changelog. Everything else is going to default with whatever body defaults to. So if you don't specify the update type, it's going to be an announcement update because that's a default. You can actually also do, you can specify bugzilla tickets that to close, you can specify if you want the bugzilla tickets to be closed when the update is pushed. So pretty much all the fields that body exposes in the UI or in the, in Fed package updates, you will be able to fill in there. So we will need to document this a little bit. I could read this from a spec file. The idea is that I, so I don't want to read that from us. The first thing is that I don't want to read it from a spec file because I want to, I'd say, I don't, I don't want to, I don't want to change the way things work currently if you don't want to opt-in in FedoBuild. So basically I want a way of interacting with these gates and phone message and Koji and body in such a way that if you want to update a spec file built in Koji and then gates built and to push them as one updates, I'm thinking like the large GNOME update that we have once in a while because there is a new GNOME version. Well, when they do this process they probably don't want to use FedoBuild because FedoBuild does not support currently the possibility of putting multiple builds in one update. So I want this to be entirely opt-in which means that I need a key at the beginning of my YAML file that will be uniquely identified which release we are targeting. And the NVR there is also what is used to ask Koji was this build already done? Ask body was there already an update done for this one? Because of course if you update the changelog and the package was already built in Koji there is no point in doing it. If you update the changelog and there is already an update then there is no point in creating yet another update. Also because of the way RPM works you can't actually get the NVR out of the spec file without building the RPM and it might not come out the same way it does in the build system. It did build it on the system. So Matt also points out that RPM is designed in such a way that you can't really extract from the spec file the NVR because of macros, because of how it's... Basically you would need to actually get that from the RPM itself and you might have situations where an RPM built locally would have a different behavior or output than an RPM built on the build system. So you did mention that it does not support grouping both builds in a single update. Have you thought about how you would do it? You've been doing something or thinking about how you could do something like that internally that I built internally as well. Yeah, so the question is how do we... How would we support doing multiple builds in one update? I think the simplest way is probably to expand the NVR field here to include all the package that we want to get in that update and it's gonna be tricky one to support though but I think that's probably the easiest way to do that. Just do a space-separated list of builds you want and then it would combine eventually the different changelog or you just make one changelog for everyone and then when it's finished building all the packages it just creates the update. I'm not entirely sure, but that's basically my first thought on the questions. There are probably easier way or better way to do that but we'll see. So, and I'm not entirely selling you and wavy future that's going to be in a couple of years from now if there is some fairy dust and everything goes fine so it's actually currently a proof of concept. We actually have something and to show you that I'm not lying I'm actually going to do a demo. Well, wait, wait, wait. I'm actually going to show you a movie of the demo. There we go. So, as I said, it's a proof of concept and you can very nicely see it at the top here because it's asked for a fast username and fast password because it's currently uses basically... It was running on my laptop and it's basically uses my credentials to act. So what we do is we have a fed message consumer that just listened to the fed message bus. Here I'm on a certain git repository from Python are complete. I'm adding a change log file. I'm just showing you what's in there so we have the same structure as presented before and if you are updates, update type. I'm doing a git push. Well, git commit first because change log are important also in git. And that's ZSH, ZSH.  I'm waiting and oh, what happens here? So, fed message from project git receive so there was a git push. In that git push, there was a change log that channel change. So it's looking at the change log itself. It's checking that basically the mandatory keys are present. So it's looking if there isn't any VR and if there is a change log. So the YAML file is validated. And then it's basically calling Koji. Was there already a build for this one? It finds out that Koji say, well, there was no, this package wasn't built. So, okay, I'm going to build it. I'm now opening the page on Koji to show you that it's actually just triggered a build. And now it's like, okay, so what do I do? Because I need to keep you busy when it's, you know, when it's building and I have, it's a three minute video. So, you know, I need to fill up the blanks basically. I'm relating the page, it's still ongoing. What do I do? Oh, wait, I was actually working on an F25 branch. So maybe I can, you know, kick the build on the master branch. So I'm just going to the right branch. I merge my F25 change, I git push. And then the consumers, thank you. The consumer received the message, figures out that there was a change to the change log file, figures out it's a master branch. So it kicks the build in her hide. And what we see is that we have two builds now running in parallel with the same consumer. Do you get the target? So the question is how do I go from branch to target? Currently, I'm using the, basically though, so in the- Branch name, that's candidate. Yeah. I think it's currently accoded. I think it's currently accoded, especially for the master branch so that it goes to her hide. Proof of concept again. What branch name? And if it's a master to her hide, it works. So what it does? Actually for master, I'm actually going to packagedb. And I ask packagedb, what is the branch name? What is the Koji tag corresponding to that branch? So and I could do that for the other ones as well. Since packagedb has that info. That package makes an assumption that master equals her hide. Yeah, okay, that's also works. So just I wanted to pose it here because what happens here? We got another build state change basically from Koji. So it says that something changed in this build. And it's basically that it finished building the SRPM. But it's not exactly the message we're waiting for. We're waiting for the fact that the build finished. So we just, we recognize this as being one of our task but it's not done yet. So we just drop the, we just don't do anything. We just drop the message. And what we can see here is that indeed the first task is done. I'm going to go a little bit faster now because, yeah, well, the coffee is like after the git push so that you can go for coffee. I'm just babysitting the process here because, you know. It's out, it's like in the video. Yeah, yeah, but I was away. There could be two coffees and then you get rid of two different coffees. So what is it doing now? Is it playing or is that not playing? I don't know. I think that was near the end. So which, where are we? I think it actually did. Of course, demonstration effect. The video was working, but now the presentation is gone. When the terminal, that terminal? This one? It's too fast. Yeah. And go a little bit there again. Yep. I need to go back to where we were. Okay. So, we got our task. Let's go a little bit faster. We keep some building. We get the row here, the building, the row height also finished building the SRPM. So we got another message saying that there was something changed in the build. And we are recognizing it again that it was one of ours and we're still not doing anything with it. And let's go a little bit faster. We still need a, there we go. So we finally got the message saying that the build was finished and we recognized that this is one of ours. So we start processing it, which basically means sending the update to buddy. This is the debug mode. So we got the entire answer from buddy, the entire JSON, that body return when it finished the update. But what we see at the, there is an update was created at this URL. And the only thing which I miss in that video is that I actually didn't click on the URL or like click, but I stopped the recording just before. So you don't see it. But I mean, trust me, the update is present in buddy and it does work and it does is an announcement update and it does contain this build. And if you want to look for it, it's the Python art completes, which was already updated, I think, to 1.8.2. So I'm not selling you pixie dust. I'm actually selling you something that actually works. We need, there is some things that we need to do. It has a very small memory leak in the fact that if your builds fail, we don't remove the task ID from our list. So that we need to actually check that the task SD is not complete, but we need to check that if the task was conserved or failed, then we just stop watching for it because there is no point. It needs a readme file. So if you want to contribute to the project, just a readme file and then pull request would do. And we need to figure out a way of making that an actual service and not something that runs on my laptop. Adam. So you still have to update the spec files yourself. You still have to update the changelug to the changelug file yourself, and that's about it. But there is one thing that we are working on. It's making Pager being a front end for this git, which means that in a very soon future, we're going to have releasemonitoring.org figuring out there is a new update coming in. Then we have the new hotness that listens to releasemonitoring.org message and finds out that, hey, Python are complete as a new release and Python are complete is Python are complete in Fedora. And the version that is in Rohide is not the version that was released. So we can update that one. So it will update the spec file. It will open a pull request on Pager. And then we're going to have some CI integration here. That's what's going to be happy. And it's going to probably do something like kick off a scratch build in CodeG, see if it builds, runs a couple of tests, if it doesn't break the entire world, and then report on the pull request that, hey, this is building fine, this is not breaking the entire world. And you as a user are going to be able to merge that pull request. And if we do things properly in the new hotness, not only update the spec file, but also the changelog.jml, it means that it's going to kick off the build and the update in body. And well, it's not actually going to trigger the update in body since we're using a Rohide, but it's basically going to end up in a Rohide. So it still allows you to go for coffee, you know? So in the entire pipeline, it would make things quite a bit nicer. Dennis, how do we deal with the Lucoside Cache update? That is a good question. To which I do not have the answer of right now. Well, if we are going to allow, if we're going to allow FIDO build to actually kick off builds, we need to have a service that is going to do the uploads of the sources when we do the merge. Validating. Yeah, we will definitely need something to do that. We could ask the new hotness to at least update the source file, and then we need something to somehow retrieve the sources and upload them to the Lucoside Cache when the prerequisites match. Yeah. I mean, cool requests work really good for the patch to a package, but the new versions. Yeah, that is definitely a good thing. We need to think about it.  The question is to find the one that pleases all of us, or at least that this pleases the least number of people. The service, all the builds in Cache will show up and be run by this service. That service, yeah. Do you have any plans to somehow map those kind of people who kick off the build somehow? So the question here is, if FIDO build does all the build in Cache, how do people get badges? I actually asked that same question. And Roddy was really, really worried about that. I really like that. You can mess up my statistics. Yeah, that's also true. So one of the ways to exclude the FIDO build as you're excluding Deniz from the statistics. I don't do that anymore, but he made a service account. So we could reuse that service account. The other question is we find a way of saying that the build was triggered by FIDO build in the name of that person. So with the government's authentication, we should be able to proxy or use a similar method of proxying the user, as we did for Koji Web, which Logins Disabled, but where that service would be able to authenticate that. Like when you're logged into the service and you click just merge this and trigger the build, it then proxies that user credentials through. So the build actually happens as the user that merged it rather than some service account. So Deniz mentions that using the Kerberos credentials and system that we have rolled in infrastructure recently, we could actually, when people are logged in on Pergure and press the merge button, you actually proxy the authentication so that it kicks off the Koji build as that person and not as the service accounts. So you can keep on getting your badges. But basically badges is a very valid use case which is on our mind in approaching that problem. It's the most important goal of all. I have a question. Good. Can the direct signing RPMs, what does it mean, what's the purpose? So signing RPMs is, the question is what does signing RPM means? Signing RPM is basically the way for user to be sure that the RPMs, that they are done on incomes from the Fedora project. And there are basically every single RPM that we distribute is signed with a GPG key, which is unique for each release. And so when you install Fedora 25, you get the Fedora 25 key. If you have already installed the RPM fusion repository, the first time that you install something from the RPM fusion repository, it asks you, are you okay with importing the RPM fusion GPG key, which is going to be used after that by RPM to make sure that the RPM that you're downloading do come from Fedora RPM fusion or whatever repo you have accepted the GPG key of. That's the idea. Okay, so I guess that concludes a little bit this talk. We've seen a little bit what happened to body in the recent months, what's going to happen to it and I've just made you dream about coffee and how you could just get push and forget about it. But we need differently help in there. So if you are interesting, willing, Fedor build is pushed to pagoda.io. It has no readme, so that's a missy fix one and we should get a readme in there. Body has a few more updates, which are a little bit easy fix and a little bit less easy fix, depending on how deep you want to dive in body. But we welcome every patch and every single ideas and RFPs and bugs reports. Although there are no bugs in Koji on the random features. There's no bugs in Fedor build yet because it doesn't do very much. There are bugs in Fedor build. There are bugs in Fedor build. I already mentioned two of them. Even a small project, you got bugs. Alright, are there any questions left? Rotten tomatoes, flowers. Tomatoes, flowers. I'm really lazy and I don't want to update the file. Check it in. Can you make it so I don't have to do that? The question is how do we end up people being lazy and not wanting to actually add and trigger and update the changelog file? So the idea, we could do that using and pushing people to make an actual useful description in the RPM changelog and use that automatically. One of the issues which I have there is that basically I don't want to change the current workflow from people so I really want days to be obtained. We could change that eventually. But I mean, in the longer run, if I need to release monitoring.org and the new alternatives are doing their job properly, all you have to do is review a pull request and person match button, which doesn't imply editing files or even interacting with the git in any way. So you can sip your coffee and press buttons. With changelogs is that we actually have three different use cases for changelogs, which is the package package has its own... I'll make it to the video and then you can point people to it afterwards. You should watch this talk and then go to the 45 minutes and then you have Matt speaking about changelogs. I care about this and I don't know the answer.  This is what's happened in this release. This is bugs fixed, all that kind of things. There's also a changelog in a spec file and so the audience of that is often developers of the software or users of the software are both kind of mixed together. The spec file has a changelog and the purpose of that really is to inform other packages what things you've done to the spec file. Like I've moved these macros around. This is when this did this and why you've made that update to the spec file. And a lot of that is stuff that the user never cares about but we keep track of there. So that might make sense as the git commit message for disk it. But then the thing here that goes into Bode, that should never be the changelog from the disk it or from the RPN spec file because the audience of those is totally different. What should go into Bode is why I made this update and why you as a user or a tester should care that this update exists. And we are really bad about that in Fedora so I would like to do something that would make that easier because a lot of the, some of the very best Bode ones are like updated to new version. Like, thanks. I could see that. Yeah, bump release. Yeah, bump release. We see that one a lot. And there's no idea, maybe it says bug fix but maybe it's linked to a bug but you don't know, how important is this? Why should, if I'm trying to test it, what should I look at? I often see a lot of things that I pick on Docker. Like a Docker update comes out and there's like critical things and Dusty is telling us, everybody go test that and I look and it says bump version, you know, and so you don't know what to test or what the reason was or what, so anyways the spec file changelog doesn't tell you that so if we dump that into here we're not helping. Which means that the new Atlas and NTR are not entirely going to solve your problem because we still need to actually human-readable changelog to put in that. Right, and maybe the upstream changelog helps. Yeah, that was me. Yeah, that's a good guy. You need to give badge for a nice update. A badge, yes. You're only looking for more badges. Fedora mission statement too. Fedora is a game by which you can obtain badges for software configuration. Professor. Yes, the changelog macro which is, well, that I can saturate the changelog file because it's shared between the depth and the RPM part. So the discussion that's going on is how can we actually improve the RPM changelog in such a way that it is actually consistent across packages so that you always have space where you expect space that the dates are correct that the information provided in there are useful. So there are two ways proposed. One is to follow the Debian rules which is very, very picky about the date and that it does ensure that there is a space where there should be that the email address isn't actually email address so that the version numbers are consistent. So RPM need already complains about dates that are so it wasn't Monday morning and you wrote it was a Tuesday morning but you got the rest of the date fine and then RPM need is going to complain that date never existed and therefore there is a problem it will do that for the entire changelog which means that if you were not awake five years ago when you updated that package it's still going to complain that five years ago you were knocked away when you updated that package. And then you need to edit your tag file and add to the changelog entry for your update to 1.0.4 that you actually also fix the changelog to the date that was released. So and then the other approach would be to actually key so there are two other approaches. There is one that OpenSUSE uses which spitted out the changelog outside of the spec file and that changelog is then shared between the RPM spec file but also the end user what's presented to the end user if I'm correct. And then there is the other option which is to basically get rid of the entire changelog in the spec file and then rely on the git commit information because most of the time we hear a lot of complain about people complaining that they have to enter changelog three time once in the spec file once in the git repo and then one in body and if they are if they are right about git commit and spec file there is definitely a different use case for the body updates that Matt already nicely explained to us but spec file and git commit are probably more close together than the body updates so maybe it would make sense to match these two. Yeah, but yeah like so what they got stuck into RPM spec file and who the hell ever we is it a big problem if you actually have an entry that says I fix the changelog because it was a git commit it's not really big so I need to go so there is eventually a way for you to do that we're going to stop here because Randy has another talk right now so if you want to follow him he's going that way those are really cool thank you I want to ask how does it feel to be here and say that you have taken over the maintenance of a troubled abandoned project to work 16 hour days and be treated to a few hostile questions oh thank you Hi we have some instruction for you do you want to use hdmi or vga play hdmi first yeah so it works so you don't have to worry about it no it should work yeah let's see what's the native resolution of the projector you know what the native resolution of the projector it doesn't need to be a native resolution the only thing we care about it's 4.3 and I don't know maybe it's it doesn't matter we have really good experience with 4.3 4.3 exactly so this is the microphone for recording you should stay in this area so the microphone gets so yeah and also please repeat the questions for the recording because you know there is no mic we also have signs for that remind you that you should repeat the question so we have the long talk it's for 55 minutes I guess so it's usually 45 minutes for the talk and 10 minutes for the questions we will show you signs that there is 10 minutes left actually it depends on how you want to do it you want to see the signs for the end of the talk so I will show you the 10 minutes left before you have 10 minutes left for the talk and there is still 10 minutes left for the questions itself so yeah that's how you actually want to do it show me signs for 10 minutes left 10 minutes before the end of the talk yeah it's a way I think I mean it takes about 40 minutes but you can also use the pointer or the girl for the presentations yeah I don't know hi I guess


Clearwater County authorities suspect arson though in a house fire that happened near Bagley early Friday morning. According to a press release from the Clearwater County Sheriff's Department, no one was injured in the blaze, which was reported at 2 30 a.m. on January 4th. When firefighters arrived, the home located on 220th Street south of Bagley was in flames. A garage and outbuilding were also on fire in the Minnesota State Fire Marshal's office has been called in to help with the investigation. Anyone with any information should contact the Clearwater County Sheriff's Department. If you enjoyed this segment of Lakeland News, please consider making a tax-deductible contribution to Lakeland PBS.


Hey, YouTube! Today I'll be sharing Intel on the Yale supplement, so stick around. Hi, thank you for joining me on my channel for the best college essay advice. Subscribe and hit the bell. Yale is picky and in a good way. They ask you for research-driven answers, creative outlets for you, and we will get to it all. Hi, I'm Dr. Josie with Write Your Acceptance. With so many of my students in their dream schools, I know how to make you stand out and be as memorable as possible. Stick around. Essay one, and I'll read the prompt first. Students at Yale have plenty of time to explore their academic interests before committing to one or more major fields of study. Many students either modify their original academic direction or change their minds entirely. As of this moment, would academic areas seem to fit your interests or goals more comfortably? And please pick up to three from this list, and so I'll kind of show that for you. After you pick the three academic interests, you have 100 words to explain why. So you want to make sure that you have some sort of connection. Have you had an intellectual project, a creative project, a community service that kind of has given you some first real-world firsthand experience? I've seen examples of students that want to study healthcare administration, and they volunteered at a hospital, let's say. So kind of what drives you to your major interests? And you don't have to kind of give, you know, a third, a third, a third to the three academic interests. You could weigh one more heavy than the others, but you want to make sure that you have that connection. Essay two, you're why us? So what is it about Yale that has led you to apply? This is 125 words or less, so you want to be compelling, direct, and brief. You want to make sure that you are kind of well researched, that you kind of are covering all your bases, all the main bases. I'll be linking above my how to research your why us essays and in the description below, you have my why us template, if that's of interest. You want to make sure that yes, you kind of cover all your bases in research, that this essay is very research heavy, because high caliber institutions like Yale want to kind of know that their students know about them and that they're convinced that they as students are a good fit beyond the brand. So really research heavy and I kind of, like I said, linked above how to do that research, but also kind of connect whether you've taken a class that's similar to a class at a deeper level in the undergraduate course catalog, or you've done some community service that kind of takes you beyond the classroom in an interesting way that you can kind of continue at Yale. So connect something personal about you and the connection you have to Yale or how you see yourself living and learning there. Step three, these are very similar to the USC short answers. There are about 35 words or less and I'll link that video up here in case you're applying there too. So these are kind of image driven, catchy, engaging, some could be funny.  So like for instance, for one of the questions they'll ask about kind of like what course you would teach. Okay, so maybe you would teach the history of popular dance in Columbia, if you're a Colombian American. So that may be of interest. And so these are the questions specifically. So these are the questions. What inspires you? Yale's residential colleges regularly host conversations with guests representing a wide range of experiences and accomplishments. What person past or present would you invite to speak? What question would you ask them? Another one, you are teaching a Yale course. What is it called? Another one. Most first year Yale students live in suites of four to six students. What do you hope to add to your sweet mates experience? What do you hope they will add to yours? So especially the course you teach what's the title? What would you add to the sweet mate experience? All that you could be very personal, very identity driven. And it could be an opportunity to add something new to your application that you haven't really shared. Step four. So this is your first 250 word essay. And so for all coalition and common application, and I'm going to read it for you, think about an idea or topic that has been intellectually exciting for you. Why are you drawn to it? So you can think about adding something beyond the major, let's say. So are you an engineering major who loves to dance? Or are someone who loves photography? Are you a chemistry major who loves a community garden and you're part of a community garden in your kind of high school or, you know, near your home? So think about how you can incorporate something new and refreshing into your application. And you're still kind of teaching them an aspect of who you are. And so like that community garden, let's say, you can then go a step further and how you've learned about urban design and urban planning and how you've learned to connect with people of all walks of life and, you know, not only teenagers or your parents, let's say. So you can kind of show breath and open up the topic beyond two larger, kind of more thematic points that really kind of deepens your intellectual curiosity, but also makes you more engaging, let's say. Do you need help structuring one of your supplements? Comment below. I'd love to help. Step five. If you're applying through a coalition or common app, you have one of these two essays, and I'm going to read them for you. There are 250 words or fewer, and they are first one, reflect on your engagement with a community to which you belong. How has this engagement affected you? So let's say the previous example about the community garden, that would be a great one here. This can also recycle with the community oriented supplement for Michigan, because they're about the same length as well. So just in case you are applying to both, that's something that you can consider. You want to think about how you define community. So if you are on a cross country or track and field team, so you've built community through sweat and calluses, let's say, or kind of are you narrating a family holiday gathering and how loud and crazy and all of these fun characters are part of your family, but they have nurtured and shaped who you are. So it could be very identity heavy or it could be kind of an interesting unique poetry space that you define as community for you because they've nurtured confidence and creativity for you. So think about how you define community and then go forward in a very image driven way. The other option for the 250 word essay is this prompt and I'll read it to you. Yale students, faculty, and alumni engage issues of local, national, and international importance. Discuss an issue that is significant to you and how your college experience could help you address it. So you want to be thoughtful, you want to be precise, and you want to show kind of how you are adaptable and really committed to the practice of effective communication, of discourse, of kind of engaging in conversation and debate. That more than anything, more than any specific issue is going to be most important, that you are willing to listen to another side, that you're willing to come together and be adaptable and flexible and compromise. That is the trait you want to show. And then also they want art. So they want either a video file, audio file or picture that really kind of shows you in your element doing your thing. Bonus for my engineers. Yay. You have one more essay, which is basically a quasi why us and connected to what you've already done in STEM or in an engineering related kind of space. So you want to make sure that you don't forget that essay. If you want to check, if your essay, your main college essay is as strong as it should be, needs to be, you want to download my free college essay guide in the description below. I also have my YS template there. I'm also already working with students, even if they have a draft. So even if you already have a draft and you want to make sure you want to get my eyes on them, make sure you get our college essay guide. But then also I have the courses on my website. If you found this video helpful, please give us a like, please comment, yay, or question. And I love to help. And please share with your college bound friends. I'd really appreciate it. Thank you. Have a good one.