 Okay, welcome everybody to Mycroft Developer Sync August 14th, 2020. So when we last left our Infrared Group of Developers, we were discussing potentially having a regular meeting to go over pull requests from the community. Part of that being motivation for that being establishing a regular setting a limit, at least on the amount of time my developer will have to wait before getting an answer to their pull request, whether it's yes or no or we're going to kick it down the road. But in any case, at least trying to get back to every pull request in a timely fashion. So I think we can definitely discuss that. Is there any other agenda items that people want to talk about today? Yeah, I reviewed the pull request we discussed yesterday. I want to talk about that a little bit. And what was the other thing? I think the other thing I can just work out with Ken offline. As far as where on the device, the NAS device, these things are going to, these way forward, you're going to live. But yeah, so I think yeah, that's it for me. I just wanted to make sure people saw the call really come up to Monday. Thank you for preventing installation and installation skills. That seems like a pretty cool function to honey. Yeah. Okay. Do you think this is going to impact your 20 oh eight release schedule? I mean, remember that it's not critical to get it out on a particular date, but we do want to keep up the practice of doing regular updates. Yeah, I need to. It depends on how much how many years of breaking changes we want to get in. So I mean, we can, at any point in time, we can cut the 20 oh eight release, but it's just like, you know, it isn't worth it holding off. You know, this is like 10, 10 items that we want to get in there before the, before a breaking, breaking release, like, which of those do we definitely want, which of those don't really matter and which ones we hold up a release for. So I need to have a bit more of a look at that. I can update on Monday. Okay. Great. So that seems like something that we should discuss with, you know, but at least with Chris and Ken and, you know, with the community as well, as to, you know, what stuff you want to add to the major release, the 20 oh four release and then the 22 release. And then, you know, and do we want to turn it into a 20 oh nine release? You know, for example, yeah, 1908 came out in September. So, you know, it's not, it's not unheard of that, you know, we get not a little late of trying to get something in. Yeah. All right, well, let's tackle the PR issue first, because that's the most specific thing. And it's the most, you know, time sensitive, I think. So, Chris there, you did a review of this major pull request. What are your thoughts? So now that I reviewed it, I have different concerns. Current. So what we, what we need. This functionality is knowing when a service is ready so that we can know that the device is ready. This goes up your video because you're breaking out for me. I'm not able to hear you consistently. Okay. Is this better? Yeah. Okay. So, so I got to look at the PR. It basically what it does is it introduces. This class that does more than what we needed to. Meaning it checks for errors and starts and stops and other things. All we need to really need is ready. And there's not really anything that uses it. It's kind of like a framework that, you know, right now, the only thing that uses on air, for example, is just a logging that there was an error. The only thing that uses start is, you know, logging that it started the only. And I'm also concerned about how we're checking for readiness. It looked like there was a some sort of loop that, that checked for ready state rather than maybe using events, ready events to say, to tell that we're ready. So those are my two biggest concerns about it. And I think that's one of the things that we need to look at. And I think that's one of the things that we need to look at after seeing it. So I guess my question is. Should we. Since we have. The potential of some sort of status service. Coming up. Should we just implement a simpler device or. Or are ready. Bus message for now. And I think that was kind of already done by Chris before this was done. So I think that's one of the things that we need to look at. And I think that's one of the things that we need to look at. Do we go ahead with. Something that. I guess may or may not be used. And that's. My concern with putting something like this in. Is that if nothing uses it. It's potential and nothing will ever use it. You know, I like putting things in and we need them. Not when we think we might need them in the future. So. Those are my concerns. So why was. Why. Compelled to. Create. This large amount of code for nothing. That that confuses me. Well, I mean, I think. And I talked to guess about this a little bit yesterday. After I did the review. You know, and you mentioned that, you know. It's a good idea. And people, someone might use it. And sometimes you're, you feel compelled to put something out there that people might use. And look, sounds like a good idea. And I've done this before in other code, but the lesson I've learned from that over time is that. People aren't always going to use things you think they might want to use. And to only implement things that you need rather than things you might need. But that's not to say that other, you know, people don't still think that something might be useful and want to put it in there anyway. So I think it's, it's a, you know. Cause it's just been, you can, you can elaborate a little more. Yes, maybe on. On the thought process behind it, but that's. Kind of what I get out of it. Yeah. So I think. A big part of it, I think was, was thinking about groups that are using system. D services or want to use this in D services. So. Jinx is doing the Microsoft OS. Is being on the system D. And it's potentially something that will be useful for us, but, you know, we've got to decide about how we want to structure that. And so. There. We also recently added these service books, which are, you know, callback in each of the services that, that can be overwritten. To provide that system D integration. Which line up with the status. Hooks that. Chris is talking about. So, you know, on. Start on ready on. Error on stopping those kinds of things. So. Yeah, it was to kind of tie those things together. And give up, give a method of, of. Querying. A service for. Whatever state it's in, not just readiness. And. But in terms of. This PR, the only. Piece of this year uses is that. Checking readiness. And it does that in a loop. In. The. Inclosure. Because it basically waits until. Everything should be ready. And then. Start the loop to. To check that it actually is ready. Rather than. I had with it actually. You mentioned that enclosure service is there's. Inclosure service itself didn't have, didn't use the stat, the status class. And the bus didn't use it either. So it was really just three of the services of the five that were actually using it. And according to the comments, I saw that there was an implied status. And the enclosure and bus services, which. Seemed a little, I thought, you know, I thought, I would think we'd want to be. Consistent with how we apply the status across. Well, so in terms of, you know, your comment about only wanting to implement functionality that we need, it sounds like somebody else has a need for this functionality. Even if it's not us right now. But. In terms of this supervisor process that we've discussed, you know, before that can, you know, make sure that if things, you know, get broken, you know, we can restart them or whatever. Would it be, you know, would it address your concern if we went ahead and said, before we actually finalize this, we should implement it in a supervisor type of system, which I think would address the asymmetry in those couple of services that aren't using it. And would prove that it actually is the right thing, the right way to solve the problem in the context of having this, you know, the supervisor. Would that address your concern? I mean, I think it's expanding the scope of the feature by a fair bit. But. But, you know, if that's the direction we're going to, maybe it's worth looking into. But so. As. I guess I didn't understand. So I still don't get what the need for it is. You know, everything you said is was potential. That I heard at least potential need for it. I don't understand how this integrates with system need and how that works. I guess. Yeah, well, I'm not. I'm not a system D. But it's simply. Is an interface between system D and, and my cross core. Sorry, what was that? Is that what this is? It's providing an interface between system D and my cross core. No, the interface is through the services that are already included. So this, this ties into those services. So that you can across the message of us, you can query the status of, of any service. This is kind of like opening up all the services to being able to get their status over our message bus. Yeah. Okay. How do we get that status now? We. Well, so at the moment, you know, for example, when, when my cross boots, it, it does a bunch of stuff and eventually. Trains, it's intense. So each intent is a little neural net. And when it's finished training, it sends a message that says a finished training and then my cross says great. I'm ready to go. And so based on the assumption that everything before that should have. Should have happened. It just assumes that it's ready. At the moment, we don't check the status of anything. Pedacious could be completed, but other stuff could have broken or not be ready. And yeah, how do you determine that today? We just don't. Okay. And so this solves a problem in that moving forward, it could be used to determine if all the services are in an operable condition at the present moment. Is that correct? Hold on. A subset of what is in this PR could be used for that. This does a lot more than the problem we're trying to solve. It's not. It's shot. It is that. And then you kind of agree from that. Yeah, I'm just confused because on the one hand I heard it doesn't do anything and then I heard it does a lot. And I'm not sure if it does a lot of nothing or nothing, a little of everything. What does it actually do is what I'm getting at. Well, why would I be compelled to use it? It sounds like it gives us some additional functionality regarding querying the, the health of some services. And I get that it doesn't give you the health of all the services yet, but it gives you a consistent interface to solving that problem is one of the things I'm hearing it does. Chris, you mentioned it does a bunch more. What bunch more does it do? Well, okay. So the reason we got here is because we needed to know when each device was ready. Are we spent? Sorry device. Each service was ready. So we can have a device ready state. But this does more than telling you if it's ready. There's a, an error state. There's a started state. There's a stopped state for states that are included in this. That are not used right now and may or may not be used in the future. Well, wait a minute. Let's, let's just stop there for just one second. So in the absence of anything right now, right? We don't have anything that we can rely on other than the fact that the Dacia says everything's good to know whether everything's good. And as services are running, nobody guarantees they're not going to run out of resource. They're not going to crash and burn. They're not going to break. So periodically a super hypervisor could go and say, are you ping me every, every minute? Are you still alive? If not, I'll try to restart you. So you're saying it offers that additional functionality. And yes, why would anybody be using something that doesn't exist today? That makes sense. So what else? Functionality. No, I understand that, but it gives you an interface to accomplish that functionality. It doesn't. It doesn't. No. Oh. Interesting. So even though it has all of these additional, like you're down versus you were started versus you haven't even started yet, it doesn't give you the ability to query that information. Okay. I misunderstood what you said there. It doesn't give you the ability to query the, the readiness state, but not the other states as it's written right now. Okay. Or is it, it would be nice if it did. And I find that it's, it would be nice if it did. And I find it a serious. There's, there's methods for each of the, to query each of the states. So you can, you can. You know, he's alive. Hold on. Well, let us, let us step back and look at this in a little bit different perspective. This sounds like functionality. That would be beneficial to my craft core. Are we all in agreement on that? I don't know. That's part of my problem with it. I don't know. And, and so what I'm getting at is that. I'm not even here. I'm not, I'm not, I haven't gotten into core of that deeply except for the first couple of weeks and I looked at it and it looked pretty. You know, it's been, it's a hodge podge, but it's okay. It's, it's, it's pretty good. So, I don't know. That's part of my problem with it. I don't know. Okay. And, and so what I'm getting at is that. So, um, you know, what you're saying is that there's some functionality that could be exposed here that would give us the ability to have a hypervisor periodically check on the health of the overall system. And this accomplishes that. And maybe it's not completely done, but it's a step in that direction. And so being naive, I'm saying gee, you would think that would be of benefit to my craft core to be able to know that service blah went down. The thing that I heard so far that's a little disconcerting is obviously it's in a loop, which it's probably off in a thread. And yeah, it could be event driven where it just is told to wake up with a one shot or whatever, repeating timer every 30 seconds or every minute. But if it's giving us an interface into the services to in the future, be able to query them and determine their health. That would seem beneficial to me is all I'm saying. I don't know enough about right now. I'm not telling you health. It checks if it's a, there's a ready check and there's an alive check. So maybe I don't know, but those are the two checks that are currently in this class or yeah, in the absence of an alive response means you're not healthy. Right. Yeah. Maybe I, you know, I'm, I'm a little different being alive and ready. Right. Okay. So it seems to me that this is running and responding and raising services. I'm not ready to do it full functionality. Okay. I mean, there's more statuses too. There's going to be, you know, I'm going down or I'm going to critically low resource level or whatever. So, you know, a stake in the ground that could be expanded to handle all of our needs moving forward with would not be bad. We mentioned the audio service crashes periodically. Be sure it'd be good to know if the audio service was down or maybe take some appropriate, you know, corrective action, but I'm confused as to Chris, you're not in favor of this poll request for some reason. I'm guessing by reading between the lines. So my question to you would be why. So the reason being that a implements a bunch of stuff that may or may not be used is one reason. Another reason is we've talked about having a service. Some of these things. And we'll, we'll just duplicate whatever that service does. You know, when it's right. Well, it recludes from having to write that service. I don't know about that. But. We haven't really got the service and what would we do? So we don't know. Okay. Well, here's what I'd like to do then. I think, I think we can resolve this with some documentation. So, if it's not obvious what this thing does, then it clearly needs documentation. So I'd like to ask the implementers to write up a brief description of the architecture of the system, the motivation for implementing it the way it is implemented, how it is being used currently and what the expected roadmap is for how it will be used in the future, because it does look like it's a partial implementation. And not complete implementation. And, and from your side, Chris, there, I'd like to get just, you know, a sketch. Like three, four sentences at most of what you'd like to see in this supervisor, hypervisor capacity, you know, that we've been talking about. Because I know we haven't spec'd it out yet. It's just an idea. And I think we can agree that it's a good idea. But, you know, I'd like to get from you your top, you know, high level requirements as to what the capabilities need to be. And then we can share those and we can see if, you know, if that is something, if that's a destination we can get to, you know, starting with, you know, with this PR. Okay. I can do that. Awesome. Yes. What do you think about the reasonableness of my request to the authors of this PR? Yeah. Yeah. I think that'll be. Excellent. Fine. I think that, you know, in the future, I think this is the kind of stuff I'd like to, you know, well, this goes back to the discussion we had yesterday of, you know, not wanting to slow down innovation, but also, you know, when it gets to a certain point and it's going to become real, we do need to, you know, fully understand what we're getting into. So I think, you know, sometimes you just have to go down the road to see where it goes. I mean, you know, this looks like one of those cases and let's see if it's, you know, if it is going to meet our needs on the long term and, or, you know, and maybe it's, you know, maybe it's a little of both, right? Maybe, you know, it sounds like there, there was a group out there at least that is using some capabilities that we don't currently need. And maybe this serves, you know, their purposes and that might, you know, be a good enough justification for including it if it's not, you know, gumming up the works in some other way. So, yeah. All right. So now let's talk about the process for, you know, trying to regularize this and make it, you know, less ad hoc. Ken has proposed that we meet on a monthly basis to review the PRs. I know that Chris Gisling goes through the PRs on a, you know, I know that Chris Gisling goes through the PRs on a fairly regular basis, right? Like almost a continual basis, it seems to me. So, so how do, so what do we actually need here? What is, what is it that we're missing? Because it doesn't seem currently that there are more PRs than Giz can keep up with, but maybe that's just my perception. I don't know. So in my mind, there's, there's different types of PRs, right? Like if it's a bug fixed PR that just is a few lines of code, we don't need a bunch of people staring at that and, and dissecting it probably gets them is more than capable of, you know, reviewing something like that or either I am or whoever, right? I don't think we need a big meeting for that. I think it's these types of PRs, which are bigger changes or functional changes or something like that that need more attention than maybe just one person looking at it. Whether that be guys or me or anybody else, you know, because we want to make sure that bigger PRs like this are, like we said, following whatever direction we want to go in. So I think maybe before we say, we should probably, you know, categorize them in some way. And maybe we, maybe we can even use the PR system to do that categorization, right? And we already have labels on some of these, you know, this label as a bug, for example, you know, I, you know, I'll look at some of them depending on what the bug is, if it's something I know about that, you know, guess does a lot of reviewing these and, and merging them without any of my input. And I don't, that doesn't bother, you know, so, but, you know, if it's something like this, then I think we market differently and it goes different brands. And also as a counter to the monthly meeting, you know, I was wondering if this was one of those, if it would have made sense to, for me and Gess and Ken to carve out, I don't know, a half a day on Monday or a half a day on Friday or a whole day on Friday or Monday or whatever to go, you know, to dedicate to going through these. So at least on a weekly basis, you know, we're going through what's there and if people have responded. So it's pretty regular. And then if there's something that comes out of those reviews, you know, that day that requires discussion, then it comes up in this meeting. That's just an alternate solution that I was thinking of. Yeah, I guess it depends on how frequently these issues are coming up. I mean, it could just be that we raise these issues in this discussion and we decide whether, you know, we can make a decision quickly in one of these meetings or whether we should, you know, make a dedicated meeting for just that particular full request. And, you know, how much, how much of our resources, you know, we need to dedicate to it. Like, you know, does this impact something that's on our roadmap or conflict with something that's on our roadmap or partially implement something that's on our roadmap, you know, that kind of thing, you know, and we need to have a more in-depth discussion. Then, you know, if they're not coming in at that rapid rate, then maybe we should make them one-offs. I do like your suggestion of, you know, getting to it within a week. I think that's a lot more responsive and I feel a lot better about that. But, you know, I guess is seeing these all the time, maybe, you know, we could just carve out a small part of the meeting to, you know, to just note to those and decide whether they're, you know, controversial in any way. Yeah, I mean, that's been pretty good about, you know, something like this, like, hey, you should probably look at this before we merge it, you know. You know, he's already mentioned that, you know, if he thinks it's something that's more than just a few line change, he's like, hey, he pings me, he's like, hey, look at this. Maybe that, we should continue, you know, can get us to be the first line of defense and if he sees a PR that looks like something that, you know, needs a little further scrutiny that he would usually give, then, you know, and maybe we go from there. Yeah, I mean, I'd like to get involved in the process before it goes too far down the road though, because this has been going on for, I don't know how long they've been working on this, but probably about a month at least. And I think it would have been good, like all these concerns that have been raised now could have been raised at the initial outset, right? I think, because, you know, I was watching some of those discussions and, you know, if I don't have, you know, the same knowledge of the code base and, you know, where we are right now is you, Chris, but, you know, what I saw was exciting to me. I'm like, oh, hey, great, they're addressing a thing that's going to, you know, make it easier for us to do this thing that we already know we want to do down the road. So from my point of view, I, you know, I looked at it as, oh, hey, they're, you know, this is going to help us out. But I understand that, you know, a finer level of understanding of, you know, the details here. And so, you know, maybe that's a discussion that rather than, you know, passively hoping that we, you know, look at it and take part in that, you know, if it looks like it's going to be something that's, you know, somewhat major, you know, we highlight it explicitly at one of these meetings and then take it offline if we need to. Does that make any sense? Yeah, it does. And, you know, part of the reason, you know, something else would be worth discussing is part of the reason I hadn't looked at this until now, because I was busy with doing other things and I never carved the time out to do it. You know, guys kind of prodded me along and I was like, oh, I should probably take a look at this. And that's kind of what prompted all this discussion. So I was wondering if there was something we can, like the guy said, like to me, you know, I could just carve out some time every, every week to make sure I get to some of these that need attention rather than, you know, trying to wait for some break in my, you know, the work I'm doing to remember to look at them. Well, yeah, it might not even be at the level of a PR. Like some, I think some of this started, you know, in the Mattermost chat channel and, you know, things we've discussed there and other places, right? Not just through the PR. I don't even remember them. Maybe it was going to be pointed out better too. You know, even if this one in particular didn't like, you know, they could in the future, right? And so that's, you know, the earliest that we can detect something that we might have strong opinions about or that are, you know, that might be a major level change. And the earlier we can say, oh, well, you know what, we haven't actually laid out to the community what our plans are in this particular regard, but let's just take, you know, a half an hour and sketch out what we're thinking and then, you know, make sure we get that out there so that, you know, they can be considering that, you know, as soon as possible. Okay. So the concrete action item result of this is Chris wants to dedicate a particular, you know, time in the week to, sorry, Chris Bayer wants to take up, you know, dedicate some time in the week to, to just reviewing these sorts of issues. That's great. And if there aren't any in a particular week, then, you know, get the time back for other things. Yeah. Do we need to have a... Well, once I go into history, I don't think it'll be time-wise to... Yeah. Well, and so that's another question. So there's two more questions. One, do we need to, you know, revisit Ken's idea of a periodic, like whole group that reviews these things, or should we continue to do that on an ad hoc basis, but just try to get involved earlier from now on? What do you guys think? I like getting involved earlier. Chris, what percentage of PR do you think require this sort of attention that we, I mean, how often do you think we have a PR of this magnitude that's worth this kind of discussion? I'd say it's a small proportion of overall, but then, you know, having a quick look back through, you know, the open PRs that go back to 2017. Yeah, early 2017. And, you know, there's some really good stuff in there as well, like, you know, support for multiple hot words. Already exists. We just need to actually engage and review and rebase it and get it ready for the latest call or enough of the stuff. So, like, there's real functionality in there that we just haven't had time to get to. Okay, so that was my second question was, how big is the backlog? And I guess it's about three years long, at least. So that seems like a great motivation for having a regular meeting and trying to get through that stuff. And, you know, get caught up on that because, you know, having a three-year-old backlog as Ken has pointed out in the past is, you know, not terribly useful. So, you know, because, you know, well, I guess in all of these cases, we're assuming responsibility for these things, but we may potentially be putting off community members who would be, you know... Yeah, that's the concern is it's demotivating people we should be motivating. Yeah, there's like 30 of these out here. Okay. Right now. Great. Well, it sounds like if we tackle one a week, we'd get done with them in less than a year. Yeah, I think... So there's 30 open bull requests in Minecraft Core, but as we've discussed, we have quite a number of repos. And so, you know, I think we could then cycle through in 10 passes and, you know, a number of other repositories to look at what exists in there. I think we've got a few. Okay. Well, Chris, well, I'm not sure if the right way to approach this is. I mean, it'd be great if somebody could take point on prioritizing these in terms of, you know, what your thoughts are regarding, like, the controversy level of it, the... Useful man. Yeah, the utility of it, you know, potential impacts on performance, you know, like, will this even run on a Raspberry Pi, you know? Which is not the only platform that our software runs on, but certainly the impacts, you know, our internal priority in terms of, you know, we wanted to use it for the Mark II, for example. So, you know, would it make sense for GEDS, for example, to take a stab at these? Or does everybody want to take a, you know, take a gander through and just kind of, you know, highlight some that they think are important or interesting to look at? And we just create a queue of these things and go through, you know, with, you know, put a box around how much time we're spending on it because we need to, you know, constrain that, I think. But maybe spend a little bit more time, especially around issues that are central to getting the Mark II out the door, right? So, for example, having multiple, you know, wake words is very interesting, but it's not critical to getting the Mark II out the door, right? So finding the right balance, you know, of that, I think will be important. But there are, you know, there are very well maybe things in there that will assist us in, you know, getting to a more stable and shippable product. So, you know, likely not, I expect most of them will be, will be interesting and fun and useful functionality, but not really required functionality. But we should take a look. We should at least know. Yeah, I wonder if the three-year-old ones even still apply, right? Some of these things that are really old, I mean, maybe they've been fixed another way, or they're, you know, you know, or who knows. Well, some of the code has been stable since then, so they could still apply, right? I try and close the ones that no longer, like I have a pay-giver now again, and I try and close the ones that really don't apply anymore. But, you know, there's a number here, like if we do go to the plug-in system, there's half a dozen, you know, STT and TTS CRs, but, you know, just different systems that people wanted to add in that never got reviewed. And so if we move to the plug-in system, then we can close half a dozen of those. There's a few language ones, which I should check in again because that might now be lingua franca. But yeah, the others have probably more, they've probably fit more into the, like, you know, features that are not critical to Mark II, but will be interesting. Okay. Mostly. All right, well, since I expect you've got the best handle on these things, why don't you come up with a plan? Tell us how much you'd handle this. We can discuss that as well. That's what I call management. Yeah, so I think one of the big things that I've been hearing is that we need to improve the tagging system for PRs and, like, the categorization system and the way that we do that through tags and that, you know, we have bug fixes and features, essentially, and then the bug fixes are, like, quick things versus complex and features that are probably just roadmap versus proposals or, like, you know, something else. And then I don't want to go too deep into a, you know, a five-point rating scale of importance, but, like, you know, maybe something that's, like, a flag that's, like, yeah, we probably want to look at this quickly so that this can fit with the rest of them. So maybe I'll have a look at that and go through the backlog and categorize everything based on those. Yeah, I mean, that's an interesting idea. If there was a way that I could just scan through PRs and go, oh, hey, this is something I should probably look at. You know, by looking at a tag or something, like, then, you know, that would certainly be helpful to me. And we should prioritize bug fixes over features, right? Unless the feature is critical. Yeah. All right, yeah, so I'll do that. Okay, great. Okay, so that was two issues. We're at 52 minutes. Did we have a, well, I guess we started a bit late, so maybe 42 minutes. What, what was our other issue that we wanted to talk about? Was there another one? I thought there were four. Do you have to use ParkCharm? No. I, I, I got a free license, you know, like a temporary license. So I thought about checking it out. Is it worth it? Well, I was just going to say they just added a PR function. I can, I can look at and view and come in and stuff on PRs right in my editor. And compare it. There's some pretty cool stuff they're adding to it. I think it's worth it. I do, I spend 90% of my time on my IDE right now. Because it does so much. Yeah. I also have a professional edition, which is whatever. Yeah. Whatever it is. Oh, I don't know if this is one of them, but do we have a rule set of wax that we want to kind of focus on a little bit in the past? And I'm now starting out there. Yeah. About the agenda. Terrible. You have a video rule. So black. Black is black. There's no, there's no configuring black. Yeah. Yeah. You just, that's part of the reason we want to use it is it's opinionated. And there's not a lot of things you can, you can change. So yeah, as far as that goes. Yeah. as far as pilot goes, that is maybe an ongoing discussion. Like I've been running pilot on a bunch of things I've had and I've got a running pilot RC file or config file where I've configured a couple of things that didn't make like black did one thing but pilot expected another. So I had to ignore that because you know, you were just, little things like that and as we noticed though, we can keep this and you know, pilot RC, probably we can put it in the DevOps repository or something. So everybody can download it and use it. But you know, like right now I try to get a perfect score on my pilot stuff, you know, unless there's something like that that I need to change. So we could also discuss and we don't do it right now, you know, what is acceptable from a linting standpoint you know, some places I've worked before said, you know, as long as you have a nine out of 10, it's okay. But you know, but if you have nine out of 10, it could be that you're, you know, what did you decide not to fix? You know, so I'm not, you know, where do you draw the line until, you know, what, you know, another thing you could look at is that there's different levels of pilot issues, right? There's errors, there's convention, there's refactoring, we just, you know, ignore the refactors, you know, yeah, so there's different ways to look at how we addressed, how we enforce, you know, linting on our code base. The nine out of 10 and places where I've been is because with non-strongly typed languages, it's a necessity. There are objects you'll pass around that are anonymous and pilot won't be able to catch it. So an order just won't cleanly compile. Code works fine. And it usually happens in factories that produce polymorphic output. So yeah. So pilot will check for that though. Well, it's not capable of catching all cases, which is why people that are adamant about pilot realize that nine out of 10 is probably gonna be the best you're gonna be able to get. I'm not a big fan of linting in general, but yeah, for Python code base, that's just me. I'm sorry, Ken, I didn't hear you. You're not a big fan of what? Linting in typeless languages like Python anyway. It makes people write code for the purposes of cleanliness at the expense of efficiency in certain cases. Well, it sounds like we don't have some clear rules to pass on to the community here. So I think we should work on that. Yeah, I think with black, I think it's easy. Just run black on your code. That's pretty cut and dry, but with pylint, if we wanna talk more about that, we certainly can and what our expectations are. Once we know what they are, I can code them into CI and it's just what it is. But we like to communicate them before the hands of people, they want to link their code before they submit their PR, they could do that too. Oh yeah, that would be my expectation. And I think that we should give the community and ourselves probably a good three months of heads up before we implement any kind of strict policy based on pylint or black or whatever, in terms of integrating it into the CI system. Yeah, and right now, I've been putting comments in PRs, for example, like I know the last couple of left on, I was like, oh, this probably wouldn't pass the pylint test. You know, just kind of hints towards it. And I'll ask to do black if it doesn't look like it's blacked. So that's that. Can you pay your pylint file? Yeah, I'll put it in the DevOps repository and let y'all know when it's there, so you can all download it and use it. Yeah, we'll give it a try. So we need to take a JIRA ticket to make concrete our our linting requirements for the CI system. And then, you know, we need to probably take some sub issues in terms of rolling that out to the community and, you know, we're reviewing it internally and making sure we all agree on that process and that sort of thing. Okay, congratulations. You snuck in an extra issue. All right. So that's it. Actually, I went back and reviewed our notes. We don't have any other topics on the agenda. So unless there's any other surprises, people want to bring up, we can call it for today and pick it up on Monday. And next week we're on Monday, Wednesday and Friday, normal time, right? Correct. Okay, good. And again, there's a little bit of a distinction between the meetings. Can we just go over that real quick? Monday is different than Wednesday and Friday? Yeah, I think Monday, we're generally trying to, before the meeting, everyone should go through their JIRA tickets, fix up the status on them, make sure that there are any new tickets that address the work you expect to do for the rest of the week. And basically, so Monday is kind of our day to review and plan for the work that we're doing for the next week. Review the work from the last week, make sure you've closed out the proper tickets or updated them accordingly, and then create any new tickets for the work that you're going to be doing for the rest of the week. And then we'll have the meeting, we can review that. And then Wednesday and Friday are about just checking in on issues like this, things that come up during the week or making sure that we're just keeping the communication channel open and getting problems solved. All right, so basically Monday is the day you should come to the meeting prepared with your tickets up to date. Correct. Got it. All right. Yeah, and if, you know, we had somebody who was actually managing this process, they'd be sending you reminders and stuff like that. But hey, you know, there's only four of us, three, four or five of us, whatever. We should be able to do this. So, yeah, so that's it. All right, then everybody have a great weekend and we'll be talking to you on Monday. All right.