You're watching FJTN, the Federal Judicial Television Network. Coming up on Court to Court. You need to have a process that enhances the work of the officers for them to adopt it and for them to accept it.  The staff need to have information and that they need to be able to make their own decisions. And I want them to have the information, even though it's sometimes hard to handle. This is Court to Court, your connection to what's happening in the federal courts around the country, providing information and ideas that will enhance your job and how the courts function. Now with today's program, Michael Burney. Welcome to Court to Court, the Federal Judicial Center's educational magazine program for all court employees. Today we'll see how sophisticated technology makes a difference in the workplace, and we'll hear an extended discussion from several court unit managers about budget issues facing the judiciary. It's been said that information is power. If that's the case, then in today's world rapid access to the information and being able to interact with it are the touchstones of that power, and technology drives the means to deal with information. Of course, the speed with which technology changes is beyond anything anyone imagined in the past. Successful use of technology in the workplace doesn't happen just because the technology exists. At the U.S. Probation Office for the Southern District of Florida, the eight officers who supervise offenders on electronic monitoring, the EM officers, were the test group for a new, more sophisticated personal digital assistant, or PDA. Before I had this PDA, I worked out of a field book, which I'm sure most officers will remember, pages and pages and pages of documents and notes and scribbles everywhere. The EM officers needed a device to try and minimize what they carry, and that entails not only a casebook but forms a phone all the time to access the alerts they get. With those things, they became a little cumbersome. So we decided to try and find a way to make it less cumbersome. Now with the PDAs, all that is done on one simple device. While PDAs have been around for several years, they become more and more sophisticated with each new version. The one de Lestinaire uses functions as a pager to receive offender alerts from the electronic monitoring system. It's also a telephone. It also contains the probation office's offender database with all the relevant data about each offender. And of course it contains a calendar, which has advantages over the paper kind. I can set a schedule in place and it will automatically alert me. The book won't. Information can be copied either in the PDA, though that's somewhat tedious with the tiny keyboard, or in the officer's computer, and then copied from or to the PDA. The other advantage to the PDA is that while I'm at an offender's house talking to them, if they have a question, anything about their case information, I can look in the PDA, access that information and give it to them readily right then and there. The other bonus is that I have my phone system set up to where if somebody leaves me a message, it will automatically forward to my PDA because it is also a phone. Hello? Yes, Tom? All right, what you need to do is give me a call tomorrow. Officers spend a lot of time in the field checking with offenders, both at their places of employment and their homes. This PDA has a voice recorder, which can save time in the field. If I come up on a house, I know that only one individual lives there. I know their vehicle, and I see six vehicles in front of the house. At that point, I can make a tape recording or record at least the tag numbers and a memo to alert me to the fact that I need to check out what these six tags and cars belong to. In the past, DeLeste and Air would have had to sit there and write notes and so on and so forth. This is something that's very simple. I just record it. Simple, maybe, but not automatic. It takes a little doing it. There's a learning curve. I mean, you just don't simply plug it in and it works. You have to have staff that's willing to, you know, suffer a little bit and deal with that learning curve. And what's the key to getting staff to be willing to suffer a little? I think that the applications have to be of benefit to the end users. You can't be selling something that has no value to people. Our more successful applications are those that people enjoy and support because they understand intuitively, this is good. This helps me do my job better. Still, introducing new technology involves change, sometimes not eagerly anticipated. Technology always brings a little fear. We had some officers who embraced it quickly and wanted to get it as soon as possible and others didn't feel comfortable with it and honestly didn't want it. They said, you know, I'm used to my simple phone. I like carrying my casebook. I feel comfortable with it. Just leave me alone. Kind of was their attitude. Changes make you nervous. People usually don't like change. So at first I was apprehensive in receiving it and learning how to use it. We took it slowly. We put the technology out there. We didn't force it upon anybody at first because we always thought and still do think that it'll sell itself. Things are working all right. I'm getting my alerts on time. I'm not getting any more alerts from Abe's cases. We gave them the training. We showed them what it can and cannot do. And during the monthly EM officer meetings, we would, and I would by design ask someone to come up and speak about what they learned about their PDAs. And that kind of encouraged officers as well. Oh, how did you do that? Show me this. It was just a point of playing around with it and finding out what worked, what didn't, how to get around it. It was very simple and very easy to understand. I suppose after about a week or so of having it and putting information in and out, I was proficient with it. And through learning with each other and going over things with each other, I think we also brought around those officers that were a little reluctant. Now those same officers are the ones that want the latest technology all the time. Deputy Chief Horowitz says that using technology effectively means spending the money needed and being willing to make key decisions about technology. Success means a commitment to ongoing support. I think our attitude here is that change is inevitable. However, we're not going to force it upon you because when you force things, you get a big backlash. We try and slowly feed change so that we can make you accept it over time because when they do accept it and embrace it, they really embrace it. It's driven by the end users. You need to have a process that enhances the work of the officers for them to adopt it and for them to accept it. It needs to be developed by the staff with the assistance of automation as opposed to a technical group getting together and trying to decipher what the end users need. The biggest surprise about using the PDA is the wealth of information that the PDA has to offer. The information that we have in our database is easily translated down into the PDA for us to access. The offender database includes all the standard personal information about the offenders, their homes and cars, ID numbers given by various law enforcement agencies and information about each offender's case. It even includes photographs, which can be helpful when an employer may not know an offender by his or her legal name. I'm looking for a gentleman who just recently became employed with you, Mr. Frank Smith. Is he available? I don't remember that man. You don't remember it? I'm sorry? Let me show you a photograph of him. Is that him? Yeah, yeah, yeah. Okay. What do you know him by? He'd be right there in the back sitting over there. In the back? Okay. No matter how advanced something is, it seems a new and better application is always just around the corner. Deputy Chief Horowitz is now looking at laptops with wireless cards so that officers can dial into the probation office's network as well as the internet. And keep in mind, the beauty of course is, you're not tethered anything, so we're thinking about this in your car, in the field, in an offender's home. When you're truly wireless, you're connecting to your database. You can interact with the data. You can actually query your data. You could actually enter data in. It's not going to be the same identical screen as this? It's the same screen. The issue that you need to decide is, as we look at this technology, and what is your preference? What the preference would be? Can you live with something a little larger that has full functionality? Or would you prefer something smaller that is more portable, easier to conceal? Wireless is probably, in remote access, is probably going to overtake us to the point that it'll be ubiquitous like cell phones are now. So I think we just need to be able to be flexible and just anticipate that there's going to be changes in the technology. And see how that enhances our business process. Keeping the focus on practicality. So I don't have to worry about looking in my fieldbook and looking through my notes and looking through the little scratch pieces of paper to see if this one was current or that one was current. This is the wave of the future. I think we have to use technology to our advantage to make our jobs not only easier, but a lot faster and more accurate. Hello. We had planned to bring you another court history feature today, but instead we're airing an extended version of a conversation about budgets. We will have that moment of court history in a later broadcast. Budget issues are a key concern of court units across the country. The adage, doing more with less, has been heard so long that some fear it may become doing less with less. We recently spoke about some of these issues with court unit managers in the western district of Kentucky. Patrick Craig, chief U.S. probation officer. Jeff Apperson, clerk of the district court. And Diane Robel, clerk of the bankruptcy court made it clear that there are no easy answers in difficult times. The court units in the western district of Kentucky and Louisville face the same budget problems as most units across the country. Reduced budgets now and likely even smaller in the future. The unit manager's responses are typical. I'm assessing every single operational administrative aspect of my office where we can reduce requirements to those that are absolutely needed. We're reducing the size of the office. In the last year, we've lost three positions and in the last two years, up to eight positions. Fortunately, the administrative office and judicial conference offered us some tools, buyouts and early outs, in which we were able to achieve a voluntary reduction in staff. That will help us absorb significantly the impact that we expect the shortfalls to bring next year. In the short term, we're facing a reduction of staff. What I'm concerned about also is that we're going to be able to continue to meet the high standards that the court has for servicing the public's requirements and needs. This is one of the major impacts that budget reduction has had on our district this year. We've lost staff through attrition and have not been able to replace them due to lack of funding. Chief probation officer Patrick Craig worries that fewer officers affect the work of the court. We can basically bring one person on for every two people that we lose, which is going to cause us some similar problems that Jeff spoke about because the courts rely upon us to give them reports in a timely fashion so that their dockets can clear as they like them to. But more than court calendars is affected. I have a lot of people out there that are in the community and doing things, they're traveling, they're doing drug after care, they're doing some things that are costly. Eighty percent of Craig's budget is for staff. While all three of us are in the people business to some extent, most of their people are coming to them and we have to go out and see a good portion of the people that we have, so as I lose people it really has an impact on my ability to be affected. In the bankruptcy court clerk's office, Robel recently proposed consolidating three case administration teams into two and solicited feedback from staff about her proposal. She says that because budget issues affect staff, they should be involved in decisions. She adds that it's important to communicate as much factual information as possible. So that they're not just hearing from me that we don't have money, but they actually hear why we don't have money, how much money we don't have, and that they have more involvement in the overall picture. It's beneficial to them in terms of understanding, it's beneficial to me in that they will contribute ideas, will help brainstorm what direction we need to go or what will work and what will not work. Chief probation officer Craig also involves his staff in a reorganization brought about because there are fewer officers. One of the things that I realize I'm going to have to have is more flexibility in my staff. What I offered to them was a proposal that I thought would work and I said here's where I'm leaning, but I'm open. Give me some counter proposals, give me some feedback. Norma and John and I sat down this week and came up with ballpark ideas, numbers on how things were going to hash out. They came up with multiple proposals and people presented them, did charts, presented handouts and everything else as to what they thought was the most effective way to handle this transition. Right now, I'm right at 50, give or take one or two. And if I'm not going to be doing any precedence reports right now, then my numbers should be up a little bit higher than what that shows to 40. Ultimately, what we're going to do out of it is not the proposal that I put up, but is a proposal that was presented by some of the staff. I think it's extremely important when you're doing that stuff that staff has the ability to at least talk about it, have input into it. You and Eric cover the same counties and Jamie and Amanda cover the same counties. Maybe it'd be beneficial if I went. My long-range concerns are how do you continue to motivate and maintain morale amongst your staff and at the same time effectively get done what needs to be done. Because I think there is a point of saturation and where that is, I'm not certain we haven't gotten there yet, but I think it's on the not-too-distant horizon. And the ironic part about it is that you're in a position of needing desperately to motivate staff, and yet the budget situation is somewhat frightening for staff to experience. So you have to rise above that information and still continue to motivate staff to do the best they can. And I think it's just a matter of letting them become familiar with how this credit card module works. They're still not comfortable with it even after three months. Again, I go back to communicate, communicate, communicate. I'm a firm believer that staff need to have information and that they need to be able to make their own decisions. And I want them to have the information, even though it's sometimes hard to handle, for instance, that we may need to lose an additional position by the end of the fiscal year. That is difficult for them to hear, but I don't want to keep them shielded from that information. I want them to be able to make their decisions. We've got to be real careful about how we publish the issues and how we administer the decision-making process in reducing requirements. I mean, these are people, and they're really special people. They do a great job for the judiciary, many of them for many years, and I think we owe them some. I really try to keep insecurity at a minimum. I don't want my staff to feel threatened, and I want to do this as progressively and voluntarily as possible and include them in the decision-making. It's kind of the golden rule. I wouldn't want to feel like I was going to lose my job tomorrow. Protecting staff is a major challenge, but in a world of smaller budgets, there's also the uncertainty of what work needs to be done. All of us are in a business to where we don't control what comes in. I can't control how many defendants or offenders we get during the year, just like Jeff and Diane can't control filings. Rubel says that because the work of bankruptcy is somewhat repetitive, it especially lends itself to the use of automation systems such as electronic case files, which can save some case administration costs. The offset to that, though, and that has to be kept in mind, is that you still have to increase the automation services, and automation is expensive, both personnel and equipment. So you're not getting a clean savings by merely eliminating case administration, but the reality is that in the bankruptcy courts, those that use ECF to its fullest extent, there are savings to be had, and again, that depends on the judges of each court as to what level of implementation and use they make of ECF. And automation can't do all the work. I do believe that automation brings us a great ability to reduce some of our needs, but I also believe that automation can't supervise offenders in the community, and I need people to do that, so losing people has a huge impact on probation offices. These managers share the same building and a spirit of collaboration. We have fewer resources to rely upon, and we're going to need each other more and more. Court unit managers working together isn't new, but it does require effort. It doesn't just happen. For one thing, units may be in different locations. There may also just be cultural differences between court units and not as much communication, and I think that that's one of the areas where we probably do better than most is that we do see each other and we do communicate with one another on a regular basis. We do quarterly meetings, and we don't actually share one another's budget with the other court unit, but to the extent that a court unit may have lapse funding available or may have some significant projects in place, and they anticipate a shortfall in funding, we announce that to one another, and to the extent that we can, we provide monetary assistance back and forth by shifting funding from one unit to the other unit. Robel says that there also are non-monetary ways to help. We've offered to assist the other court units in providing the non-confidential type of human resources assistance that any office would have. She acknowledges that not everyone embraces this philosophy. I think that there's a sense among my colleagues in the bankruptcy court that there is potentially a loss of independence by too much working together or too much sharing, but I also think it's important for us to realize that we are a part of the larger picture, so it's a balancing in some respects between maintaining your independence as a court unit executive, but also playing a role as a team member within the unit itself. And the secret to doing that? A lot of communication and the freedom to speak freely, to speak openly and to say yes or no when the time arises, and I feel comfortable in doing that. Sharing administrative services is getting an intensive look within the judicial branch, and we're likely to hear more about it. The three managers also talked at length about larger issues in their budget concerns, such as the dichotomy between the emphasis on frugality and the spend it or lose it mentality. I know it's a big element out there right now as practice good stewardship.  All of us are looking at ways to try and reduce our costs. The downside to reducing costs to some degree is that sometimes you reduce your cost and you lose that funding. I'm not certain what the answer is. I'm not certain that there's any one thing that makes anybody good at what's currently going on. Most of them, if you talk to them, who've been around for a period of time will tell you spend what you get, otherwise you're not going to get as much next year. So achieving good stewardship by just talking about it's not going to get it done. There's got to be some incentive for people to save money, I think, beyond the fact that it's the right thing to do. And I believe it is the right thing to do. I don't know what the answer is to that, but there's got to be a different way of doing it if they want to get to that point. Another issue is the timeliness of knowing how much budget they're going to have. The other thing that's a little difficult is in the planning aspect because we get our money so late, most people that I've talked to at least in probation are pretty limited in what they're spending in the first and second quarters just because they're uncertain of what those funds are actually going to be. And all the funding is based on a historical perspective, so I think it's having some impact on what our funding ultimately is because of how we're having to spend. Because we're under fiscal year pressures to use the money that's obligated for that year. And the later we get it, the less planning we can do with it. And that is a huge problem. Basically in the first two quarters you're in a holding pattern and then you have two quarters in which to plan that current fiscal year. But you're never in a mode of planning the upcoming fiscal year, which is ideally what we should be doing. Without knowing what your funds are, we tend to be very conservative in anything that we spend. It's basically necessity. You don't buy anything or you don't purchase anything. And sometimes you don't even get that that's necessary because you're not certain you're going to be able to make it through the year with the funding that you receive. So you end up not spending as much in the first and second quarter. Therefore we end up trying to figure out in the third quarter what can we spend, but you still know you have to get through the fourth. So you're sort of conservative still. And the fourth quarter doesn't help you because that's not going to be considered in your funding for the next year. We're all wondering what's the floor that we're going to reach here for planning purposes. Which leads Apperson to contemplate an even larger issue. Our role has got to be to reduce costs in every way possible. And we need to do it now because based on my experience, there's a problem in the judiciary that's going to affect all of us locally. And that is that the nondiscretionary accounts are consuming the local discretionary accounts. For example, two years ago, the discretionary nondiscretionary accounts were 50-50. Two years later they're 60-40. If we don't deal with that dynamic, we're all going to be struggling. That dynamic is occurring because Congress is not funding our requirements. If we don't deal with that, public service is going to be degraded. The judges largely control the nondiscretionary accounts. If those accounts are consuming the discretionary and they control those accounts, then they need to be aware of that. The more that we can communicate with them about our funding issues, the more flexibility we'll have to implement reductions in staff and other priorities. But it really is a team effort. I think the judges also have to realize that their use of the central accounts, which we don't control, does indeed affect our ability to use the local accounts. I don't think that message has been quite clearly as well made as it could. How the central accounts are consuming the local accounts, because that has to be made, because Congress is not funding the judiciary fully. If you don't have enough money in the national spending plan, there's a prioritization.  The managers have to manage the local accounts to accrue the savings that are required to fund the national plan. That's what's happening. Apperson's suggestions? I think every court administrator should convey the issue to their chief judges and let their chief judges decide how best to convey the issue to the other judges. The administrative office can play an increasingly important role here on a national level when the opportunity presents itself to convey the message to all the judges. Apperson strives for perspective, but acknowledges the challenges. Our judicial budget-making policy is one of the most unique models in the world. And I'm really thankful that we have the model where we have the local control we have. But on the other hand, because of the responsibility and using it more effectively, it does make the decision-making process more complicated.  We value your comments about this program and your ideas for future topics. We're continuing a different way to hear from you rather than filling out an evaluation form. Please email me your thoughts, comments, and suggestions at mberney.fjc.gov. That's mberney.fjc.gov. Our next court-to-court program will feature CMECF Training for Attorneys. A moment in court history tells the story of two female legal pioneers. And we'll hear from four clerks of court about their work helping courts in other countries improve the administration of justice. We hope you'll join us. I'm Michael Burney, on behalf of everyone at the Federal Judicial Center. Thank you for watching today.


Somewhere around the late 90s and early 2000s, there was a top secret project at Microsoft known only as Code Name Moon. The project was said to be the next big thing in operating systems, with features that would revolutionize the tech industry. However one day, the project suddenly disappeared. No one knew what had happened to it, and it became one of the biggest mysteries in the tech world. Some say that the project was cursed, that it was too ambitious and that it had amured some higher power. Years passed, and Code Name Moon became nothing more than a forgotten legend. But then one day, a group of tech enthusiasts claimed that they had found the lost operating system. They had stumbled upon a hidden server, deep within the bowels of Microsoft's headquarters. Excited to see the long lost project, the group quickly downloaded and installed Code Name Moon onto their computers. But as soon as they did, strange things began to happen. Their screens flickered, and the icons on their desktops began to move on their own. Files that they had never seen before appeared on their hard drives, and their computers would randomly shut down and restart. They soon realized that the lost operating system was not what it seemed. As they dug deeper into the files, they discovered a dark secret. Code Name Moon was not an operating system at all, but a gateway to a sinister realm beyond our world. The project had been abandoned because it had been deemed too dangerous, but someone had tried to bring it back to life. The tech enthusiasts soon realized that they had made a grave mistake.  They tried to remove the operating system, but it was too late. As they watched in horror, their screens turned black, and a single message appeared in bright green letters. Welcome to the other side. And then, their computers burst into flames, leaving behind nothing but ashes. To this day, the lost operating system known as Code Name Moon remains a mystery, and those who dare to search for it may find themselves facing a fate worse than death.


What's up everybody I'm the mangoose you are awesome and now that I've had some time to play it we're going to talk about the .40 patch for Fault. My opinion is all the changes are overall positive so if you were hoping for a patented mangoose rant I'm sorry. This is also going to be a pretty boring video visually, but let's dive in and go line by line discussing the changes that Strange Matter made. Learning with hero experience, XP gain was changed so that you level a little bit slower especially to level 2 and everything else was balanced around that. It does encourage better farming from players but I really didn't notice that much of a change. I was expecting this to slow the game down but in my experience it didn't and I'm happy about that. The gold you get from kills and XP bounties, a lot to go over here I'm just going to try and summarize this a bit.  That's somebody that's being pushed in the entire game. Assist gold is fixed at 150 unless you kill someone that's on a death streak. Group kills give XP according to the victim's level and is shared among everyone that gets the kill.  So you get more experience from killing someone higher level than you and less if they're lower level. All of this adds up to discouraging deathballing while also giving the losing team more of a comeback mechanic. All in all great changes as far as I'm concerned, Fought has been a very snowbally game and these changes should alleviate that somewhat. Back to the end of all of this, they're reducing the shared XP from lane minion kills from 30% to 25%. The way I see that, it's a bit of a nerf to supports that are trying to get their XP through their carry getting last hits.  Just through discourage stacking a lane, but I think it hurts to the supports more than it discourages deathballs. Skrystone is a great idea to help supports gain some gold, but I'd rather have experience to be honest. Now that they're chopping that down a bit, I don't know. As a support you rely more on the impact than the efficacy of your abilities and slowing down support leveling ain't good. Hopefully I'm just kind of misreading that and I'm not getting it or something, I don't know. It didn't really seem to have that much of an effect, I mean as a support you're always down on golden levels anyway, so whatever. Basic attack projectiles, they increase projectile speed by 20%, good change. To quote the door gunner from Full Metal Jacket, you just don't lead them as much. Some changes to how heroes function, the hero camera field of view decreased slightly and the camera position tweaked. This brings the view of Fault more in line with Paragon, which I like. Hero acceleration and animation speed increased slightly, I don't think they increased this enough, Fault still feels a bit sluggish. But I like that they are amping this up in small increments, I would rather they gently tune this until it feels right instead of going overboard and making everything too fast. Base movement has been tweaked according to class, so ranged heroes will move slower than melee. I like this change and I think it should have been this way from the beginning.  Lane minions, now this along with the raptor changer probably had the most effect on the game overall. They increased the amount of minions that spawn in a wave, instead of two melee and two ranged, you now get three melee and three ranged. The health damage XP and gold have been redistributed among the minions so each minion has less health and deals less damage individually. This was supposed to help with last hits and it does for the most part. However I see this as a step forward in solving one of Fault's main issues which is a lack of lane based macro play. One of the hallmarks of any MOBA is manipulating minion waves to your advantage but you don't see that as much in Fault because the minions are kind of weak while the towers are very strong.  Same with mid lane rotations. One of the reasons you normally take a mage in the mid lane is because you can quickly clear the lane and rotate but you don't have to clear the lane in Fault.   The new minion changes do somewhat alleviate that even if that wasn't the intended consequence. Yes the minions deal less damage and have less health but it seemed to me like the larger waves were a bit scarier and were able to deal more tower damage than before. I like to see them start to tune up minion damage a bit in the coming weeks until we have a good balance and setting waves becomes more of a meaningful skill set. A bit of a side effect here, the lower health with more minions made last hitting goddamn near impossible if you had a full wave.  The minions also get a little faster every 90 seconds maxing out at the 25 minute mark which also helps with using the minions to your advantage. Super minions got a little bit of a buff. The super minions now replace siege minions. They spawn at the front of the pack and they take 70% reduced damage from AoEs and they also grant physical and energy armor to minions around them. Great change that should help end games a bit more quickly here. They also fix the jungle minion spawn times. Now for the raptors.  This is a great change and one that has been asked for.  It's a bit scarier now as the enemy team can snipe that raptor kill from you and you can't just kind of drop by take one and roll out. All in all I think this makes taking the raptors more of a meaningful decision that should be made based on what's going on in the game more so than just you know the timer for raptors is up everybody go. Or prime or prime got buffed a little bit taking prime now awards more XP and gold to the entire team which is great. Not much to say here really I just like this change makes the reward match the risk a little more. Optimization they did more fixes to optimization so you don't get as many frame rate spikes and they locked the frame rate at 100 until they can get things completely smoothed out. If you're still having frame rate issues a few things you can do is lower your shadow quality while also lowering your post processing. Check your task manager to make sure you don't have something like adobe eating up your ram. I also found that Norton firewall was causing crazy freezes in my game so I opened those settings and allowed fault through the firewall. If you're having trouble identifying the app jacka gave me a little tip in the fault discord it's called res win but I'll post it on the screen you only really need to know that if it's not already just straight up named fault. Bug fixes they fix a bunch of bugs biggest change here is that you can't get on top of the walls around the raptor pit anymore which is a great change. Gideon used to be able to just stand on that wall and rain down destruction it also makes it harder to cheese wards you can't just stick wards where mainly heroes can't get them that that is so cheesy it's not something that I ever do like I try and play the game fairly and the way it was intended you can cheese wards in a lot of different areas but always put them on the ground as they were supposed to be put. Bug fixes the muriel is actually a pretty big buff to muriel not really a buff but she works as intended now which is which makes her a lot better than she was. Her consecrated ground was supposed to give a shield when you entered it and another shield when it popped it wasn't doing that before it is now that's actually a huge change from muriel this effectively doubles the efficacy of one of her abilities I don't know if it's enough she still seems a bit weak unless you're going like off lane kill kill muriel her being weak is probably just me being bad at her really though some changes to items subs or substitution whatever you want to call it which lets you transfer damage from a friendly hero to yourself has gotten a much needed range increase I like this item but I haven't been taking it because you have to be dangerously close to the action to use it I'll probably try it out more now. T-Fist's active has been changed from energy damage to physical damage seems to be a trend to change stuff from energy to physical because people normally build physical armor long before they build energy armor change to one of the aspects one of my favorite aspects magician this one is the one that gives you mana regen based on your missing mana they reduce the amount of mana regen from 0.5 to 0.25 per 100 missing mana making this aspect less powerful I'm sad because I love taking magician with pretty much any hero that uses mana but I can definitely see that it was a little too strong this will force you to think about your mana consumption a bit more now heroes countess taking a big hit with nerfs to shadow slip dark tide and feast pretty big nerfs too all I can say is fuck yes countess was getting picked in pretty much every game and was deleting teams with very little skill I think really great countess players will still be a terror on the battlefield after these changes but people that were picking her because you could just like spam three buttons and kill anyone won't be able to do that anymore poor little babies Gideon got nerfs to cosmic rift and void breach while they buffed a black hole again great changes all around here his ultimate didn't feel as impactful as it should while his basic abilities were very strong especially in the hands of a skilled player not me that could take advantage of his passive ability to reset cooldowns so the countess and Gideon nerfs combined with the bellica nerfs from last patch means that all the casters have been nerfed in fault I think this is very much needed casters should feel strong and have devastating effects in a team fight but they shouldn't be crushing one person's entire health bar with two abilities Narbash thunk cooldown increased a bit as you level not a huge change I don't think it was needed but I'm a Narbash main so I'm biased as fuck Theo buffs to the damage of shield bash and his ultimate while the stun from his ultimate has been nerfed a little it's good to see the stun duration brought down a bit seems like the stun trains are a little too easy to pull off right now I'm not sure that he needed the damage buffs anytime I've played steel I felt pretty damn strong and other steels that I've seen also seem strong I may start picking him more than Narbash to be honest do you guys think he really needed the damage buffs I don't know and finally twin blast holy hell was this ever needed there is now a 0.625 I don't know how they came up with that number second delay between grenade charges twin blast is an ADC but people were playing him as a burst mage because you could just triple ram grenades up somebody's ass before they could react at all he was a terror in the early game because of the burst damage while still being scary late game because you know he's he's an ADC this was a much much needed change I think overall positive changes the fault many of these are things that we specifically asked for as a community so it's nice to see that strange matter is listening and willing to adjust if you enjoy my content please hit that like button and subscribe for now this is the mangu signing off you guys have a good one mangu


Would you prefer that I turn the recording off? No, I thought you were going to do the introduction. Oh, okay. Welcome to today's GSOC mentor meeting for the Jenkins Cloud Events plugin. And we are speaking about Shruti's work in the last week and moving the plugin towards a first release version. So I did review the pull request and got it merged and just one thing, one thing I wanted to say was the read me would be nicer with the TOC table of content. And that's it. And I think we can move on to doing the first release. This week we can catch up on Wednesday or even tomorrow to do that. Yeah. So, what are your next steps of the plugin? We also, what is that about read me? Did you say TOC? Table of content. Okay. Okay, I'm sorry. So, the, the past week. So we talked with the events team just to get a better understanding of how they have been developing their like events. And so that's it for the captain and Tecton sort of integration. And I was able to clear some things in terms of how we can design a sync which is agnostic and also it can deal with different kinds of events in different structure and coming in from different sources. that if we can talk a bit about that, so we have a better understanding of the infrastructure that can be in place for the stage where Jenkins as a sink. I think that will be a bit helpful in moving forward and just thinking about everything that's needed for Jenkins as a sink. The last time we were also discussing when Kaira and Ivy were discussing about designing the sink, which is an actually cloud native sink which can deal with fault or just like network and transient failures and also can deal with retries, which retries is also applicable to Jenkins as a source, but that's something that can be accomplished in an easy manner. But for Jenkins as a sink, so when we were talking with the events, say team, they specifically had sort of a middleware, I'd say, which is dealing with events coming in from Tecton and captain. So they had like captain inbound and Tecton inbound and like outbound for both of them. And what they're doing is basically like transforming the cloud events, which is going out and then they have a middleware in between, which is like a cloud events broker which deals with receiving and sending of the events. And if our sink is totally like an HTTP request response system only, like if you're designing or if you're, for example, like receiving events only in that manner, only like a post request to the endpoint where it's present. I think that it's really going to tightly couple things with that infrastructure of Jenkins server or Jenkins node, whichever, whatever is dealing with the events always being available. And then it also leads to the possibility of losing events, some of which might be crucial. So I was thinking if maybe we can start out by like maybe testing with Knative because that's sort of the whole, you know, like the product is actually something that might help us, but also not really sure if having Knative, like having Knative integrated with this sink, how can this work? Like it's going to be two different tools, but also when someone is configuring Jenkins and Sink we wanna spin up Knative so we can, you know, configure like an infrastructure as code or something similar to that. But I was actually curious in hearing your guys's opinion on the Jenkins as a sink infrastructure specifically going on using a PubSub like infrastructure going for a different protocol for both Jenkins and the source and a Sink, for example, if we wanna introduce Kafka both for Jenkins as a source and also as a Sink, you know, like because Cloud Events does support like the protocol for using Kafka and also if we wanna go with like a queuing infrastructure so there's Revit MQ would support the kind of system that we might wanna work with in a full tolerant and sort of like a full like transient failure tolerant system. So I resist, that's a very, that's a question that's everywhere I resist. If you guys have an opinion on that or what do you think about it? So I think we can try implementing retries probably with HTTP, but if you want to start playing around with the Kafka protocols for the Cloud Events, what you could start doing is you could just set up like Kafka, I haven't worked much with Kafka but you could just set up the infrastructure for now and then start playing around with it. And then along the way, you will see problems which come in some things which could be better but in terms of implementing Pub-Sub and everything from Jenkins site directly, I'm not so sure about that. We probably, it probably would be good if all of that stuff like even retries and all these things actually would be managed by, you know, some kind of middleware, some eventing middleware like Kafka. Yeah, and that's what for Knative, that's what the broker is doing. So, you know, you have events coming in from Tecton and that's using sort of like a Tecton outbound and then sending a specific kind of event which Knative is expecting over to the event broker and the event broker or the Cloud Events event broker is the one who is implementing the retries and also implementing sort of an asynchronous way of handling all of the events and the messages which are coming over. So with the Jenkins as a thing, that's like my meeting send with, you know, because they said, I like remember them saying that, you know, since all different sources have different data or different way that they have structured their Cloud Events, I don't remember them saying that any specific solution for designing an agnostic sync specifically has worked because everything is different. So we might want to think about just implementing, when we're thinking of like implementing a genetic sync, also just thinking about having that middleware which can handle different kinds of both like protocol and also the different structure of data that's coming in and then design it in a way that Jenkins should receive it. I don't, I am not really sure if that can work though, but I feel that might be helpful. Sure, G, from my understanding, but you can correct me if I'm wrong, the way that they're using the broker, this middleware, it is what enables the sync to be agnostic to the underlying technologies. So this is what provides essentially like a translation layer depending on whatever underlying if you're doing RabbitMQ or if you're doing Kafka or whatever underneath. Yeah, I think it's, so for them, what I understood was that the responsibility of creating sort of, you know, both the events which are understood by the sender and the receiver, it's the responsibility of both the source and the sync. So I can actually go back and pull out there the POC that they have. And also there's a PubSub Lite plugin for Jenkins, which is a Lite version of PubSub, not necessarily something that can be helpful, but definitely, like I've looked into it and this definitely looks like something that we can use. If you think we can use the existing logic and the PubSub plugin which you're talking about, could you send a link to that plugin? Yeah, it's over on the GSOG section. Is it PubSub Lite plugin? Yes. If you can use this, oh yeah, okay. So I will say if you could use the existing logic and the PubSub Lite plugin without having to write something new, then it's something, maybe it's a good idea to experiment with it. So initially, why don't we try like playing around with those K-native brokers and see how that works? Yeah, that sounds like a good idea. And also like another thing is if we do wanna support just K-native, where or how should it be inside, like as a part of the plugin. When we try that with K-native, does it mean that we support only K-native because I think cloud events are agnostic that way. Anything that reads cloud events, cloud, sorry, I mean cloud event. So anything that reads cloud events will like read a cloud event, right? Whether or not it is supported by K-native. So even the broker, I think is such that it will just help prompting the events with anything. It necessarily doesn't have to be supporting on the cloud events for K-native. Yeah, so the K-native, like the K-native broker specifically works with cloud events or this is like, it can work with other structured event data, but I think like the K-native brokers itself, is only with cloud events. But if we wanna substitute this with something, so can you guys see my screen? So there, the POC that they had, they had like tecton cloud events, which was sort of that tecton outbound, which is like sending cloud events over and then it's receiving it and then they have a trigger. So it's just like, if any event is coming and looking like it's from tecton. So that trigger, it's basically, how we were mentioning setting filters. So CE type C, that's what the trigger is going to do is basically set filter. So the trigger is gonna be like, okay, if any event is coming of the type C dot tecton or whatever, then send it over to this captain inbound. And the captain inbound is what sort of transforms it to be used by captain. So as Kara was saying that in a way that cloud events broker, it is like agnostic because this is only actually dealing with the triggers, which are looking for a particular type of an event. But both of these services, tecton and captain here have their inbound and outbound, which are sort of dealing with that conversion of events into a format, which can be used by each other. So if tecton has this outbound, captain has this inbound and what this is going to do is basically transform the events coming from tecton into something that captain can use and understand. So that was one of the thing which was, I like the thing about Knative, which is really interesting is, it is working with cloud events as are. So we only like, we can set, or a person can set triggers for Knative service, which will be running inside of, or maybe like as a part of our plugin. It's sort of that interoperability also between different operating, I mean open source tools operating together. So the user would have to set up these triggers, but those triggers won't be inside Jenkins as a thing, but they would more be inside like the Knative service, which is running as part of this plugin. But the only thing again is about these in-mounds and out-bounds or those are specific, the how you mentioned the direct interoperability system. So again, having those agents and that kind of system. So that is one thing. So it will still be indirect, like in our case, with cloud events, it will still be indirect interoperability because what will happen is, so imagine extending this cloud events broker to like one more row, sorry, one more column, okay? You extend this to the right, you copy paste this captain thingy to the right and just replace captain with Jenkins. Now it's easy, but I'll tell you what it will look like. So the captain bridge and tecton dashboard is the front end. The CLI is there, forget about the CLI, but that will be the Jenkins front end, like that will be the Jenkins port 8080 from where we can check the Jenkins UI, okay?  And these are event listeners with which we can use, which tecton can use, and then these are created on tecton side and then consumed by the broker where a trigger object is made by the Knative cloud events, by Knative, and this trigger object is created with the webhook URL given by tecton, okay? So that's what is triggered. Same thing is with captain inbound. Do not look at the, so these two are technically the same because they are both webhooks, okay? Now here tecton cloud events is actually, so Andrea, I cheated most of the work on this, but I did work on this a little bit. The cloud events, what do you call it? Controller for tecton. So what the cloud events controller for tecton does it? It just sends cloud events. So you configure or sync where you want to send cloud events and you send the cloud events and the cloud events are sent to that place. That's all that's happening. So what is happening here is that all the events are just sent to the cloud events broker over here from tecton and the trigger is the one which is actually doing all the work here. Now to translate this into Jenkins, the captain inbound, captain outbound or tecton triggers, tecton cloud events, what it looks like instead of inbound, you would have so inbound and outbound can be translated to source and sync directly and which the cloud events plugin will handle. So right now, what we are done with is the outbound, right? You will see that we are done with the outbound and we are kind of working on the inbound stuff. So and we are trying to make the inbound stuff a little better. So in terms of the inbound, which is Jenkins as a sync. So that's the inbound stuff that we still have to work on and make it a little better. That is our next step in this process. But for now what we can do is, and I think it will be a good exercise as well, but just play with the same architecture and forget about this, I don't know if this cloud events player is very frankly, I think it might be a UI from which you can see. Yes, this is like similar to Sokai, but for a creator. Okay, so it's basically like a more sophisticated Sokai so the cloud events player view monitor and match up cloud events. So what we can do as a good exercise is we'll just replicate this entire architecture for Jenkins and then we will remove captain out of the picture and then slide in Jenkins. And then obviously we won't be able to do any inbounds right now, but what we can do is we can do outbounds. So what we'll do is we'll just start a job, a Jenkins job, simple job, and then we'll do an outbound, we'll send an event. You will have to configure a K-native trigger to say that once this Jenkins type of event comes, trigger a tecton pipeline which does something. Okay, so I think this would be a really good experiment which you can do the next week. And in this way, you can probably gain an idea what the POC will look like. And also you can showcase this to the events sake that you have done a POC with Jenkins interoperability with tecton. And obviously if that works with tecton, it'll obviously work with captain as well because in the trigger you probably have to create a similar trigger. The only thing you'll have to change in that trigger is the web hook which it's calling and the payload that is there. So I think that's the good next step you could take but I don't know if I'm just blabbering or I've answered any questions. Is this something that I'm missing out or not haven't answered yet? No, it does make sense. And like I am following because you have work insights on this and you have work with this system. It does make sense. The only thing that I'm just like looking at right now is sort of understanding that if we are, because I remember them mentioning how the inbound and the outbound is for both sort of like tecton and captain is also doing a bit of manipulation to adjust the event and the way it's coming over. So I think that it's a yes, it's a very good step and we can try with both tecton and captain as just having captain and tecton both as sort of like sending or like receiving events. For now we can just have them as inbounds. We don't have to need to take the outbound from them. We can just have them as inbounds and just the setup should be fairly simple but the part where you will have to do some learning would be the tecton triggers and the CRDs and stuff that we are using. I can help you set it up if you want and we can kind of do like a POC with Jenkins and tecton. Yeah, that sounds like a really good idea. Oh yes, I was going to say that also if we do decide in the future to sort of move with this architecture I also was wondering again going to the question of how can we enable this thing in the middle, you know, like the K-native system on Jenkins, like the cloud events plugin for Jenkins. So I'm just thinking a bit about that of how, you know, if there needs to be a script that can also start this architecture but that will also need like a part. So this is a fairly decoupled system.  Is that what you think of that, this cloud events broker would become a dependency to the Jenkins cloud native plugin? Cloud events, cloud events, cloud events plugin? No, I'm not thinking necessarily as a dependency but more or less like if we are, you know, like if we need K-native as sort of a service from inside of Jenkins plugin as sort of like this always needs to be there. It's like, yeah, maybe we can say dependency but also like it obviously can work without it. You don't always like need K-native but if someone happens to do or happens to initiate this system running, you wouldn't want to go back and set this up on K-native but they like need a system which is, you know, asynchronous and which can similar to like K-native we can handle all of this. Like have that cloud events broker. So if we end up using like after the thing, you know, some other pub sub mechanism or some queue we still have to, we might like have to make any structure or any format like cloud events because we don't have the trigger inside of Jenkins is the same for a source, right? We only have that inside of K-native. So for that filtering and then sending it over because the idea here. We'll do one more example after this. So once you are able to achieve this bit of exercise where you replace captain with Jenkins and test with Jenkins outbound and inbound, we'll do one more exercise where we replace this middle bit of cloud events broker and we replace it with something else. And we could probably discuss that next time. I'll try to figure something out, but maybe we replace this with Apache, you know, and see how we can make that work because the point of indirect interoperability is that it should all be fairly decoupled. And you're just using data packets to tell each other what's going on, what is happening and your focus is that. So from what you're saying right now, it seems that you are considering this cloud events broker probably as a hard dependency at some point but that won't be the case. So at that point when we do the second exercise, we also get a better idea of the event filtering or something if you wanna do in, on our side, what that should look like, what's important, what's, or just some simple filtering even, maybe use regex or something. We could do that on our side, but I think it's a good idea to do some, like test architectures, like in this case, like this is actually a very good idea now. If we just replace captain with Jenkins for our first go, and on the second go, we replace the middle bit, the cany it a bit with something else, like Apache or something, like a different broker. Keep this, I just checked some documentation. They have their own Kafka broker as well. Maybe you could just extend instead of completely replacing to use the Kafka broker to send things to Kafka initially and then remove after that, remove it completely and then just connect Jenkins to Kafka to TechTown or do something like that. I'm not sure how well that will work. I don't have a great experience with Kafka, but initially I think it's a good idea to go with just the Jenkins replacement, then extending the cloud events broker to have a Kafka broker as well so that you can trigger some Kafka jobs. And I'm not sure Kafka topics. My coupling was not on point. And then we can do an experiment where we remove the cany to base Kafka broker and distribute that with a normal Kafka broker. You could? No, so we tied on in like giving users the ability to choose the protocol binding. So do you guys think that like the protocol binding should sort of like the user is entering it or if like a person is selecting a particular kind of broker it just automatically gets selected? I think that's the more easy way. I think that's like the better idea. Yeah, it should be fairly easy because like you can say something like protocol binding and then in a dropdown they can select Kafka or HTTP or whatever. And then when you're creating the, yeah, it should be fairly easy. I think just like when you're creating it you have a switch case should be simple enough. Yeah, and like the UI right now it does like support sync type. You know, it has that HTTP sync and other sync. So we just need to go on to other sync and then implement the. So my like my computer battery is sort of it's like it's not really super amazing. I know I'm starting my idea. I'm my intelligent and it might crash but I'm going to try and sort of like show around. That's all right. Yeah, so, you know, like like you suggested having an abstract like a sync and different kinds of sync are just extending from it and then like developing over it. So I think that can be really helpful here because we have an HTTP sync which is extending from the abstract cloud events sync. And then we just have different kinds of sync which is designing events. So we might, we might also not need. I'm actually thinking if abstract makes a lot of sense with my, but the final product is going to be a JSON, right? Like a JSON object, like a cloud events object. The final product is a cloud events object, right? So I'm just thinking instead of doing the abstract thing, would it be better to have a sort of switch case which manages all this? Because I don't want you to waste too much time on the UI. I think that this is going to be like very, I think in terms of just making different sync classes because in that way we can sort of just separate the kind of sync. So the UI has a sync type, right? So a person can sync type and what this can do is also just sort of separate the UI sync type with the implementation sync type. So the things are kept separate. And what this will really need, if it'll just look at the place where we are sending events and see if the sync type is HTTP, then use HTTP sync class to send events. If it's a different format, the new stuff, format so we can use switch case there and then just go into classes. Because we still would have to do the, the design of the cloud event is going to look different. I can try, I can like try making either whichever would make more sense. We can go forward. Yeah, there's, I am just, I just think that right now I have a gap in knowledge because I'm not sure how the, I was just thinking, do I really even know the protocol binding and what it means for Kafka? Even I would have to just check before I say anything really because I even have to figure it out to tell you the truth. But what we can do is we can sync sometimes this week once you gain enough info on what that is. And on my side also I'll check it out. What we can do, but I think to start off with the Kafka bits, to start off with that, we can just use the Kafka broker for, which cany tibias, and we can start off with that before moving on directly to Apache. So sounds good. We may try this, like the whole thing with the power issues and the power cuts here, it's just really derailed what I had planned. Should have been more flat. That's all right. It's fine. Anytime, like when the power cuts happen, I know they must be very erratic. I'm not sure if it's the same problem that is happening in Punjab, that's happening in UP, but... People here are just lazy. There were four people who were fired over this yesterday, like in the bars in the department, because they weren't able to... Yeah, like we had a call for 18 hours straight. It went from like 12 p.m. And it finally came at like 5 a.m. in the morning. And there was one day, that was like one day and then kind of the same things happened over because they weren't able to find what had happened in that 18-slash-whatever-hour cut. So they had to fire four people. That's just this state.  But, yogi, right? I can't say much about that. But I hope you just get light on a more regular basis. Are there any kind... But when are you free this weekend? Or you can just actually just ping me. I'm pretty much free this entire week. And you just ping me when you're free and we can catch up on the release bits. And then after that, if you wanna sync on the architecture bits, I can help you with that as well. Yeah, that sounds really helpful. Thank you very much, everyone. Side note, you've already been able to deploy a SOC. So you're kind of halfway there with the setting of the vocals. I don't know what else might be needed, but for all the CRDs and all the CRDs that you need, you were able to install on K-Native is something you were able to install in MiniCube. The only next thing of you, the next thing you can do is, you just have to figure out what triggers are, how to set up triggers and all those little bits. And then after that, you'll have to figure out running Technon locally on your MiniCube and using the Cloud Events controller for it. I don't know if you need that. And setting up the triggers, which you will definitely need to fill. The trigger template, trigger bindings and whatever things are there in the triggers controller, you'll have to learn a little about them and then just create the event listeners and then give it to the Cloud Event triggers and then once, and set Jenkins as a source on one of the broker, I think. So we can talk about that sometime this week. Just let me know whenever you're free. And I'm pretty much free every week again, just bring me, let me know. And have you also like worked with Yaktan so we can also sort of try to get out just to make sure that these things are fairly similar for different systems? Not exactly. I did deploy it, but I couldn't get to running things with it. I was just, I just got a little confused with the abstractions and the wording they used for certain things. But I will probably have to check it out at some point and we can just have a hacking session and figuring out what Captain is about because as far as I know, they are like the, they really embrace Cloud Events and try to work with them as much as possible and use that as their main medium of communication. Kara, do let me know if I'm going wrong here because I feel you know a lot about Captain compared to what I do. I don't have much of an idea about it. Actually, I was thinking that Mauritius would be the person, would be a really good go-to person to ask about. I think in his new work, he will be working with it and focused on it. So I feel like he actually, of all of us probably has the most context and knowledge. Yes, yes. So maybe in the next meeting, what we could do is we could have like a captain session after the hacking session maybe and figuring out stuff, whatever questions or anything you might have about Captain, we can ask them to Mauritius when he comes in the next meeting. You can make it a point to call him for the next meeting for the captain discussion. I'm not sure, but do we have events in meeting today? It says August 16th. Let me check that. Yes, it's August 16th, the next one. Oh. Have they changed to monthly format? I don't think it's, I don't know what I'm just gonna go on with, let's say that's the summer. I'm probably, but I'm not sure. You might know more about it. I think that is exactly correct. It's due to the summer. We did the same thing with the interoperability segment. So I also like I have like the, started with Jenkins as the same again, the one, again, like the one thing is this setting up the, maybe I would say triggers because we have been talking in terms of triggers for K-native. So triggers here. And that's why when I was, you know, like mentioning like that dependency with K-native, that one thing was leveraging triggers that K-native has because yes, it will be easy to implement it inside of Jenkins. But if we are already working with another sort of system that is natively made to trigger and filter based on a cloud events metadata. I think my question here would be that what should be our sort of dependence on using any form of, or designing any form of triggers inside Jenkins as a sync. And what I mean triggers like more specifically like filters and just triggers both included. Specifically cloud event triggers though. Yeah, that would be Jenkins as a sync, right? Mm-hmm. So, yeah. Wait, no, I'm, yeah, yeah, yeah, yeah, yeah. Jenkins as a sync, yeah. Yeah, so probably in that one sync, what we can do is we can have a object called triggers, which the user can set up and then certain, like if you, if in the sync, you say you want to create three triggers with two, three different things and the first one would be something like, you know, it's just start job one, second would be like start job two, probably start job three, but you could do that like, and I think before we restart, we'll have to kind of like redo the UI, move it to manage Jenkins and do all that sort of stuff. But yeah, we can start off with that. When you're gonna redo it, we can, while configures sync, we can have like these boxes for triggers and each trigger will have, you know, a particular project endpoint or like a build job or run on Jenkins pipeline, like do any of those things. Yeah. So yes, to work on that, I would say that most of it is like sort of moved out, but it's not like very clean because it's like just rushing over and like running it down. So still like I would move probably like everything and then design the idea with Jenkins as a sync, specifically aligned with triggers and filters. Yeah. I feel like there's a lot of stuff that we need to do with Jenkins as a sync. It's probably a better idea to do it in some time as we understand, you know, the architecture base itself and how the sync would be used and getting started with the architecture with the cloud events broker and everything is a good place to start off. Like once we start understanding the one flow, which is Jenkins to TechNorm, then we can start understanding the other for this TechNorm Jenkins and what that would look like. And we can get some idea of, there was a plugin, I think the events plugin or something which was mentioned on the design document, initial design document and we can gain some, we can get some help from that key whether how we can, you know, design that part or if we can just use the implementation that they've already done and kind of refactor it for cloud events, I think that would be a good step ahead as well. Yeah, yeah, that sounds good. And most of the triggers for this, like with the gainator broker, they're usually set on the header fields or not the headers, I would say the metadata about the event. So do we still wanna sort of have that structure, probably like in this introductory and the starting out phase, wanna keep the filtering option for the body or the data specifically of the event as well? Yeah, we should allow the user to filter everything. So by fields, we should allow them to filter each field individually with a different filter, each part of the header, each different header with a different filter and then the body itself with a different filter, like the body contains this, this, this. I think we should allow the user to do that. It'll be very, yeah. I'm sorry, go ahead. Yeah, because if we just allow only a few kind of filters, like only the header or some parts of the body, I don't really need to know that, but just the header, I think it'll be good for to start off, but we should allow them to do everything. I don't know, I don't think it would be that hard even to just do the body also. So, I don't know, yeah. So if you guys can see my screen right now, we are looking at, so we're still inside of the POC and we're looking at the designing of the triggers for depton, so like depton outbound, yes. So like the events which are going out from depton, and so, you know, they have this, let's see, so they have like the bindings, they have like header.matc type, this is the C type that an artifact was published. You know, they're doing like bits with expression, replacing the registry, whatever, and then they have like these bindings where they have, okay, the name, this is the name like SH Captain Contacts and body.shCaptainContacts. So this is like, this is the binding with like the event data, whatever is present inside of the event body. So like obviously here, it's like that they are aware of the kind of events which it's triggered from depton. And so like the entire body and the entire type, so I think that we can take reference, some like somewhat reference for this, but for us it's going to look very different because we obviously can't just like give them like bindings like, okay, or just like filters like, okay, this is going to be inside of the body and then body dot, whatever, because we don't know where it's coming from. So that's also one thing that we have to think about of how we can allow you there to go very modular with whatever filters they're setting on the body because our sink is agnostic and it doesn't know how to par, it knows how to parse it, but it doesn't know how to find that particular piece inside of the body. That's one thing that I've been thinking about. Yeah, if you remember we discussed this last time with the CEL interceptor. So we discussed actually, we probably did though.  So what is happening with that they are using an interceptor which is a common expression language which we saw last time and the language that they're using over there with the header dot, match, something, something. So that language is the common expression language and I don't think they have a Java library so that we could use, which we could use but it is definitely an idea with which we can go ahead. So instead of CEL we could use something else for filtering and we can obviously start off with something else, like just simple matching, we don't even need any kind of library, but in due time what we can figure out is what we can use for this sort of, data extraction from the cloud events which the users can use ahead in whatever triggers they're using. So in this space what is happening is that they are binding certain variables to certain, so they're binding certain values to certain variables and then to run in their pipelines. So what this allows the user to do is that the dynamic nature of the pipelines which is changing the variables and running them, the changing the variables part it's completely done by the triggers themselves so they don't have to, like the DevOps guy or the whoever it is, he doesn't have to think about it. So this is definitely like some feature which we should have in some, whenever we are done with the initial implementation of the same thing. So once we reach the trigger stage and we are able to do match, at that point we should figure out what do we need to do for this value. Yeah, because I don't think I'm understanding correctly but the interceptor that they're using is more specifically for the matching but like the bindings is like when we were talking about extracting maybe the job name from the event body that's coming for Jenkins, you know. So Pecton is like, okay, I have completed this artifact and this is now what I want, like I wanna start a job with this name. So that's something like maybe body.jenkins job name and that would have the name of Jenkins job name and then we would trigger a job like using that particular variable. So the interceptor, I'm not sure if they've used it inside of, I mean, yes, we can use that. Obviously it'll be used inside of the event body but that's modularity of extracting specific values. I think that's one thing that the system for the POC with Captain and Pecton, yeah, like the inbound is sort of helping with that. They know what's coming over but we don't. So as we move forward, we will obviously have to give examples of how to use this plug-in with different systems. So at that point we'll have to give examples like what it would look like to use a good Pecton and there might be an examples directory where we can keep this stuff and we should do that. And if you notice here, this part of the eventing is non-dynamic, like they know where certain things are like the trigger ID, the context and all. So these things, we need to be sure of. These are some things we need to be very sure of. That's why the format that we're using for the event in the cloud event also matters a lot. But I think we can actually take this conversation ahead at a later date as we, you know. So right now we're just kind of getting acquainted with this. So I know like there's like ideas flowing and all, but slowly as this kind of, you start getting used to these ideas, you will figure out the right path today. So it's good that this is simmering in your head right now. But once you start working with the architectures and stuff, I think you'll get a better idea of what stuff should look like, what it should be because you would have done enough for, like you would have seen enough things to know what needs to be done ahead. Like right now you're looking at these tecton triggers, like you work on setting them up. At some point you'll figure out, okay, captain inbound outbound, this is how it works. Then you'll get a better idea of like how the cloud events side, cloud events plugin side of things should look like. Because users here are using these things, once they switch over to something else, they'll have a similar concept in their head and they'll also be able to work with the same concepts more easily. And it will be easier for us also. Yeah, that's a good idea. All right, well, thank you and thank you. Well, everyone had to go, but also thank you everyone and thank you, Kara. Let's move forward with the stuff we've talked about today. Let me know if you're free this week and we'll discuss some of the stuff and I'll be setting in some of the stuff that you need to go forward. Yeah. And congratulations on getting first part of GSOC done. Congratulations. Thank you.  So like, thank you for all the work you put in and for being amazing. Thank you. Thank you for being amazing and working on all of the stuff. Where's Beth and I? Yeah, you've done fantastic work, Shruti. Thank you so much. Thank you. And we will continue doing this. Yeah. We surely will. All right, good meeting guys. And I will be in contact over the week and thank you very much for being here and thank you very much for your work. Thank you everyone, bye.