 All right, welcome to 14th of September, Microsoft Developer Sync Media. Okay, so last I checked, we're still mid sprint. So we can do a quick go around and check on status, any blockers or things that have come up. And then if there's any agenda items that people would like to discuss, we can add those in here. I've got a few that I'd like to talk about. So let's go ahead and get started with the guests. You always start with the person who's working up the earliest. Yeah, so in terms of my tickets and stuff, well, yesterday I got derailed a little bit. I've been adding a few tickets to the sprint, but it was a discussion started in the community forum. So it's kind of been bubbling away a little bit, but it was started getting discussed in a bit more detail, which I think is good around how we process pull requests and how we process code contributions from the community. Because it's something that we've talked about on here, and so they've seen us talking about it, but they haven't seen the translation of that into practice so much. And so they wanted to ask what to go with there, which I think it's pretty fair enough. And so I started a new process set around that end-to-end process of how we take in community contributions around code and the aim is to see how what the expectations are of after the company and of the community, both as code sources as well as code reviewers. Community members can be reviewers as well. Put some expectations there around time frames and trying to tighten up our labeling process so that that's clearer about what the status of any PR is, like rather than a pull request just sitting there with no comments open or with a comment that's like, yeah, this looks great, but it never got merged and hasn't been actually code reviewed or is that just referring to just things like nice behavior, all that sort of stuff. So spent a few hours yesterday starting to try and map that out in more detail. And yeah, as I said, I hope that we can actually lay down what we think realistic expectations are so that community members can be confident that if they spend the time contributing codes and then we're gonna spend the time, well, someone's gonna spend the time and let them know something about that. Because, yeah, we're still not keeping up with the current pull request coming in, let alone the backlog from the last number of years. Anyway, so I'll post the link to that. It was in the community chat, so I'll make sure that everyone gets it posted in the team chat as well. So yeah, it felt like that was more important than processing other PRs at the moment. And yeah, it also raised the question around our, so I also spent an hour yesterday trying to get through some of the backlog of email support requests. And then that made me think, why am I spending an hour responding to people who are not paying members and who aren't contributing to the community at all and spending an hour helping them rather than spending an hour helping the people who are trying to help us. And so I think it's something that I'm considering whether we should actually turn off the email support form on the website and encourage people to go to the community forums and the community chat for that, which we can help people there, but it means that every agent helps give, helps the community rather than just helping that one individual person. And at some point, I think it's worth providing some mechanisms for paid supporters to get email support, but whether that's something we can do straight away is another question. Okay. So that is, yeah. Two things that weren't really related to our sprint, but that's where I'm at at the moment. Right, well, but our part of your regular set of responsibilities, right? Yes. I don't know if that's clear to anyone who's listening, but Gez lives in the space where he's a part-time community support and part-time developer. Yeah. And when we say we have three developers, we also all do other things for Microsoft on the side, whether it's like keeping infrastructure running or, you know, yeah, responding to the call request or blah, blah, blah, blah, like we all do a lot of things. Yeah, exactly. So yeah, I think that's a good thought in terms of email support. Yeah, I don't think that we've promised anyone email support, right? So if that's taking up a measurable amount of your time then we should definitely refer those people to the forums for support. In terms of the document that you were talking about working with the community on the PR process, I looked at that and I think you're on a good track there. I think we need to make it clear to our community what our goals are, what our objectives are. Our repositories are a, you know, as we move towards deploying something that's going to be a commercial product, right? We need to be able to support long-term. We're going to have to, I think, look at the way we handle merges and things like that very carefully, right? We don't want to, you know, there may be really cool features that people are submitting, but, you know, if they're not something that's essential or on the roadmap for, you know, particular implementation of the, you know, of the software then we have to be careful about, a lot of things, you know, the usual concerns like software bloat, you know, maintenance, performance, things like that, right? So I think the new system that allows us to have modules that can be compiled in or, you know, optionally linked in, I think that's a good path forward for features that are not necessarily on our roadmap or might be sort of edge cases or, you know, of interest to only a particular set of users. And, you know, maybe we'll have to explore with the community a way of implementing those and maybe we even expose that to the marketplace, for example, right? So that it's not just skills, but maybe other parts of the software that can be loaded that way. But, you know, when we release the Mark II commercially, you know, not just the dev kit version of it, we're going to have to be a lot more circumspect about what we make easy to install on people's end devices because, you know, it has to be curated in a way that they can trust that the stuff that they're putting on their system is safe to use. So yeah, so there's a lot of considerations there in terms of integration testing and making sure that submission has, you know, all of the things that are going to make it possible for us to maintain it going forward. So, yeah, so I've seen that document there and I think, you know, we should continue to work on that with the community. And, yeah, and continue this process of, you know, as we're doing this week, explaining what our roadmap is, sharing that with the community and, you know, taking the good ideas that are rising there and bringing them into our roadmap at the appropriate place. So, you know, there's a lot of activity right now around the company play skill. And, you know, I think that's a really good thing to develop in a thoughtful way. And if, you know, if that's moving too slow for a particular person, well, I mean, they can be doing that development on their own and, you know, that when we have the bandwidth to appropriately support it, you know, we will. Well, I think that's a good example because, like, you know, they're PRs where they are being held back as well. But there's a clear process of, like, why they're being held back and, you know, how we're trying to move forward on that thing. I think the, you know, the broader issue is that, you know, people have got, like, you know, three-year-old PRs that are actually really good changes, but they just never get touched, you know. And they put a lot of work into them and all that sort of stuff. But I also think this is the chance for us to tighten up some of the expectations we have around how the process, how PRs happen around, you know, that people, you know, that things do need to be... If things aren't pitched as an idea and people just contribute, you know, a whole lot of code straight up, then, you know, there is the danger that it's not going to get merged because it doesn't align with the community or our idea of what's on the roadmap. And so that's, you know, if they've built it for themselves anyway, then that's fine. But, you know, if they're just thinking that something's in, it's a better process to sort of pitch an idea first, get ideas, you know, have that discussion with the community around what that might look like and how it fits in and all that sort of stuff and then start coding. But also tighten up around what's required in a PR so that it's very clear that, like, you know, if there isn't already test coverage, then we should be adding it with every single PR. And if there isn't already traditional documentation, then we should be adding it with every PR and we're changing it with every PR because, you know, presumably the code changes something, so value. So, you know, a test should be updated, second documentation should be updated. Yeah, that kind of thing. So anyway, yeah. Yeah, and, you know, there's a lot of ways to go, right? If somebody codes up a whole bunch of interesting functionality that they want to use and they submit it without, you know, checking in first, whether it's on the roadmap or if somebody else is already working on something like that. And, you know, that's a fine way to go, right? If they're, especially if they're doing it for themselves. But as long as they, you know, there's, the expectation is being set that, like, we're not automatically gonna take it and that we may, you know, come back with feedback and say, oh, hey, this should be implemented in this other way, you know, and if you want us to merge it into the branch, then, you know, that'd be great. Or, you know, this is where it fits into our roadmap and that's, this is when we'll likely be able to take a whack at it ourselves, right? So, yeah, I think it's just about. I guess the roadmap is, I think the roadmap is still that the biggest outstanding piece that I'm trying to think through is, like, you know, we have these very, very old roadmap documents which are really way out of place. And how, what do we consider our roadmap? How do we communicate, how do we communicate that? How do we keep it updated? How do we develop it together with the community? Like, what does that look like, you know? Internally, community, is there two roadmaps? Is it a single roadmap? Is there, you know, a roadmap for the Mark II? Because it needs to say, you know, for a commercial product, if that needs to be, you know, you know, there's different requirements around a commercial product versus something that's, you know, a leading edge open source, you can install on your last thought kind of thing. Anyway, so I think that roadmap piece is probably going to turn into a big question, I think. Yeah, yeah, I think that, you know, I think we owe it to the community to have a publicly visible roadmap that they can see what our priorities are and be able to comment on them and, you know, make contributions in that way as well. So, yeah, so. And it will help them decide if there's a basis they want to contribute to as well, you know, like at the moment, because there's no way of saying what we think needs to happen next than shooting in the dark, so. Right, yeah. So that's, I mean, that's a big part of what we're doing this week, right? It's Wednesday, we're having a brainstorming session on, you know, priorities and then Friday we're going to be making some, there are these high level decisions about that sort of thing. And I think at that point, you know, maybe that'll be part of our next sprint is to put some of that in a publicly based document so that we can start to get some feedback on it. All right. Well, hold on, the one thing that we're not doing, and this is one of the things that is the thesis behind which the company was founded is leveraging the community for the creativity components of it. You know, I think that when we do our roadmap, it's very likely to come back with, you know, a lot of pieces surrounding, you know, basic framework functionality, right? So the ability to, you know, to capture information from users who've opted in, the ability to process that information, the ability to feed it into a model, and then, you know, use that model to solve problems is really a big focus of the company. But, you know, the way I hear it or see it in the forums, a lot of the community is less concerned with that stuff and more concerned with, you know, individual skills or capabilities that are beyond the framework. In other words, our focus is the operating system and, you know, making the overall experience work well. Their focus is the individual applications that that operating system enables. And those things aren't necessarily, you know, you can do those things in parallel, but, you know, we haven't necessarily done a really good job of, you know, bringing the community into the discussion about what our priorities should be, right? And, you know, for us to go off into the ivory tower and say, this is what, you know, this is what we're gonna do next, you know, in the absence of their input, you know, may create some conflict. And I will say the flip side of that coin is, you know, opening the door for input in a way that is a giant distraction. Like at the end of the day, most of our community members are not paying their mortgage with the stuff they're doing at Minecraft. You know, we are. And so we have a different set of priorities to make this thing commercially successful so that does have longevity than the community might have immediately. Anyway, yeah. So spending three weeks naval gazing and having long conversations where everybody gets input is a great way to go out of business. Yeah, and this is what I mean by the roadmap page turning into a big question is if it's just a matter of, you know, our internal team putting down our ideas and creating public documents and, you know, that's like pretty straightforward. But then it's like, what is the process now and ongoing of, you know, having that community conversation in terms. Yeah, keeping the community involved and managing that balance of like having having a clear core roadmap, but, you know, in the words of Mickey case, like leveraging the chaos of the community to add variations to our ecosystem and allowing that to, you know, enrich everything that we do. Right, well, and I think that's, you know, that's why in particular your duties are split between the community and, you know, core development, right? You know, we've made the decision that our community is an extremely valuable part of what we're doing here. And so that's why, you know, even given our very limited resources, we've dedicated somebody to focusing on that, even if it's not as, you know, as much, you know, even if we'd like to be able to, you know, put more resources behind that, right? Which is the case of pretty much everything we're doing now. So, you know, we've kind of taken a position on, you know, how much we can support that in conjunction with all the other work we're doing. And so that's just where we are resource-wise, right? So obviously we'd like to do more and the community is a great source of ideas. And, you know, I think my point is just a matter of, you know, let's communicate clearly what it is that we want to do and for what reasons, right? So if we're focused on getting the mark two out the door, which is the current focus, you know, what is the, what's the reasoning behind, you know, the various decisions that we're making, right? So not everyone is working on the mark two, it looks like at first glance. So why is working on the wake word and the data collection scheme, you know, important to getting the mark two out the door. So, you know, we can make that a little more obvious to the community. And, you know, likewise with all the other, you know, parts of the system that we're working on in terms of, you know, there's the, you know, there's the update system that we've been having a lot of, you know, background discussions about and things of that nature that are going to be essential to getting the mark two out the door. And so that's the kind of stuff I want to put on the roadmap, right? So that people can see that that's what, you know, that's what our focus is. And, you know, the roadmap doesn't necessarily have to be, it's not a schedule, right? It's a list of priorities. And some of them are going to be, you know, pretty high level and some of them are going to be, you know, fairly detailed. But, you know, other things that might be on that roadmap are, you know, the kinds of changes that we're looking for the community to contribute to, right? So it might be that, you know, in the current, on the, in our current phase of development, the things that we're looking for from the community are contributions to the essential skills, bug fixes, improvements to the core infrastructure and things like that, right? And on a opportunistic basis, we may, you know, roll in some changes from left field that look really great. Things that we didn't anticipate, right? And that's what Gez's job is to do is to kind of, to look for those opportunities and take advantage where we can. But at the same time, you know, there may be functions that are great to, you know, to think about implementing but or incorporating, but, you know, we're just not sure of or they don't have the proper testing support or might be, you know, considered, you know, like a little used feature that might just add to the complexity of the software and that sort of thing. So, you know, maybe that's something that we, we develop a system whereby people can contribute modules that will end up being in the core repository. So they're checked in and they're, you know, they're available to anybody who wants to use them, but they're not necessarily enabled by default. The things of that nature. So, but yeah, I mean, I think we need to come up with a solid plan here and communicate that with the community and, you know, I think also make it clear like what, what we're able to do and what we're not, right? So we know we have a backlog of PRs, some of which are very good and are a couple of years older than we should, you know, we should definitely get around to doing them. But, you know, as a matter of priority, we just don't have the resources to do it right now. So. Something else I wanted to add was something we could probably do a little bit better job of that probably wouldn't take a whole lot of time would be identifying things like in our, you know, the bugs in our essential skills, for example, that are in our JIRA, but aren't exposed elsewhere. You know, those are things that, hey, you know, if you want to help out, here's some stuff we know is wrong or we know it needs to be fixed, that, you know, could probably be fixed pretty easily if somebody spends a little time on it, you know, and exposing that to the community. So if somebody, you know, had some free time and wanted to contribute, here's some things, you know, we know of, you know, that could help us out in the short term, even. Yeah, I actually think that there is an issue in our ticket system right now to link our GitHub and JIRA ticket systems together somewhere. Yeah, of course. So, yeah, that's one of those kind of meta issues that, you know, we just have to put on the priority list. So. Okay, anything else, aside from that? No, I don't think so. I mean, yeah, I've been doing some stuff to fix the, been talking with Chris and, okay, to fix the point com stocker build that broke. And we've changed the backing business, but he might become more twinked. Currently, anyway, I won't bother going into the detail. Maybe, yeah, I guess this is all, I'm not gonna finish all my tickets by the end of the sprint. Okay, we'll take a look at that afterwards. All right, okay. We'll take a look at that then a little later and see what we need to do about that, if anything. Okay, so Chris, very. So we had an hour today. I don't know if everybody saw the matter most. And so I spent my day dealing with that and I'm not quite done yet, but really the crux of the issue was that the MySQL crashed again on WordPress. So, it's the first time I've had to deal with it. Usually, this is all over that, but it came up in the forums, in the chat this morning that people could not download the PyCraft image and that's what it traced back to. So, in the incident report, the short term solution was to restart the MySQL server and that seemed to affix everything momentarily. Short, longer term is what I've been working on for the rest of the day since I restarted the server. I figured now since my brain's on it, I might as well work on that ticket that's there for getting this done. So, I wanna share my screen here for a second. So this is, we have a droplet out there a digital ocean droplet that is the MyCraft maintenance page droplet that we're supposed to be using for these maintenance issues where I have to take down the site completely and the droplet completely. There's different, there's different scenarios, right? And if you're just doing WordPress maintenance and I think there's a plugin we use that'll just save the sites down but the droplet's still up. When we take the droplet down, we need something, another mechanism to say, hey, we're doing maintenance. So, that's what this screen is. I pulled that graphic from our WordPress maintenance functionality and just threw some text on there. So right now I have that running that IP address up there is our new server for this purpose. So, we can pretty this up later if we want to but that's kind of what I'm working on right now is getting this to a point where, and I'm using our test WordPress instance right now to get this tested. Making it easy to flip a bit basically that points to this when we want to do something and then implementing that. I think as pointed out the last time we did this we just used the old WordPress instance to do this and that instance isn't around anymore. So, this was our long-term solution was to use this maintenance droplet. So, that's kind of what I'm doing now is just getting that all set up. And it is a ticket in this print so I am working towards this print but it's not what I said I was going to do today. All right, fair enough. It's not in the blocker but. Yeah. So, two comments on that. The WordPress site goes down, Salini still functions, right? So people can use all the backend services and go to home.microsoft.ai and stuff like that, right? Correct, well, yes, they're not dependent on what I meant, let's put it that way. They could both be down but. Right. One is off the pen over here. Correct, okay, that's what I thought. So, maybe there should be a link on that really basic front page that some text and a link that says, our home.microsoft.ai is up and running. You can go here to access your account, right? Because we don't want people to not be able to do that since they can. And, oh, I was wondering if we could just use it, well, nothing matters but we've got the test.microsoft.ai server as well, right? And, so I have two questions about that. One is why not just divert people to that if our main site is down? Because presumably that runs on a different server. And second, why can't we, can we promote the content that's on test dot over to the main site now? Because I don't see why we shouldn't. So the answer to question one, so yes, we can definitely, I can add a URL link in there pretty easily that points to home into that screen. That's pretty straightforward. But as far as pointing to test, we could do that. Tests, you may have a slightly different user experience because we may be testing things on test. And then they see things that are in progress if we did that. And maybe even things we don't want people to see, it depends on what iteration we are in test, which is why I kind of went this way. No. But as far as the promotion thing, all I guess talk about that. There are people now jumping on test.microsoft.ai to see a little bit of a top secret side. Well, we're not live streaming yet, so there might be just enough jumping. Yes. I'll first explain everyone's expectations and there's nothing secret on test.microsoft.ai. Other than a new contact page, which is what I talked about before, propose possible. Yeah, I guess the one, well, one point is that this maintenance page should be up quite very briefly, which when we are, obviously you won't decide down for as long time as possible, like balancing like how much work we've put into one thing versus keeping the site online for 99.99999 cents at the time kind of a thing. If we point to test, then we'll need to put the store into maintenance mode and that sort of thing so that people don't do actions on the test site, assuming that it's the production site and then those things get out of station. Yeah, good point. Okay, so that's not a good idea. I like Chris's current solution of just having a static web page that's the home site. That's fine. It is something though that we can do, if there is ever any time where we're, that may go down to, where we may need it down for a long period, we can clone the entire site, put it onto a different droplet and jump back and forward. It just requires a lot more. That's actually something I attempted today. I was, I made a snapshot of the production WordPress droplet and put it on a host and tried to get that. It didn't work out all that great. I mean, I thought maybe it would be that easy, but it was not. No, no, definitely not that easy. Because there's protections in place so that like, we can strike our payments processing back end. The way that it's set up at the moment is that, depending on how people purchase a membership, some of their memberships are actually driven by WordPress, like the recurring memberships. And so then WordPress will ping strike to charge, to recharge them on a regular interval. Whereas the ones from our, Leni's strategy is managing that recurring process. And so if we then had multiple instances of the site, then it could potentially charge them quite for the same, for the same membership. And so, yeah, there's some protections in place so that not both of those can exist at the same time. Yeah, so, yeah, I mean, I think that could be a longer-term goal would be to have an A and a B site, maybe have that set up that way. But yeah, that doesn't sound like it's a couple-hour version. Okay, so, yeah, carry on. Put in a link to the Selenium back end so people can get there. And I would like to promote tests to home, unless there's any reason not to. I think I've been pushing all the changes across. So like the navigation changes and everything now live on. Yeah, yeah. Yeah, oh yeah, I did that late last week, I think. Oh, okay. I mean, I don't know. Yeah, sorry, it did take me a while. Gotcha. All right, I see that now. Thanks. All right, so moving on. Derek, if you want to pretty this up and give me another image or HTML or something I can use, this is just that image and then some text I threw up there. So if there's, you want to make this different then it's pretty easy to change the HTML. The bigger thing is getting all the- Yeah, don't let that hold you up. That's a, let's make a ticket for- Yeah, that could be a lot of hard work. Yeah, make a ticket to pretty that up at some point in the future. But I've got a lot of things I want Derek to work on. It's fine, I think it's fine. It's really, we don't want it up for very long. Yeah, yeah. So yeah, that's what I've been working on. My didn't, I should finish this up today. And part of finishing this up will be once I get the proxy set up and all that good stuff going then I will actually sometime tonight point to this, upgrade the droplet, hopefully that'll fix our memory errors. Hopefully, we've already upgraded it once and it didn't fix it. So hopefully- Oh really? Yeah, we went from one gigabyte to two way a year ago or something on this droplet. So hopefully this will fix it. But another solution I saw doing the research was in the config file from my SQL, you can downgrade the amount of memory it asks for when it asks for a buffer and that might help too. So then we'll do the increase in droplet size first and then creeps back up. We'll have another potential report. It's a freaking wordplay, trust me. Why is it so hard? Anyway. All right. Yeah, I mean to be honest, I think- Because it's a freaking wordplay. Yeah. It's like amazing software, but it's also its own beast. And I think like having it hosted by a dedicated wordpress host I think is really the best long-term option. Well, and we'll talk about some of this stuff moving to Selene as well. That's also a longer term. Yeah, yeah, I think we're getting over things. Very, very long term, yes. Okay. All right, so Derek, do you have any news or blockers? No real blockers. Let's see, I got Ken's device wrapped up. I think I told him to get an email and I was waiting on the parts. Just the last, the cables I had for the display just pulled too short. So I had to quickly get some order. And so I have been messing with mine a little bit today. This is actually a running the Qt version. And they, we asked them to do a quick screen rotation addition to the UI for us. So it actually does display a horizontal format. Of course, not all the skills are gonna be optimized for that. But anyway, so all this stuff brought up mine and everything, but I haven't been able to test any audio stuff. I just haven't been able to configure it to be running off the USB. So I do wanna go back to the skills that aren't configured for that orientation. So when we originally met with the blue systems team, the construct for the visualizations was a card construct. So all of the visualizations were designed to be in symmetrical XY format. So they were all square. And if you were gonna do a horizontal screen, you would simply lay the two cards side by side instead of one on top of the other. And the thing I really liked about that proposal and that approach is, we can stack them and go vertical, we can put two cards next to each other and go horizontal. We can put one card on a watch, right? And then the swipe over, if you had a display that required four cards, you could put the first card on the watch and swipe to the next two, right? And the same for a horizontal screen. And then if you have a full size screen, you could put either four or six cards up there for the display. And so my question is, did we not do that? No, I mean, not initially. No, there are cards, like there is a, you can choose to use cards in the interface. So a skill can choose to create a card based interface. But a lot of them, they use things like, you know, if it's just text, for example, you just say show text and then it responsibly adapts to the size and shape of your screen. So if you, you know, which is not card based, but it's sort of responsive. Yeah, and the idea of the card was designed at the time, the card was essentially a portrait format for the Mark II at a four inch, roughly a four inch screen. So if you go up to a 10 inch screen, you might be able to get three or four of those cards on the screen and fill that horizontal space, right? But that doesn't mean necessarily the card information, if just by itself would look good in a horizontal format. So we're talking about actually redesigning the base card, so to speak, that makes sense. Okay, well, that sounds like a bigger discussion, but the answer is don't get what you wanted. It's not, I didn't get what was promised in fairness. It wasn't my idea, but I liked it when it was brought up because it does provide a lot of flexibility. Yeah, so I guess what I'm saying is like, yes, you could put two cards, like you could put two weather cards on here, but I think they'd be too small in this display. So what I think we need to, we'll really need to think of as more responsive type of design that, okay, if you've got within the card, within one card, like right now we use a lot of icons like the sun above, you know, the temperature, right? So those on a horizontal display kind of would look better side by side as opposed to stack. But that's, those two things aren't actually on separate cards, if that makes sense. So anyway, yeah, it's, part of it is there, the cards are there, but it's not exactly the same problem, if that makes sense. Okay, yeah, it does sound like we need to have a discussion about that, but that's a fairly encompassing, you know, graphic interface architecture issue. Yeah, it's a very principle item, like first principle item, and I'm not married to it, but I liked the idea and I understand some of the challenges with it, but if we did something that was extensible like that, that allowed us to stack cards, you know, horizontally, vertically in arrays or however, in order to build displays that are display information in a seamless way across multiple screen sizes and formats. And we can do that as a first principle, you know, that saves us a boatload of time on down the line when, you know, some company approaches us about doing end cap displays, which is gonna happen. They're gonna wanna do, you know, they're gonna wanna do a portrait big screen TV at the end of an end cap in a store so that people can walk up and talk to it. Well, if we haven't really thought that through, now we're gonna have to redesign all the graphics for all of the skills that that customer wants in order to work in that format. And it seems to me to be a good idea to plan to abstract that now as opposed to going back and fixing it later. So it sounds like this is something that's gonna come up as part of our choice of frameworks as well. Keeper, skibby, that sort of thing. So we should add this to the discussion. If, you know, it sounds like there was a, you know, some substantial work put into the GUI discussion and, you know, what the interface would look like and how users would interact with it. We should find that and figure out why it diverged from that plan and figure out what our new plan is going forward. Yeah, I also don't think there's anything that forces or coerces skill developers to use that. You know, I think it's out there, but, you know, it's somewhere that even if we do all our skills that way, another skill developer doesn't, and they turn the screen, then it just, you know, who knows what it's gonna look like. Well, but that's an issue though, right? I mean, every skill developer, all these skills work within a framework, right? If they are, if a skill can just like take over the whole system without any sort of expectations about how the other skills are using the screen or, you know, that sort of thing, then, you know, we have not done a service to our skill developers. So we need to figure it out. Yeah, that's where the flash.api comes in for the GUI. Right. Okay, so it sounds like. Yeah, well, it's also like we can, we've got to give people the framework and the guidelines to create the best experience possible, but being in a business project, it also means that people can do something completely different and, you know, make something that breaks all of that. So that will happen, but that then probably won't get into the marketplace here. Yeah, and, you know, for us, you know, it's just like anything else, right? Like we just need to set a standard, not just need to, that kind of diminishes how hard it is to do that, but we need to set a standard, hey, this is how, this is how Minecraft, you know, that the Minecraft display needs to be organized. This is what we expect. If you want your skill pulled into master, or if you want your contribution pulled into master, it has to meet these standards. And, you know, we're starting to do that relative to testing and relative to VoightConf, but we also, you know, as we deploy a GUI, that should be the same. Like here's the standard. If you want your application included as part of our GUI, as part of our standard build, you know, it needs to meet these standards. And they need to be clearly communicated partially for the open source community, but then also partially for our own review. If we don't set up a good standard and somebody submit something, then it becomes really, you know, does Derek like it? Great, then it goes into, I like it, no, I hate it. So it doesn't go, I mean, if we have a standard, it avoids, it avoids, you know, it becoming a personal opinion thing. Yeah, I think that can be coerced through an API too. Like if there's something you really want, you know, you can actually code, kind of guide people in a certain direction in some cases. So that's something we can consider as well when we put up an API. Yeah, and there's other, yeah, there's a lot of considerations. You know, there's how much CPU does it utilize to run their fancy graphic interface, you know, things like that. So, yeah, a lot of things to consider there. Okay, so let's make sure we take a ticket to include that in our GUI discussions. I thought that issue had been more resolved than it is. Okay, so any updates on the hardware, Derek, aside from demo working? Yeah, I mean, you know pretty much everything I know, but for the rest of the team, yeah, so Kevin, you're gonna have a little meeting with Kevin after this. Kevin is working on the board that we need for plugging the USB in to kind of, basically connecting the two devices via USB. So he's working on that. I don't think he's made a breakthrough on the audio issue we saw in terms of the amplifier playing quietly, but he's been working on that. One of the other things we were working on was our own custom PCB to drive a driver board for the, for a display that we could just buy at a reasonable price. Because the whole issue with all these displays and why you can't just pick any old display off the street and drive it, you know, is that they all have different display interfaces and different requirements and stuff. But we thought we'd found one where it was very affordable and we could drive it with a fairly easy to design display driver board, but it seems that might be more complicated than we thought. So we're looking at possibly having that just be sourced, having the driver display board be sourced. So looking into that a little bit, which actually the whole camera debate down where we put the camera was kind of wrapped up in that thing because we were hoping to actually put the camera on that board. So that might not be it. Might have to have several parts for that. Still exploring that. That miss anything there, Michael? It sounds right. Yeah, okay. Ken has been doing, he had some success. I think actually configuring his SGA201 to work with, he just has the board by itself. It does not have a full kind of sibling with the loudspeaker. He's not running with the i4 as a USB device right now, but he was able to configure it. So that's good. So yeah, I think that's about it on hardware and Chris, I'd like to get yours to use in time this week, maybe Johnny, I don't know, one of us could run over to you. Or I can always ship it. Other than that, I've been working on the GUI tagger. We had a meeting last week and talked about the concepts I've had at that point on Thursday and good feedback on that. So we'll bring some of those changes and we'll continue to work on that. I would still like to finish the first 3D printed design but that's probably the thing that's the most dangerous of not getting done by the end of the story. But I don't think it's not really walking anyone else. It's not really going to slow us down right now, so that is where I'm at. Is it slow going or have you been interrupted? Why do you think that keeps us in danger? Well, I just, you know, I want to prioritize the tagger so that, you know, I'm not blocking Chris. You know, that's probably my next-size priority outside of getting the hardware devices are essentially done. I don't know, depending on our conversation with Kevin like if I need to do some help sourcing some of this place or stuff or anything like that. Yeah, I think that's just the biggest thing is the tagger might end up taking. Gotcha. But if we can get that sorted out quick, you know, it's in and of itself is not particularly, I don't think blocking me other things. Okay. I don't have any updates for today myself. I had some agenda items I wanted to talk about, but we're out an hour already and these will fit nicely into our brainstorming session Wednesday, so I think I'll just save it for then. And so unless there's any final questions people have we can call them there. All right, well, I'm off to talk with Kevin and we're gonna try to get to the bottom of the next steps on the hardware and our production side of things. See you all on Wednesday.