 Nudge the TSC on some recent threads, kind of a hot July compared to probably expectations given that everyone likely extended the, at least in the U.S., the usual 4th of July vacation times with, you know, the week. We'll hit a similar phase like this in August with Europe, I'm sure. Asia, they never take vacations out there, so never really have that issue. Given it's a light week from the formal perspective, we can probably breathe through these in, you know, a half hour, 40 minutes, and really it's just about nudging people back to conversations that are happening on the forums mostly. But Todd, why don't you get started on the first couple and then we'll jump in on the other three. Sure thing. The first quick reminder is the annual TSC elections will be starting in early August. So that's for the 11 TSC seats, it's for all contributors and maintainers. We will be working on pulling together that list, much like we did last year at this time, and sharing the list with everyone on this call and more broadly on the technical list just so that everyone can ensure that if they're meant to be on that, as someone that is able to nominate themselves that they are certainly able to. And we'll also follow up with some more details on these specific timelines on the election just to make sure everyone's comfortable with that. And once that's ready, we'll get that kicked off in early to middle of August, looking to wrap up right at the end of summer. And then after that, we'll move forward with electing a new TSC chair as well. Any questions? And Todd, that's for, that'll be for people who contributed up to what date. We will, I don't know off the top of my head, that's part of what we're looking at in terms of finalizing the time timeline. But I suspect right up until early August, we had it pretty close to the nomination point last year. Okay. Thanks. Any other questions there? All right. Onward to Hackfest Planning. Brian, before I talk kind of more specifically on dates or locations, do you want to just talk quickly, kind of overall Hackfest thought, strategy, et cetera, and just back there? Yeah. So we had, we had a pretty good Hackfest in China. We had about 95 participants there. And thank you to Chris and to Arno and to Makoto and others who came in from out of the country to help to be the bridge there. It was really useful as a way to bring a lot of our members and developers from our core China companies closer into the development cycle. It felt a little more like a mini conference than a true Hackfest. But it did trigger some conversations, some thoughts about just making sure that the technical steering committee here views having Hackfest roaming around different parts of the globe once every two months, about on average once every two months is the right format, is the right pace, is something that people still find useful. There's no doubt that there's utility in the face to face. But we also want to make sure that people feel like the travel time and the two days that they put into this is of high value to them and their employers and all that. And so as we think about planning the one and one for the US in September and one later on in Europe, just want to make sure that that the enthusiasm is there. That the belief that it's the right format and un-conference kind of, you know, self-directed kind of thing is there. And that folks in the CSC are interested in taking leadership and defining the agendas and leading conversations there. And then that can be a useful guide to us at the Linux Foundation in terms of the right way to support these projects, the right decisions around location and timing. So it's an invitation for anybody on the call if you want to express an opinion about Hackfest, write a loan, write format. We can take a few questions here. We could also then take it back to the list. But yeah, just wanted to level that. Any thoughts? My only concern is travel budget. If there are every two months versus every three months, something like that. That's a couple extra. And it could be in the earlier days of the community having a pretty frequent pace was a good way to keep momentum going. And with light the fires, so to speak, and moving to about every three months might be a more affordable pace for sure, especially for the committed developers who still in need to be at each one of these, which would be really nice, really nice to have that, you know, kind of core that keeps coming to everyone. Hart, did you want to say your idea on the call? Sure. I just said something in chat. I think it might be a good idea to have kind of a more well-defined structure. If we want these to be Hackfest and not actual conferences and we want people to kind of get their hands wet with everything, we might want to to change the format a little bit. So we kind of have, we just intentionally leave, say, you know, a part free for hacking, because right now, you know, I don't know if this is necessarily a bad thing, but it particularly recently, all of these have sort of become more conference like where there's just talks and meetings and just the schedule is full, I guess, and people seem to prefer sitting in on talks to to hacking. So everybody just ends up, you know, sitting in on two days of talks, which isn't a bad thing necessarily. But we should figure out, you know, exactly what we want to get out of these, I guess, right? Would it make sense to do like two days of meetings and a day of hacking at the end or something like that? Personally, I'm not contributing a lot of code to any of the projects. I'm, you know, looking more at the working groups. I don't know how many other people are more focused on working groups than developing code. We've always tried to make room at the hackfest for those who just want to hack, you know, places where they can go off to the side. I think the key question is, does anyone do that if, you know, there's a fear of missing out? If there's presentations being given or talks being led, you know, does that become an attractive nuisance? It makes it hard to peel away with a couple of people and start working on code. So maybe Hart III frame, maybe the idea is, yeah, reserve the afternoon for no presentations, we've got to talk. But what we find is that a lot of people who show up at the hackfest are still pretty new. And so at the very least, we need, you know, some guidance on getting a desk environment set up and that sort of thing, just sort of can jump into the coding. So I think we need to provide room for that kind of activity as well. And sometimes that works better with somebody in the front, you know, classroom style, kind of leading the group through sometimes better one-on-one. Yeah, Brian, I've always thought that, Brian, I was going to say, I've always thought that hackathons were better when, like on the beginning or say more learning of each day, there would be like a 10 minute, somebody would peel off and say, hey, if you need help getting set up and getting going, you know, come with me and then kind of have a side talk where you just do, like you said, classroom style to get dev environment set up and stuff. So just kind of be aware that you're going to have people who are new to the community there and plan for a little bit of content for them just so that they don't drag everybody else down, you know, asking questions or feeling excluded because they don't know how to build the code just yet. Well, and in fact, the re-engagement of new people in the community is often a way to surface out bugs in not just the code, but in the onboarding process, in the, you know, the learning curve, where there are unreasonable obstacles, learning curve, that sort of thing. And so, like I've been a fan from the outside of Facebook's premise that if you're hired as an engineer, you should be able to commit code and have a push to production on your first day, right? And by the sound of it, most developers succeed in doing that, whether that's a good idea to move that to break things for us, I don't know. But I like the idea of setting as a goal that if you show up at a HackFest and you are a developer, you should be able to push a contribution of some sort, you know, a bug fix or, you know, some sample code or even a doc fix or something like that by the end of those two days. Maybe that becomes kind of more of a focus for the HackFest, is kind of bootstrapping and, you know, bringing your dead end to the community. I really like that idea. It's a good idea. And as well, like Zippin is pointing out, getting folks from different projects to talk to each other because it's so easy to ignore what that not happened when we're focused on chat, that sort of thing is a good thing to have happen at a HackFest, right? That's why I've loved many of the presentations because they've been intentionally attempts to reach across the aisle to the speak. Yeah, so I kind of like the theme of all this. It sounds like maybe if we will have a little bit more time between the HackFest, that gives us a little more time for a bit of structure. It's still probably good to have that on conference format where we can be pretty flexible right up to the day of the conference or the day of the HackFest, but allocate a little bit of time for prepared presentations, a little bit of time for ramping new participants. Make sure that we've got kind of like a newbie area or something to get people on board with the projects that they're interested in, and then also some time for maybe kind of experience hacking where we've got some project to project work or something like that. OK. OK, well, these are for the September conference HackFest. Are you planning on a public one as well as the hyper-legal one? I know some sometimes you've done like two separate things. Well, we've done. Well, there is there is a thought that we didn't actually execute on but a thought that in China, we would do a hackathon and then that would lead into the HackFest. And we just decided for bandwidth and cost reasons to focus on the HackFest. And I think that was the right decision. We've also collated these things with other developer conferences. We had one close to construct, you know, here in San Francisco. In fact, in the beginning of this year, the other one two weeks ago in China was close to the Linux con happening there. So we try to correlate them to help make it easier for people to justify the travel, I think, and other things like that. But but they're always public. Every one of these things, you know, anybody can show up with them. We hope we get the core contributors, but we want to clear that we want to even newbies to come in. Why don't we talk then, you know, there's there's more. I would encourage folks to share over the TSD mailing list if there's some other ideas here. But I'm hearing so general support for the idea of having access to the idea of keeping them open to folks and and and the similar structure just raising the importance and the profile of just sessions focused purely on getting tables of devs together to write code kind of undistracted by a talking head up on a stage. You know, and make sure there's there's room for that and perhaps even avoiding the distraction in the schedule for some stretches of that, which sounds fine to me. I always feel pressure to add to the agenda so people feel like there's always something going on. But let's do the back side of that, too. So I don't want to go ahead. Yeah, I was just saying, giving focus to Bob's comment, our recommendation that we spend half of the day in the second as in the working groups, you know, more from the conference in perspective and the afternoon, then we go back to more access, but to change the flexibility that in certain days we might do more of one as opposed to the other. I think hard side, yeah, we should look at and see if we can improve on that. So I'll go back that much. OK, OK. All right, so based on all these conversations, people still feel like it's the right thing to be focusing on an event in the U.S. mid to late September and another in Europe, which before the end of the year, probably, you know, Novemberish late October, November, maybe even early December. We do have a doodle poll as Todd has put into chat for potential date for Europe regarding U.S. We have a couple of weeks that are a bit of a noted the 14th and 15th, 21st and 22nd. There are I don't think there's any ideal date that doesn't have conflict for some folks out there, but 21st and 22nd, I think we're looking either one of these actually work for Linux Foundation staff to support. And we do have some good options in Chicago for free interest in space. That's the city that's easy to get to from spreading the world. So that's what we're looking at for Chicago and in Europe, I kind of try to drive folks to the doodle pool there. But OK, so so unless unless we hear strong indications again, we'll continue to move forward. I'm planning for those to hack that and have to be many of you there. Any other thoughts or comments? Yeah, yeah, so I just put some stuff in chat. I think a lot more people would be interested if we got some kind of toy projects and advertise them in advance of the Hackfest. You know, these don't have to be like, you know, super meaningful things. I think like the Sawtooth Lake battleship or, you know, that I mean, that may have ended up being pretty complicated, but just fun projects that people can get their their feet wet with coding. We don't actually have to have people make significant contributions at the Hackfest, you know, it's only two days and, you know, even the best people are only going to be able to do so much in two days. But we want to put people in position where they can make substantial contributions. And if we kind of get them started, get their feet wet, you know, that's oftentimes the most difficult part of the learning curve and where a lot of people, you know, stop. So if we kind of get people over that hump, then we might we might be able to gain more contributors, which I think is the ultimate goal of these things. Yeah. OK, well, thanks for the feedback, everyone. And we'll, you know, the Hyperledger staff will continue to move forward in planning these two events and we'll have to see most of you there. Why don't we talk, why don't we move on to the agenda item. Great. I think the next thing is the security code reviews and bug bounties and Brian, I know you kicked off a thread shortly ago on this. I did and I apologize for getting it laid out there and intended to kind of last night. But I'll just briefly go through it and Dave's on the line, too. And he he's going to own this going forward. So I, you know, look at him for this. But but he and I have been working him mostly actually doing the legwork in setting up two two things that we think will help reassure the public about the the security priorities of the organization for the code that goes out from here, especially code that carries a label of one dot oh and beyond. Right. So the first of those is that when we push code out as different projects get closer to a one dot oh, the Linux Foundation is willing to fund the cost of doing a proper security audit for the project. We've been talking to different vendors. We get a rough swag of about 40 K on average, sometimes more, sometimes less. We think that's important enough to fund, at least, you know, at some point in the young project's life, you know, before it gets on or soon thereafter. And so we'll take that burden on. And that's the way to help reassure all projects, you know, whether you are well, well financed trends or not. That you're part of you're part of something bigger here. And obviously, that still means that we need to be thinking about the secure coding practices after that point. Hopefully, the process of going through that will help burn into the minds of the maintainers, you know, what are what are what are code paths that lead to problems, whether the types of, you know, the sensitive programming that we should do more of that sort of thing. But we think it's suitable to do it one time. And if projects want to do it after that point and find a way to pay for it themselves, that's great. But we think that's the baseline that everybody carrying a 1.0 moniker from here should carry. The second is it is bug bounty. You know, I think it's been extraordinarily effective in certain parts of the open source world, particularly the web browser world for companies to post public bug bounties for security vulnerabilities. And that's that's a really a big way, I think, of building trust in public trust in the integrity of the code. So we've even started to engage a company that's called Hacker One, by the way. We haven't closed the deal with them yet, but we really like what they've been talking about. And they have a baseline service for bringing projects like in open source projects in particular and running a process with they have a private hacker developer community that they've basically enlisted to do all sorts of different projects. These are gray hat hackers, folks who are also committed to the standard disclosure process. And that's how they get there to be able to claim claim the prizes. Typically things like the start out very low values as you clear out a lot of the low hanging group, you know, a couple of grams or less per for vulnerabilities. But hopefully we get to the point where, you know, projects might have outstanding bug downings and the tens of thousands or more, right? I think Chromium is kind of the gold standard here. It has what, a hundred thousand dollars or two hundred thousand dollars is for bug downing. You know, hopefully, I don't know if we'll get that high very soon, but something that stands out there that says, OK, bring it, right? And you'll get rewarded for it if you follow the right process. So we'll fund the relationship with a company like Hacker One to set up this independent process. But what we will need will be crowd funding for the prizes per project basis. And so what we'd like to do is work with the vendors in this community around the different projects to fill a queue, basically, of prizes. For finding vulnerabilities in the different products. That's a good way for the I think the commercial community on each project to stand up in a test to their confidence in the code. It could be that the board figures out a way to distribute some funds equally out there as well from our core hardware literature funds. But we think the validation that comes from having companies involved in filling that that those those buckets would actually be also a really good signal. So with that, I just wanted to put it out and open it for comments. And we can take comments on the list as well. But just putting it out there. Any initial reaction? Richard, I think it's a good idea that certainly the funding, the security audit, the, I guess, the tension in any project is always when to do it. Certainly, I look at it to see corners not in this process at the moment. But the question we ask ourselves is, you know, at what point do we do it? When the situation you do it early and you you already know there are still issues. So I pay someone to tell you what you already know, they've been too late and you risk going live with no issues. So whether it's when it's you call one or no or whatever you call it. But a milestone when you're saying to the world, you know, we think this thing is is broadly ready or this thing, you know, is useful for some scenarios that kind of feels like a milestone. I think it's good at it. This is Nathan from on the Hyperledger Indie Project. The Sovereign Foundation has sponsored this kind of audit and it's in process right now. And I can't say that we found anything that's groundbreaking or really surprising, but it's been really healthy to have them digging through all the different parts of the code and also the different aspects of the design. It's helped our documentation mature and it's also forced us to answer a lot of questions that in a much more clear and concise way than we had answered before. So both the security audit as well as having a Hacker One profile have been helpful for us as a project. So I think that it would be of general interest and generally helpful to all the projects going forward at Hyperledger. Well, I'm happy to take more feedback from this. But at this point, we're moving forward on both both these fronts. And so let us know pretty soon you have strong opinions different than perhaps those directions. But yeah, thanks for the positive feedback. Why don't we dive next to the next topic? And again, this is another nudge back to a thread kicked off recently on the TSC list, which is just a quick discussion about third party dependencies and the licenses on those dependencies. I wrote up in my technical in my typical overly long fashion, perhaps. But the core thing is when you've got an open source project that depends upon products under other licenses when you have a hyperledger project, at least depends upon projects under and code under other licenses. No problem at all. It can be proprietary. It can be any other license. But it's when it becomes an issue is when we redistribute those dependencies as a part of the package that one pulls down from the hyperledger website. Right. And so when that when that happens, then what we need to do is look at those licenses and if they are very different from the standard IP policy we have in the charter, which is Apache for code and and creative comments, attribution license for documentation, then we need to that this is the standard process, go and get governing board approval for that. And I think we've been pretty easy going so far, partly out of, you know, we figured we needed the ground to settle a bit as projects made their way to one dot to figure out what are the dependencies that really need to be included in the images that get redistributed. But a strict interpretation would be even code that's checked into the repository needs to follow, you know, even if it doesn't end up as part of the final image that gets redistributed. Even that would need to get authorized because essentially because it's in our repository, we are redistributing it. So we are going to this process now with fabric. We've completed the audit of the different packages. Thank you very much to the fabric team for helping piece together all the licenses for this different third party code. And due to the nature of how Go works, we are bundling a lot of dependencies in rather than using operating systems, package management mechanisms to load those dependencies. The process has also been conducted, I think, on the other projects. I think Tracy said everything except, everything except Indy and Burrow. That's right, Brian. OK, so and we'll be covering those soon. So there should be tickets in your issue tracker for any other things that we need to go and get approvals for. But just wanted to highlight this for the developer community that, you know, this is there's there's a process around that, you know, the earlier we can address that and get approvals for that, the better, especially when some of the licenses like some of the code and fabric isn't strictly OSI approved. It's under wacky licenses like the WTFPL, which, well, looking like it's not a problem at all, still requires overhead on the part of, you know, lawyers and others to look at and go, OK, this is this is the nine. It's better. So anyway, just a flag and if there's comments on it, happy to take feedback here or on the mail. And. Yeah, I just wanted to I wanted to add, Brian, so I was thinking about what I wrote on the list yesterday. And I'll probably send out an update for that. But what we're scanning is just what's in your repository, right? So if you are building in those third party dependencies without having them in your repository, I think that's still something to be on the lookout for, right, where the license can won't catch that. It's something that the individual teams will have to catch. That's a good point. Any thoughts or comments or should we just follow up on the thread? OK, well, not hearing other thoughts. We'll move on to the next topic, project reporting. Tracy, do you want to give a restate from the message you sent? Yeah, so the last TSC meeting that we had on June 15th, we had brought up a proposal to do project reporting. And in that meeting, we kind of took the the information to the list to try and talk about it, right, where people were interested in really looking at, say, metrics instead of the project reporting. You know, and we didn't really get a whole lot of response to the information on the metrics. And so, you know, it it seemed like we we still have this open issue of how do we track projects, the health of those projects? How do we do oversight on those projects? And so, you know, I think it's still very appropriate that we we talk about project reporting and and what we want as a TSC, right, to really understand how projects are behaving, how the communities are either growing or or not, as the case may be, right, and to really understand that the health of those projects. And so, you know, this was really a request to to try and bring that conversation back to life and to understand what the TSC wants from an oversight perspective. Yeah, thanks for orchestrating that. Tracee, I'm sorry, I didn't respond on the thread there. I did review what you posted again this morning, though. And it looks like a valuable list of metrics. I'm always doing tradeoffs with what's not really what's what's valuable or what's not valuable, but what is really a tradeoff in what's the most valuable thing that we could be doing with any amount of time or resource. And I know that from at least from my individual perspective, I don't feel like I'm doing as much coding as I feel would be constructive for the project. So when I kind of weigh against doing reporting or administrative kinds of functions versus doing more direct technical contributions, I prefer not to stack more things on that reporting or administrative side. So, you know, I'm kind of inclined to hold off on more of these reporting activities maybe until the projects have another year behind them. And, you know, we can kind of see where things qualitatively feel to us like like they're growing stale or imbalanced and certainly if something acute happens, we should be able to address it on the fly, but maybe starting to build the metrics, you know, a year out from now. And so I will push back on that just a little bit, Dan. From the perspective of your role as a contributor to Hyperledger Sawtooth versus your role as a member of the TSE, right? And what would you like to know more about the other projects that are happening, right? So I take your point, obviously, that providing information and doing reporting does take time, right? But I think there's two separate roles that you have to consider in what you're playing right now. And so I would ask kind of what do you think from your role as a TSE member, you would want from understanding what's happening in the other projects? Yeah, certainly I appreciate that. And there's a distinction between roles there. I think even with wearing just a TSE hat, the kind of technical steering that I'd like to be providing is maybe being more read on things like the hash graph proposal that came through and devoting more in that technical direction. And then, you know, as we start to sense that there might be issues with project health, I think we can still address those without necessarily doing a monthly tracking. Maybe in another parallel with hash graph, we could set up an explicit rule for things or try to quantify things directly, but the amount of time that we put into trying to do that quantification might just be better spent, more efficiently addressing things that we feel qualitatively. Yeah, I think one way to think about this is there is a mandatory oversight role that has to be performed somewhere in the organization on all projects, right? From the day that they enter. And that's just to make sure that a project both isn't doing something acute and obvious and bad, but also hasn't become more abundant or something that doesn't fulfill our claims when we say when something's a hyperledger project, it is developed in the public, it follows the processes, you know, that sort of thing, right? And so that oversight function, you know, by default, if no one else did it, would be performed by the board, right? The governing board who is very smart, very capable, but I think we've succeeded for good reason in having the governing board trust the TSC to perform that role, right? Alternately, we could have the hyperledger staff perform that role. But I think in across these three different options, right? The governing board or hyperledger staff or the TSC, if you're on a project that is underperforming from those perspectives, you know, who would you rather hear that message from, right, who's gonna be more of a democratic voice in managing that, that's going down the road. It seems to me like it's the TSC. Now, by staff can do a lot of the legwork in collecting data, in organizing this process, nudging projects to the right thing. It was fully planned to, that's what Tracy's full-time job is. But at a certain point, there's a call that needs to be made if a project is underperforming, because it needs to be excised from the project, right? Or corrected in some way. And so that oversight function, I think the TSC should fight for and own as the technical heart and soul of the project. If not, we can find another place in the organization for that role to be fulfilled. It doesn't sound like it needs to be exclusive. But I mean, you were hinting, Brian, at some role for staff to do the evaluations. Does it make sense for staff to do the evaluations and raise exceptions to the TSC? It makes sense for my staff to be involved in nothing the project to be following and know whether what's being reported out from them is what it should be, right? I think there's still an important role for the leaders on that project to play in leading that, whether it's quarterly or monthly or whatever, but actually reporting back, because if there isn't that sense of ownership there, there's probably not gonna be a sense of ownership of fixing any problems that get noticed, right? So there are, I mean, the concern is status report for the SICA status report. As opposed to status report for the sake of actually evaluating the health of the project. And as the TSC, I don't wanna be reviewing status reports that were generated for the sake of generating status reports. So how do we, I mean, I know we've had all these discussions before about cadence seems to be appropriate, sort of managing exceptions rather than managing steady state, but the kind of third one is just the kind of what's new part of the projects is always nice to be able to hear and have as a common topic for discussion. Do we need to use our weekly TSC time for those or would it be possible to have kind of a quarterly longer meeting where we bring in projects for kind of a status update, status what's new, what's planned on these calls? So not take our one hour and dedicate it to that, but actually have a two or three hour session quarterly that's set aside for exactly that purpose. I really think if you take those two or three hours and spread them in the form of 10 minutes a week. So here's my concern is that when a project does go quiet, then the ability to fix that and bring them back into, well, if project developers stop using the public tools, for example, and they start privately talking about building the code, it gets harder and harder as time goes on to correct that behavior. Yeah, by the way, I was not talking about the exceptions. The exceptions certainly could come into the meeting. So it's probably like, how do you monitor for the exception and respond? Okay. I think it's more important to be agile and respond quickly when you see a community that is not responding to bug reports, is not responding to new users asking questions, right? And are fixing that within a few weeks of it becoming a problem rather than realizing three months later that there haven't been any commits or triage of bugs in the issue tracker or anything for a while, right? And this is, by the way, not related in my view to evaluating the technical direction of a project. Are they technically working on the right thing? That's still something I think, you know, is the different level of conversation. This is really more, are the projects exhibiting the kinds of behaviors we need as open source projects in terms of bringing new developers in, conducting their work in the public and showing the kind of help that they need to be showing. Ah, yeah, let it say. I took a move that... I think it's fine because, yeah, governments have to be a good thing and therefore the processes have that. So we need to ensure that there are issues that can be applied in a timely manner. How best to do that? I think FTSC assumes most of the government is functioning and it means that as soon as something needs to be done, then it's your expectation to receive, to be looked at, to be inspected before that issue is that it impacts the focus in the main project. How best to do that, I can't say, but I still think as you said, it should be at that. Well, why don't we... I'm gonna continue this over email a bit. I definitely get the sensitivity to not wanting to create real extra work. My hope would be that the template that we come up with to fill out is something that somebody who is an active maintainer should be able to respond to in 30 minutes, you know. It's not something that requires a lot of extra legwork to go get and if it's healthy, if the project's healthy, it's steady-state. It is not reporting for the sake of reporting, but reporting so that the rest of us can maintain an ambient awareness of the health of each of the projects as a high-polisher. This is just, for those who've been involved in the Apache Stocker Foundation on the Managing Project, this is a key reason for why that process, when it works, it works well. Now, perfect, it doesn't catch everything, but if it didn't happen, that community wouldn't have scaled to what their reputation that they have. Anyway, just wanted to gin that up and please take a look at that thread and participate on it on the TSC. I do think I wanna come back to the TSC with a specific proposal to vote on to adopt a template of some sort. And so let's talk about what that is, but if it is not something that TSC wants to do, we can figure out a different approach as well. But I do think it's the right thing for the TSC. With that, any other thoughts or comments? Do we call it away? If not, we can just leave it for 12 minutes back to the coming minutes. Hey, Brian, we gotta talk a little bit later this morning. Do you wanna reach out on email and just try to knock that out real quick? Send me a phone number, whatever I can reach you at. Okay, yeah, yeah, I'll be done in a minute. Okay, I guess that's it. All right, talk to everyone soon. Have a good day. Thank you. Thanks everyone. Bye. Have a good day, have a good day, bye-bye.