 All right, welcome to August 19th, Microsoft Developer Sync. So here we are. So we've just had quite an extensive discussion about some matters that are not of interest to the public, but we're going to carry on with the rest of it now. I'd like to give a quick hardware update to kick it off with some good news. Well, it's not really good news. It's just the expected news that we've kicked off the second rev of the hardware board to resolve the issues we found on the first go round. Hopefully, we'll get those back this week. And they should come up in pretty short order. Pretty much everything was solved except for being able to program the XMOS chip on the last one. And that was just because there were some problems with the way the pads were implemented. So we'll get that sorted on this round. And we'll keep you apprised of what's going on there. Other than that, we've been digging into the precise wake word tagging process and the schema for that. We've had some extensive discussions offline today about that process. So that's a topic that we could get into here. I think it concerns basically all of us. And is there anything else that we should talk about, any other agenda items for today? Oh, I know. We put off a discussion of the tickets yesterday, didn't we? That's your ticket? Yes, there it is. Yeah. You haven't talked to the tickets. OK. And there's also the track status stuff, if anyone has opinions about that. But probably easiest is just to go check that out in the PRs of my profile. Sorry, I didn't quite catch what you were referring to there. Sorry, there's also the GUI track status. The GUI track? That I've mentioned very briefly at the start. Right. So just a proposed, well, an update to the existing track status. It's an internet, you know. Anyway, I think go have a look at the PR. Let's not talk about it here. OK, OK. All right. Then let's do something boring for a little bit and talk about the tickets. Chris, there, are you in a position to help us walk through that? I still don't have a good handle on how this GUI works. Thumbs up on the video if you like JIRA. I used to love JIRA, but that was a long time ago. Now, if you had a voice interface and I could just say, hey, JIRA, show me all the open sprints. Wouldn't that be awesome? Yeah. So if anyone's listening and wants to create a microp skill for navigating JIRA, please get in touch. There's a compliment one in the way. Oh, nice. OK, so Chris, are you intended to be muted? No. So is this, if we're talking, we just want to talk about who's doing what this week or do we want to really go through all projects like we had done before? And looking at this from a project's perspective or from a person's perspective? Let's go by a person. OK, see if this works. Project as project roll over under for tickets for that? Well, we actually had a sprint for the prototypes that we've closed out, I think. I started a sprint for support, but there's really not, well, let's see, there was something that came through yesterday that guess handled. But yeah, there's really not an active one. We could start the support sprint. Yeah, I mean, what would be the overall arching project? Would we have a separate project just for project roll over? Or would we have a, would it be under business development with a sub-project of roll over? Well, yeah, so there's, the way it's set up right now is basically in each, you can have separate projects. So there's like a hardware board that everything feeds into the backlog of the Microsoft Sprint. So you could have a, you should actually have a business dev board. You can put all the project roll over stuff within and then, you know, we might have the, like the specific sprints of building the prototypes that pulls from that, tickets from that board. So yeah, if you wanna populate project roll over tickets in the dev board, they should still feed into the Microsoft Sprint. Okay, so I'll start with me. It's really, I'm working on the precise sample upload stuff, I'm gonna have some changes. I had a bunch of stuff in review, but I'm gonna have some changes to that code once we get the schema worked out. So I'll have to go back in there a little bit. I had moved on to the script that moves the data from one place to the next, but I'll have to pause work on that once we get the schema happy. I'll go back, rework things that has to be reworked and then move on from there. This is really my, what I've been working on this week and have been working on is getting this spread away. Ken, where is your, I think part of the problem with using this all sprints and clicking on people is if you're not actually assigned to things, if the assignments are right, that's not gonna work, but that's the point of being able to click on faces up here, if everything's assigned right and everything's assigned, you should show up. Well, what's the project doing? It looks like, for example, all my tickets are in precise, P-R-E-C. That shouldn't matter because all the issues from all of our other projects should be linked into here. So the backlog is a giant slurry and you can just pull things from any project. Yeah, I'm putting my sprints. Well, all I know is right now in progress under precise project, if you search for me, you should see that there's four tickets in progress, 71, 72, 74, and 75, P-R-E-C-Dash. Yeah, this is the problem that I've been having with you. Yeah, I mean, basically- You're here in Buc-Fixes, right? Which sprinter are you in? It's a good question, I don't know. Where I was put, all I know is I've got tickets. They're P-R-E-C-Dash, the way I find them as I search for the items. Well, really the easiest way is go to P-R-E-C-Dash 60. You want to see what you and I are both working on. That's in the backlog. All right, so yeah, if you go bring that up, you'll see all the tickets sub-categorized. See right there? Yeah. First piece, and I'm working on that third piece. It's gonna meet and settle. But if you click on that, you should see, yeah. And then there's my in-progresses, my guns and all that good stuff. Okay, all of these should probably be in the, well, I don't know if this all isn't really part of the precise upload sprint, but if this is all stuff you're doing, you should probably have a sprint defined for the things you are doing to precise. Because right now, it looks like you're working out. I don't know how you guys do it. Usually, a sprint is a sprint, and then there's a collection of work that's done during that sprint, which could be a variety of tickets on a variety of projects. I've never really assigned sprints to. We do it a little differently here, really a sprint for us is a kind of like a project, the collection of tickets that we do, and we kind of group them together. And then once we're working on that group of tickets, we set the sprint to active. Yes, so if you're using sprints as projects, what are you using projects for? Just a way of partitioning the tickets, you know, by subject. Actual JIRA projects are applications, precise as a project. Minecraft Core is a project, Selene is a project. But then you take the backlog of all those projects and you group those tickets into projects, probably the wrong word, in this regard, but you group them into sprints, a group of tickets that you wanna do kind of out together in an average to, in my case, get the precise uploads done. Yeah, well, it's okay anyway, that's how you find my stuff. Okay, we should probably create a sprint for what you're doing. Yeah, I mean, if this is too complicated, given the small size of our team, we don't really need to have more sprints than we have team members. Maybe it does make sense to just do like a rolling two week sprint like we had before. I prefer to keep things organized by projects because it helps us to see how much we have done until we've accomplished a specific unit of work, right? Like if you've got 12 items that need to be done before we can roll out the new version of precise, then it's nice to see what those 12 items are, irrespective of what work, Gez is doing on the 20-08 release or Chris Bear is doing on Selene, if it's unrelated. So that's why I like to group in things. For that, so if we go into the Minecraft Sprint here, you can go in the backlog, if you look at the epics, you can see the stat, how many issues there are and the status of them. Right. So if we use epics, right? And instead of use them, epics to track the progress of a project rather than the sprints themselves, then we could do both. We could have the sprints do. It is what we're doing in the next week or two weeks and have these epics to track how much work needs to be done to get whatever subdivision of tickets we want to do for projects. Sure. Okay. Of course, we have a crap ton of epics right now. We certainly have a lot of work to do. Yeah. But you can also like this, you can drag these. So like this is what I'm working on now and one of the more important ones, you can put the one you're working on here at the top. So you're not scrolling down to find them all the time. But yeah, so if we want to do that, after today, we can reorganize things a little bit here. Right. So we can have a whole bunch of sprints to find here and a lot of them might even have started yet. Right. I don't know, maybe we should just be using, well, we can't just use epics without sprints, right? Because you can't just look at all the issues in an epic without, or you should be able to without. You can, it's not the best interface. Yeah. And epic is typically defined as a project that's not, it's going to span multiple sprints. Right, right. My concern is just, yeah, okay. Well, I mean, then the only sensible thing to do is to define sprints as a unit of time, right? A week or two weeks or whatever. Yeah. And which would be fine for, you know, keeping track of how quickly we're doing things. But again, you know, I'm not sure how useful that is given the small size of the team, or maybe it's super useful given the small size of the team. Well, I mean, another thing we do is we can use a combine board too, instead of a scrum board, not to sprints and just, you know, pull off tickets off the combine board as we do them. That's the same thing as just having a backlog though. Right. It's just dragging things from the backlog to the in progress column. Yeah. And then you use, you can still use epics and other categorizing things to categorize the tickets and then, you know, what we're doing. Okay. Well, I don't have a specific problem I'm trying to solve right now. So I guess we don't have to spend too much time on it. As long as we can get to what people are working on pretty easily, that's really all I care about right now. Yeah, I actually have on my bookmarks menu the ticket PREC-60, because that has the three major sub-tickets and then those sub-tickets kind of have their items. And traditionally that might be a epic and then projects and then tasks, but. Yeah. I don't want to introduce a lot of management overhead in terms of managing the tickets because there's only three of us. That's why I said just go to PREC-60, simplest way to get there. Okay. All right, so having had all of that meta discussion, did we actually talk about your tickets at all? No. Okay, let's do that. We just said that 71, 72, 74, and 75 are in progress. Gotcha. Okay, so you've got four things in progress. Let's just take a quick look at the summary of what they are here. Sure. Okay, so determine trigger and response. There's one of them. Yeah. And this is, yeah. So this is basically, at some point in time, we've accumulated enough files to trigger a new model build process to kick off. And so this speaks to that. Right, well, not necessarily just files, it could be new tags or things like that. Well, for right now, the trigger is strictly new files. We can certainly refine that. This is part of a larger process, obviously. Okay. And then go to the next one, 72, Chris. Yeah. Yeah. Here is kind of, add new data to existing data sets. Okay, so yeah, yeah. So this is basically speaking to the fact that when the new data schema is done, I'll take the existing code that I've built or that I'm finishing up and I'll change the SQL to go to the new schema versus the old schema. Okay. Yeah, we've got a streamline in this process. Yeah. Sometimes I just use the URL and change the number. Yeah, right. Roll down to the bottom, let me see the latest on this. Yeah. So this is, what is this balancing of some sort? What's the title of this ticket? It is. Yeah. So this is speaking to the fact that as I've been iterating through this balancing, I've learned some stuff, which is that you want to limit the user contributions as late in the process as possible because you never know how much data you're gonna lose during the classification phases. And so you really wanna get all your data classified and bucket it out before you start losing samples. And it also speaks to the concept that when we said, well, we'll limit samples to 10 per account where I'm basically at is 10 per account per bucket, if that makes sense. So if an account had 10 high wake words and 10 low wake words and 10 high not wake words and 10 low not wake words, I've expanded it to include it from that perspective. Otherwise, when I was combining the data sets up higher and whatnot, I was ending up with like two or 3000 usable samples at the end of the balancing. And where I'm at right now is I'm at about 10 or 12,000. And I actually added a step in the process to bring in some raw external data to balance out our weakness, which is female not wake words or high pitched not wake words. And not wake word should never be a limiting factor for our data set size, right? I can say, okay, don't have enough high pitched wake words or low pitched wake words, that could be a limit, but not wake words. I should be able to get that information or get extra data. So that's what I did. I'm actually in that process now where I'm bringing data in from the wild, converting it to our format, which is 16 hertz or 16 kilohertz and 256 bits, blah, blah, and so I basically download them from some different places that are given them up free. I convert them and I add them at the very last step right before the balancing occurs to the index file as additional rows. And so I noticed that I was 2,000 short on high pitched not wake words. So by adding these additional 2,000, I will acquire 8,000 additional centers that make sense. So that was absolutely necessary at this stage because we have such a small data set size. And so that's what this kind of speaks to is I've been iterating through that process, running through it, finding out what I end up with, determining how I can get the maximum number of balanced data samples out of what we have and hopefully that'll serve us moving forward. Okay, and then one more, Chris. Just go up and change the URL. What was that? Oh, you can click there, I guess, sure. Should be 75, right? Mm-hmm. Oh, this just speaks to the fact that once I get this training data set with the latest data assembled, I will build some new models using it and see how they perform. Okay. Anything limiting your progress right now? Nothing. Nothing. All right, full steam ahead. Yes, sir. Infinite speed. Okay. Okay. Infinite velocity. Yeah. It's the same as velocity zero. Well, I guess if we're going forward, sure. All right. So, I guess, let's take a look at Jess's plate here. Yeah, so mostly focused on 20.08 at the moment, which is all the things in the review. There's a few others that have switched over to Chris's allocated Chris review, but okay, it's been really helpful in reviewing things as well. So, I think everything, all the PRs that are pushed has passed all their tests and have been reviewed for memory. The remaining pieces that I think are really important for 20.08 is the inf module has been fully deprecated and we pulled that out for a few places but I think there's like three places where it still is used. So, switching that over to import lib and the lingua franca community have been doing a huge amount of work, particularly chance encounter on some pretty big changes there. So, we're trying to get that in for this major release as well because there's breaking changes in there. The, I think the last sticky point was that if you called a particular, if you normalize an utterance and then called extract date time or extract duration in Italian, then a couple of those test fails. So, I'm spending today looking much more deeply into lingua franca to see where that's up to. But, I mean, our only officially supported language is English and so I feel like if there are a very like half a dozen tests in Italian that are failing, then I'm inclined to push ahead and just mark them as expected fail and merge it and fix it in 2008. But, yeah, if other people have opinions on that then. Yeah, it's an interesting issue. Is there nobody developing in Italian that can help fix those before we? They haven't been around recently and like in a very recent future, and we're just, we're at a pretty tight deadline as well. And it's specifically related to seconds. Like, essentially the normalized function, I think, converts it into seconds in the sort of ordinal, two and a second, as opposed to the fact that it could be either a time unit or an ordinal number. Yeah, so potentially we'll be able to fix it. And, but, you know, just in terms of if we can't, because we don't speak Italian, then maybe we push it and encourage a bug fix, you know, for 20.8.1. Right. Okay, so we're talking about this is for 20.8. Or for the 20.0.2, the last 20.2, at least. No, it's the last 20.2 really just gone out. So this is for 20.0.8. Yeah, to have that, because the changes to lingua franca, they pretty structurally change how lingua franca is structured. So it's a, and there's potentially breaking changes particularly for other languages if people are using it in core. Gotcha. Okay, well then I'm fine with you pushing it with those few tests failing. I'd be hesitant to mark them as expected fail because, well, do we have a path forward for recognizing when it's, you know, notifying people which tests are failing at, or effectively just not being run, right? If they're expected to fail, it will not run them unless they start working and we get a notification that, hey, this test that we thought failed now works, right? I don't remember what the resolution on that was. I don't think we have that yet as far as expected fail starting to pass. I don't think that's been built. Okay. Yeah, I mean, I kind of use it as a, you know, someone saying, how can I help? I'm like, well, if you search our repos for expected fail or for a skip test, then, you know, that's a pretty sure sign that something needs some love. Mm-hmm. Very well. Okay. All right, fair enough. All right. Yeah, but we'll see. Maybe we might be able to sort it out, you know. Okay. Anything else? Yeah, I mean, the other stuff, they're like updating the docs for the open data set and that sort of thing. I was trying to put on a back burner for the minute until we get 208 out. And I'm catching up with, okay, later today to go through the sort of major release process and just make sure I've fully understood all of that. Cause, yeah, okay, it was always in control of that in the past. And, yeah. Okay, great. Christopher. Did you already go through and you muted? Yeah, I was first. Oh, you were? Yeah. Okay. We can do Derek though. Sure, let's do Derek. Okay, so, yeah, for the Mark II Dev Kit project, I had been back looking at some things today in terms of thinking about, well, it's kind of reprioritizing some of the stuff to a certain degree. So we're talking about getting ready for the first draft kind of 3D printed design that, you know, kind of was the look of the production product. But I've created a few of these laser cut enclosures to, you know, get it into a form factor that, you know, the same location for what will eventually be the production design and utilize an acoustic chamber that is essentially the same volume and, you know, same porting and sealed and all that good stuff. So what I'm thinking, the thing we need to do though is test that in comparison to be off the shelf design. So we have, or correct me if you guys think I'm wrong in this way thinking, we don't really have any metrics to try and, you know, strive for in terms of performance here, mainly because we haven't sought to optimize the off the shelf design because we kind of had the limited ability to do so. So in terms of saying, you know, what is the ability for us to barge in, what's the decibel level that the speaker is playing at that we can barge in? And what is the decibel level that the user can speak to Mycroft and activate the wake word? You know, we did a little bit of testing with some interns about a year ago, you know, doing like simulated whisper select 40 decibels at like three feet, six feet, 12 feet, that kind of stuff. Does it activate the wake word? You know, does it not, et cetera. But what we're really doing then was benchmarking existing products with benchmarking Amazon benchmarking Google. We don't really have any data on the off the shelf design, you know, how it performs. So I'm thinking, you know, for us to make a decision on the, you know, the SK201 whether it's successful or not, we need to have some of these things thought of, like we need to say, can we do, before we, I think before we get to the point of, I mean, I can do some work in parallel like getting ready for a production kind of equivalent design, but if we have no way of telling that we're passing some kind of performance parameters, I think it's a bit of a carbon foil horse to get too far along on that. So we need to have some way of saying, okay, this is gonna get there, this is promising. Because we are switching, you know, the XMOS chip from what the off the shelf design. So, you guys think, you know, that's on the right track of thinking. So I was kind of reshuffling the priority there instead of me kind of moving forward with getting, you know, a more detailed plastic design. I'm kind of sitting down there to write some metrics to try and... Yeah, I think that's a good idea. We should search the backlog for tickets of this nature because I think I went through and put a whole bunch of tickets in around this. Okay. Quite a while back. So that might be a good starting place for those metrics. Okay, yeah, I can, yeah, I'll dig through the backlogs and see where I can find and move those to kind of active. So, I mean, to be able to do any of this, I, you know, I needed devices. So that's a, you know, last couple of days for this demo that Josh, I requested, I do for a digital customer. And I think those were actually ended up in print 12. I got some devices done. So now I do have devices so I can do some of these things. I can use the benchmark test. So that's kind of where I'm thinking that I should be spending my time. And then I also have, you know, so I have there in review, I've got built-in device for Kent. So one of these devices I do want to get to Kent because he doesn't have one. So I've got two that I've built over the last two days. And then one I want to keep so that I can do this benchmarking. Yeah, so I think that's, you know, that's gonna keep me busy for the foreseeable future. I did take a look at some of the user stories that you're working on, Michael, for the precise tagging. And particularly number two, I think is the part that I would be involved in or be able to contribute in terms of helping on the UI of the user-facing tagger. So I'm not sure if that's, if we need to get rolling on that pretty quickly or if that's still a ways out. Well, I think the more user stories we can get now, the better off we'll be because it's affecting the architecture of the system. We've had, you know, I had a number of discussions, you know, like I said that Chris, Bear and Ken and I had talked for two hours this morning about the, you know, about the classification system. And it turns out there's a, you know, when you look at it from different angles, there's different requirements. And it wasn't, you know, it's not obvious from looking at it from just one angle what the right answer is. So, you know, even when I was going through and adding in some just stuff off the top of my head like, oh wait, yeah, we need to have some way of dealing with putting in beginning and end boundaries on samples to know where, you know, to delineate where the actual wake word occurs inside the sample, especially if there's more than one utterance of that wake word, right? Stuff like that. So, yeah, the more examples that we can give them, I think, the better. Yeah, particularly one thing I was thinking about, I think I threw it on a comment for the ticket that they've gotten kind of lost in the whole precise organization stuff. But the idea of moving, we're basically saying, you know, is this, hey, mycrofters, it's not, hey, mycrofter in the past. And now we're talking about possibly tagging multiple things. So my concern there is we might want to test that because there could be kind of a fatigue for the tagger, the user, if they've got this. Yeah, the GUI, the presentation to the user should be completely independent of the database. And so, yes, in terms of how we present it to the user, I think that we'll probably need some experimentation there, and certainly some design there. But yeah, I mean, it could be that we have, you pick one attribute and it's swipe left or right for true or false. And you just do that on like a, you know, one sample a second or whatever, just as fast as you can. Or it could be listen to a sample with a waveform on the screen and enter the beginning and time points for when the wake word stops and starts and then tag as many attributes as you can that match that, you know, like it's English and it's, it is a wake word and it has a funny accent and whatever. So there's different ways of doing it. And then we may have multiple tools for tagging. So all those stories should be in there and in terms of what you might want to try. And then we can, you know, the database side of things should be sort of diagnostic with respect to that or should accommodate them. But I don't, I specifically made the note of I don't want the GUI to be represented in the database because I think they're, you know, they're different, like they're different issues. Cool. Okay. Well, that's good. So yeah, we can experiment with the best way because I just have a feeling like, you have used like a multiple choice thing or like, you know, check boxes that might just be too much. I do like the idea of like, let's, let's get it to you. You know, hot dog, not hot dog. Well, you guys were just speaking to, I'd like to call the syntax of the problem. Sure. And then there's Mantix, which is, and I don't know how to deal with this other than to just say it. So if you're saying, hey, you know, while you're tagging this, tell us if this is a male or a female voice. I think you're going to get further with that. And if you say, tell us whether you think this is a high or low pitched voice, because I think the latter is a more subjective value, not how you're going to deal with that. That's just something I want to throw out there. Yeah. Yeah, I think that's a good thing. You know, this, the idea of that specific tagging problem, I think does, we should maybe talk to some people and see what we think the best, the best way we should phrase that. But yeah, I think you're right. You know, you don't want to be ambiguous or confusing to the user is like, you want to be able to, but I think we also just, we want to keep in mind, we want to be representative of as many different people as possible. So. Right. And also, but you know, and it's about serving the utility of the, of the recognizer, right? Maybe classifying things as male or female isn't important to us because we don't really care if we just, you know, we don't, we don't care if a particular user is male or female, we just care that we can recognize them when they say, hey, Microsoft or whatever the wake word is, right? And so getting the right classifications in order to accomplish that is what's important to us. You know, the reason high and low pitch, I think makes sense for now at least is because it doesn't matter whether it's a high pitch male voice or a low pitch female voice or whatever, right? If, if you've got a, you know, maybe right now, if you've got a lower female voice, the system works really well for you because most of our samples are, you know, happen to be male and happen to be lower pitch, right? But, so the fact that you're female doesn't matter at all in that particular case, or it's not relevant to improving the wake word performance, I guess I should say. Yeah. More generic concept, right? Let's take age group. So I think I listened to a sample. I think it's a child. Somebody else listens to it and they think it's a high pitch speaker. All I'm speaking to is how do you deal with that concept? Well, again, I don't think it's relevant unless it impacts the performance of the wake word, right? If it's a high pitch, you know, child versus a child with a raspy voice versus, you know, an older person, like it doesn't really matter as far in the sense that, you know, whichever of those things are important to the wake word classifier or the recognizer in terms of, you know, making it perform better, right? So if you've got a, you know, an older person with a raspy voice and a young kid like, you know, mine who's had pertussis and his lungs are permanently scarred, thank you for people who don't get your kids vaccinated. You know, he sounds like a, you know, he's got the froggy voice, you know? So, you know, I don't know if he'd show up in the normal classification for a kid's voice. How are we getting out there? I feel like the biggest tension for me is like, you know, we're asking people to tag their perception of an audio sample. We're not asking people to tell us what the speaker, how, you know, who the speaker is kind of a thing. And so I think just in terms of how we frame it in the UI, I think that's going to be important because then it'll be like, you know, you can't be wrong about what is your perception of this voice? And which is kind of analogous to what we want, which is like, how do we think that a machine learning algorithm is going to perceive this voice? Yeah. I mean, that, yeah, that thing we all say is, if you ask people, is this, is this, is this saying, hey, Minecraft, that yes or no is a lot less ambiguous than some of the other classifications we're going to try. That's all I'm getting. In fact, those other classifications can be ambiguous. The question is knowing that, how do we deal with it? Is it something we care about or not? That's awesome. Yeah. So I think it's going to require some testing for sure to see what the best, I mean, to me, it's like, okay, yeah, we test, you know, do we want to get this down to like, you know, A or B and then, or do we want to do, say, A, B, C, D, you know, and then we get down to like, okay, what do we want to call these? High pitch, low pitch, you know, whatever. So, but it was a lot, there's a lot to, but that, but I guess where we're at right now, we're still at the user stories. You haven't, you know, kind of got that far. Do you want, Michael, do you want people contributing to this, this document, the user stories document? Actually, sure. I'd love to see the community contribute to this. Well, I was just thinking like anybody on the team, but yeah, maybe we could throw it out to the community too. Well, sure, the team, obviously, I think that the team should have input, but I think it would be interesting to hear from the community as well. Okay, cool. All right, well, I'll try and get in there and throw some extra stories on if I can think of any. We do want to move quickly on this though, because, you know, Chris is, it's kind of, it's on the critical path for us to do the next step in the tagging system. Yeah, well, I think next week, I should start carving out some time then to like start mocking up some of the UI for it. So, I'll get that on the sprint for next week. Okay. And well, we'll just check it out. And well, we'll just have to hope that it can, the system we choose can accommodate it or it can be easily changed if we come up with any changes, because I think, you know, Chris, correct me if I'm wrong, Chris, but I think we're kind of hoping to get this resolved today or tomorrow. Is that, you're muted, so I can't hear what you're saying. The schema itself, yes. I'm kind of, you know, I had a bunch of code written and it's already all gonna change. From our discussions this morning. So, yeah, I really can't do a whole lot more of the work that's assigned to me until the schema's ironed out. Well, anything I'd start on UI-wise, is it's gonna be super, like, I mean, not talking like the graphics are important or anything, just talk, you know, getting the basics, wireframes, you know, very simple stuff. Yeah, I don't think that's relevant to what Chris is doing. Well, I'm having stories as fine too, because then I could use those stories to build behave tests, for example, you know, make sure that, you know, those things work when somebody uses the tagger, you know, that kind of thing. So, I mean, if you wanna add to that, it's not gonna hurt the schema. And, you know, I don't think so far, all of the user stories in there, I think the current version of the schema will support, just from looking at them more quickly. But, it's really not gonna hurt to have all these things we expect the system to do, sitting in there. Okay. All right, cool. Well, I'll try and get into some contribution there. So, I think that's it for me then. So, yeah. All right. Well, unless there's any final things that people like to discuss, I think we should call it there. And we'll be back together on Friday. Sounds good. Yeah. All right. Well, thanks very much. Talk to you on Friday.