 Let's get going. For yours. All right. Hello, everyone. Thank you for joining. This is the TSE weekly call. This is an open call. Anybody can join, listen in or participate. There are two conditions to requirements to doing so. The first one is to be aware of the antitrust policy. The notice of which is being displayed on the screen. If you're online using the client. Some client. And the other piece is the code of conduct. So just behave. Being a decent human being and everything will be fine. But do not be shy if you have things to say. This is really meant to be inclusive and as people join in and participate. So. With that being said, let's get going. So we have an announcement. Somebody added this. I have to, I don't. Dan added that. I just happened to come across it. Well, I was finding something else in the community calendar. So this is something that the marketing committee does to reach out to our projects. And this was in response to. Some maintainers feeling disconnected from how their projects were being marketed by hyper ledger. But I think after Jessica got this call going, there hasn't been a lot of participation. So I think it's really in the project's best interests, the maintainers in particular to help guide how their projects are being marketed. I know that. Stereotypically a lot of developers don't want to engage in that project. They want to prioritize it, but then it seems like they still feel welcome to. Feel disenfranchised by not showing up. So do yourself a favor and show up and explain what you think is cool about your project in that call. Yep. So this has been mentioned a few times. The ideal scenario is for each project to identify one person, at least to represent them as much as possible. So we can leave it to each project to figure this out, but I agree with Dan. I second this motion to get people engaged. And I find it quite interesting for that matter. So. I don't think people should see that as a boring task to do. All right. Thanks. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Okay, so you can see that as a boring task to do. All right, thanks. Okay. Quality reports. There is hyperledge IND was submitted last week, barely before the call. People didn't have much chance to review it, but I haven't seen any issues being raised. So I'll just pass it unless somebody wants to say anything about it right now. project for the borough project, the report for the borough project. So please keep an eye on the project update calendar and fill out your reports in due time. So with that being done, we don't have much to discuss, but the first item is the common maintainers management policy item. Following up the discussion, Tracy did submit a PR against the Hyperledger repo, the TSE repo, and with a proposal on the guidelines on what could be expected to be found in the maintainers file. Some of us have been commenting and I would strongly encourage all the TSE members to carefully look at it and approve if they are okay with it so that we can merge it and call it done. I don't know if anybody wants to discuss any of it now. I mean, Tracy, you have the pen, maybe you want to say something? So I just I took an attempt at putting this together, tried to not be too prescriptive in what the document should say and contain. So the only thing that is really a must is the fact that you have a maintainers file at the top level of the project. That maintainers file could be a markdown or a rest file. So I just shortened it to maintainers in this document, which you can see kind of reflected at the very top. And then everything else in here is really a should and guidelines around how the format should look and those sorts of things. I just saw your comment come in on GitHub. I'll update this table here to reflect that your LFID is not necessarily your chat ID, which surprises me, but good for you that you managed to get that changed. So yeah, really, I think the only piece that may be something for us to discuss at this moment is whether or not we want to be more prescriptive around the how to become a maintainer section. Arno, I think you were mentioning that this seems like something that every maintainers file should have. And I had made it as a should. So I guess just some some requests for feedback from the rest of the TSE on this particular section, whether or not we want the how to become a maintainer as part of the maintainers file. Yeah, so let me clarify my position on that particular point. I do think every project has to have some kind of, you know, process that they are going to implement. And I think we indeed should have that documented and fairly easy to find. And it's, you know, I think there are two ways to get that done. One is to document it within the maintainers file directly. Or as some projects have it today, I think most projects have it elsewhere today, is to simply add a link in the maintainers file that points to where your policy is. But I do think we need to be transparent about what the process is and not make it hard to find. Because, you know, even when I was, I started on this, this task, I was just trying to figure out what the different projects were doing. And some projects I couldn't even figure it out. And I was like, where is that documented? And then, you know, I know Dan was of the opinion that, well, people get to the point where this becomes relevant should be familiar enough with the repository structure, they would figure out where it is. But I'm not really happy with that answer. I have to admit. Anybody? I just want to express my appreciation that this is put together and has the company affiliation column. And I'm interested in how many projects are using scope. I know Fabric has people who are maintainers only for docs, for example. I know that Sawtooth has some, they don't use formal scopes. I'm interested in like how much or how important that is. So, Raya, I'll say that Ursa also uses scope and we use it for our review policies too. So we denote people that have like, you know, mathematical background. And so we have, you know, special policies for reviews that sort of edit the math of crypto. They have to get, you know, extra reviewers. And they have to get reviewers that are like mathematical cryptographers. So we definitely use the scope. Okay. I think I was thinking too formally. As in like the GitHub's scoping feature. So I understand. Oh, sure. Okay. Yeah. So the scope here would be expressed as like a cryptographer or documentation, not as like a subdirectory of a thing. Generally, yes. Okay. Sorry, I misunderstood you there. No, no, I think I misunderstood Tracy. Yeah, but I think it's a good point to clarify. And maybe the document should be made so that it's clear what is meant that, you know, I think we can be fairly flexible again on this. And I, you know, from that point of view, I tend to agree with the, you know, the general direction Tracy took, which is really about, you know, providing guidelines as opposed to being really mandatory. And so this is an area where we could, you know, say, well, you could have a column that scope and then it's a bit up to its project to define how they use it. I don't think that hurts. Okay. But I suppose I could agree with that. I mean, if you don't use it, then do you need the column, I guess is the question, but no, the thing that I wanted to poke on though was this within the fabric project, we actually have, I think three or four different identifiers, you have your LF ID, you have your chat ID, you have your email, right, and your GitHub ID. And the reason that we have those is because essentially it's a means of figuring out how do I get to this person, right. And so LF ID is not chat ID. I want to make that clear. They're completely different. I don't know. I mean, Rai, you can weigh in on that. But as far as I know, there's no connection between the two at all. That was one question we were having. By default, it's the same. And this has led to issues like people with spaces in their names. But it is, it's related, it's not orthogonal. So, well, mine is my initials and my initials are not even represented in my LF ID. So, my guess is that in San Francisco, when we were sitting down in the lobby, you said change my name and I went in and changed it because I'm the person that's done all that. If you want your name changed, if anyone wants their name changed, you know, get in contact with me and I'll make it happen. So, I will make that change to include LF ID, chat ID and email columns. Obviously, they're optional, but we should have a mechanism for being able to contact said maintainer. Right. And that was, you know, when we were last, you know, last year, Salone brought up the issue that she couldn't find any maintainers and didn't know how to contact them. And it was because there was no record of what their email was, so. Yeah. But I agree with Chris on the gist of this. I mean, I have also found difficult sometimes to figure out how to contact people and not everybody gives you a contact info on their GitHub page, which is often the only thing you have. And then it's like, well, where do I go now? So, sorry, my connection dropped, so I missed some of Chris's comments, but I'm not a big fan for putting email lists and where they can just be harvested. Well, if you had been in the open source, open standards arena for longer, you would not care about this anymore. Has been out there for so many years. If outlook was better at filtering junk mail, then I would care less. That should sound. Well, so, I mean, I kind of don't think this matters because if you're using DCO, which you should be, your email address is right there. Yeah, there's lots of ways for people to get email addresses even off responses to the mail list and stuff, but I don't know. Something about just putting a list in the repo just feels more accessible to lazier people. But that's not how you find the list. Yeah, my thought was to set it up such that there must be at least one mechanism to contact the maintainer, whether or not that's an email address or your chat ID. I don't care. Okay. So, I'm not trying to make it required, if you will. I just want to make sure that the maintainer can be contacted. I agree with that. I actually put that in a comment, I believe that, you know, at least one or the other should be there because, you know, if you have one, you can at least use that. You get really in trouble if all you have is the GitHub ID and the person didn't put any contact info on their GitHub page because that's the data and then you have nothing to contact them. Well, then you have to go fish for those sign-offs and stuff like that, but it's a bit more convoluted than it ought to be. All right. Anything else? Any more general comments on the direction? Do people feel like this is going in the right direction? Because if not, you should speak up. Yeah. No, I think, don't get me wrong. I think this is great. I think, again, you know, as we were discussing, getting to some sort of consistency is a good thing. I just, I do think that we need to make sure that we provide a means for people to be contacted. And so, that's what should be written. Not a chat person, but I'm sure Brian also agree. Yeah, I'm with you, but Tracy, maybe we can put in the text that, you know, a reliable way of contacting maintainers should be documented, whether it's the, you know, chat ID or email. So that people understand this is what we really want that info. Contacting, being able to contact the maintainers is important. Yeah, so I'm going to add a note that says there must be at least one reliable mechanism to contact the maintainer or chat ID or email. There you go. Sounds good. Thanks. So there's a lot of shoulds in here. And should to me means totally optional. One of the things that you have as should is outlining how people get added to the list or removed from the list. Wouldn't that be considered something further required for the governance of a project? Yeah, I think that's where we actually started the conversation. Right, but I'm assuming to capitalize the should that you mean it in the RC 2119 sense of the term, which means you have to have a damn good reason not to. Doesn't mean totally optional. It means you need to have a really good reason why you wouldn't. Right. And then the other part is should this list be machine parsable? It's okay to have random text in these files, as long as sort of this list of information from these of these maintainers can be plucked out and fed into, I don't know, YAML parser or whatever. And the only reason, I mean, this maybe highlights Dan's concern, right? It would make it even easier. But the ultimate goal here is to make a lot of the maintenance, then the governance enforcement automatic through get hooks. So like updates to the maintainer lists should be signed off by multiple maintainers, whatever your threshold is, right? That kind of stuff. We can we will eventually be able to automate this. I mean, I guess maybe it's that would be optimizing too early, because we're not there yet. But that would be my only concern. I know that Ryan, I both work on a lot of tools that are meant to go through these repos and pull out relevant information. So I think that's a must. This is our chance, right? But what is a must? The machine parsable list. Yeah. So this is our chance to get it right. I mean, when I say our, of course, I mean, your, I don't have any say in this, but, right? No, but I'm listening. I just don't know. So how do we do this? What would it take? What kind of tool do we want to parse this is another thing. Because we also want this to be really, I mean, human readable, right? Currently, these are like markdown files or rest, and it's like, you can just, you know, GitHub has built in support for those. Did you see, I made a change, I think, to the fabric maintainers file a few iterations ago, where I added a section of links at the bottom for the GitHub links. So that was my first step towards making this machine parsable. Okay. So that I was wondering what that. Well, for one, it makes it easier to, you know, by having it by reference, right? You don't have to sit there and look at all the things. Yeah. Yeah, no, I just, I just noticed that I didn't realize you had gone through and done that. So thank you. And I agree. I think using hyperlinks certainly would make it possible. Right. And then the next step would be to add, like, instead of, like, all of those are GitHub links, because those were really easy to do with Ock. The next step would be, like, if you were going to have email links to have a tkirt-email or, you know, lower-whatever, company, you know, company affiliation, whatever those, whatever those are, to use tags and links as opposed to just text in a NIC grid. I mean, to be fair, to be honest, I can write a parser that will pull these out in this grid format. That's not a problem. I just don't like handwriting parsers anymore, especially when we've solved this problem a half dozen times with JSON and YAML and whatnot. Right. But if the TSC is going to take a stab at this, this is, this is their chance. And I just, you know, let's, yeah, let me, let's do it really easily, right? Let's, let's not make it harder. Let me get more clarification in the justification. Okay. Get hooks are things that can be run when you get a pull request or when you do a merge. And there are certain kinds of governance rules that we must follow when we are accepting patches and merges. And right now they're done at human scale, meaning the merger, the, the merging maintainer has to verify it manually. Okay. But there's no reason why it couldn't be automatic. And what I mean by that is things like the DCO sign-off. Right now it's just the sign-off line. But in the future, and I mean very soon, near future, after this summer's mentorship, hopefully, we'll be in a position to have our own signing tool that uses our own identity systems, namely decentralized identity, self-sorbent identity. And we'll be able to then start enforcing, A, you have to park your identity somewhere where we can resolve it. So either in the repo itself or, you know, anchored in some identity tool that uses sovereign or whatever. Right. And B, that all of your commits have to be, all the inbound commits to a project have to be signed by an identity that the project already knows about because then we can write scripts that enforce governance things. And specifically on the maintainers file, each project can say, you know, to add a new maintainer, this has to be digitally signed. The commit that actually changes the file has to be digitally signed by, you know, a quorum of maintainers, three of the five maintainers or whatever. Right. And that it would actually be machine enforceable. It could be a get hook script that checks the signatures, resolves them using Aries. Aries knows how to resolve dids to did documents now and get public keys out of them. And could then decide, right? Like it's part of sort of the build pass, right? The CICD, right? It's like first thing to do is to check the digital signatures on the code before we even spin up the pipeline. Anyway, that's sort of the grand vision. Something we've been heading towards since self sovereign identity became a thing and we started dogfooding. So if we do take the time now to just make a slight tweak here and say, look, this table just needs to be a YAML table or whatever, whatever you choose. It can both be human readable and easily machine parsable. And that would also then feed into this, this future that I envision that Rai, I don't know how he feels about it, but you know, it's like, yeah, we could totally do that. It would solve a lot of things going forward in the terms of having airtight regimes around a lot of the legal and governance rules that we have to maintain and enforce. All right. So thanks for the explanation. I wasn't sure we were going with this, but I think I understand a bit better. I don't know that this is the best way to do that. But one thing I see, one issue that you have right now with the way like the fabric maintenance file has been set up is you have even after what Rai did is you have a whole list of GitHub ideas, but you don't know, you can differentiate the current ones from the retired ones to start with. So it will require a bit more massaging to be able to get it to suit this kind of needs. Yeah, you're right. I mean, the ideal scenario here is that your maintainer status is actually in the form of a verifiable proof. Right. That is the ultimate way to go here. Okay. But listen, guys, and I wanted to react also, you know, Rai said twice at least, this is our chance to do it right. I'm like, come on, let's not be so dramatic. We can always improve on this, right? Right now we have nothing. We are talking about developing a guidelines to, you know, a set of guidelines for people to follow and improve the overall, you know, status of what we have across the different projects. If, you know, it takes a month or two and we say, hey, if we did this little tweak, we can make it possible more easily or whatever, we can also agree to do that. And it's not like we'll say, no, sorry, you missed the opportunity when we did the guidelines. So let's, let's. Well, yes, you're right. That's right. But maybe there are some immediate short-term gains, like we can easily measure the contributions of maintainers, if we could easily grab the maintainers list and then map it to their contributions in the mailing list and in the repo itself. Okay. But my point was, you know, I don't think this, I mean, this could be like a side project. And, you know, if Rai already has some ideas that we can easily document and say, hey, by the way, if you could do it this way, it'll make things much easier for everybody. I think we can do that. I wouldn't necessarily want to delay this task of setting up the guidelines, you know, for too long before, you know, because we're trying to figure something much more fancy. That's all. Yeah. Okay, less is more. Keep it simple. So instead of the line with pluses and dashes, can you just go left bracket, left bracket, maintainers, right bracket, right bracket, that makes it a YAML table. And don't know. Okay, you guys can figure this out offline. You can discuss the tricks that could be used on improving the format. I'm happy with that. I don't want to spend more time now on discussing different hacks we could use at the formatting level. Let's go back to the substance. There was one point I wanted to go back to, and I agree with Chris's point on the meaning of should. There's a difference in standards world, right? We use must, should, or may. Optional things you say may. Should is not completely optional. But I do wonder if we shouldn't make the documentation of the policy, I think, is important again, and I would make that a must. I don't really care where it is, and we have a lot of should about what the policy should contain, but I think it's a must to have the policy documented. You have to have one. So it has to be, it should be written down, and we should have that documented, and it should be readily available. Anybody disagrees with that? No. Just a note there in all the standards work we've been doing, should is something really not desirable, because people don't know if they need to or not, and they usually just ignore it. You want to make the requirement a hard requirement, and then explain when it's not a hard requirement. So I like this change. Okay. I like should, because I like the light touch on this. I think we're kind of close to this space where we're, we have the potential to just start creating rules, because we've run on of other things to do usefully as technical governance. So, you know, particularly for like smaller projects that have a single maintainer or something like that, having them author a maintainer policy and go through a bunch of stuff when they're kind of maybe struggling to keep the basics of the project going. Do we have a project with a single maintainer? I don't know how many maintainers we're up to on Quilt, but at one point that had a single maintainer. I also think it's not uncommon to have a project that has four or five maintainers, but where one guy's doing the bulk of the maintenance work. Yeah. This is I because I'm going stir crazy looking at all of the GitHub repos. There are a lot, there's a lot of abandonware and this is a topic I was going to bring up later. Once I was able to more carefully characterize that, but you know, Aroha and Sawtooth and well, those two in particular have a bunch of repos that were created, populated and haven't been touched in a long, long time. And that was a question, I guess from me to you, is that okay or not? Okay. Okay. So let's not get into this now, but I think it is an important question. So we should definitely have that on the agenda for later. But so, okay, I take your point though, maybe should is reasonable enough. It achieves the main goal to provide direction without being too draconian and start dictating everything. So anything else? Otherwise, I'm happy to leave it at this. And then I think we can finish it off through PR comments and whatnot on the proposal that Tracy has been working on. Yeah, I just wanted to let you guys know that I did just do a push to add the stuff around having a reliable mechanism to contact the maintainer and then short kind of description of what scope might look like if it existed. So that those things have been pushed already. Okay. If I could ask the TSC, for this repo, how many votes do you want before merge? I mean, I could make that zero or I could make that like 10, right? What's the number that you want? It should be a quorum. It should be the, you know, majority at quorum. I don't know how that works, but... So not to open a whole other dialogue on it. But that should normally be the case. We know getting people's engagement can be a problem. So another policy I'll just float is that you have the kind of two plus one policy that we use in a lot of the projects with the caveat that it can't be merged within a week of being submitted. That way, everybody's had a chance to put their input in. All right. I mean, of course, for something like this, I think it's totally fine. The reality is if we were changing something much more important, I'm not sure you would feel that way. No, no, I wouldn't. So I'm fine with sticking with the quorum voting rules and just moving that over to GitHub. But let's keep an eye if people aren't engaged, then we might have to loosen them. I'm not completely opposed to what you were saying. I totally feel, you know, like the same, like, hey, let's not overkill, you know, let's not kill ourselves over this. But I just don't know if we're going to regret if we just say in general, this is the repo where we're supposed to document everything right forward, where we're going to converge all the rules and decisions we've made over the years. So there won't be all these documents on the weekies and whatnot. And so I'm wondering, you know, when talking about the project life cycle, does it only take three people to say, yes, let's change the life cycle? Maybe not. So I don't know how we, you know, how we manage that. My part is that we keep the GitHub repository just a minimal review, and then we let things be reversible on the call. It makes it so that things like, you know, minor text edits, like if Dave comes up with an improvement on the formatting, don't require a full discussion every time. Yeah, that's not a bad idea, actually. That's kind of the way weekies work too. You allow people to make changes. And some people freak out and say, oh, no, we can't, we have to control access. And you say, no, you can see who's done what and reverse it if needed. And in practice, it works much better than people expect. So I think that's a reasonable proposal. And I, you know, I trust the TSE members would not go crazy and change the project life cycle really nearly for that matter. So it's really rhetorical. All right, so based on that, I made my mind, I agree with the simple rule of like, what was it? Two plus one or something like this? As I just discovered, you can only set it to six. That's the max. So you could set it from zero to six. So no, no, but let's not even go that far. Okay, two is enough. That way we don't have to go fishing for like, you know, all you really have to do though, or no, is, is look at the contributing dot md file for this repo. And then you'll see what the policy is. Yeah, I hope so. I know it's not there yet, but Dan, I guess that's your job now. You know, on that line, in that line, I have to tell you the repo linter repo is not also is not compliant either, which is kind of funny. I've been trying to address some of that. All right, I think we're done with this. So the last agenda item for today is the frequency of those TSC calls. So Dan sent an email saying, Hey, how about we switch to every other week? Seems like this should be enough. I'm not opposed to it. I think, you know, realistically speaking, if you look, I mean, maybe, you know, if we'd be okay with that, I, you know, I'm not opposed to it, but I have to say, first, historically, if you look, we haven't had to cancel many calls. And in reality, we use most of the time on the calls all the time. And so maybe we will miss something. And things tend not to move between calls. The calls tend to keep a heartbeat, force people to pay attention, you know, do their reviews of the reports and that kind of stuff. There is a risk if we make it two weeks, that for two weeks, almost nothing happens until the call finally comes in. And things will slow down as a result. And, you know, for proof, I think you can ask Tracy, when did she got the comments from people like myself and others on the, on these guidelines we just talked about, you know, it happens at the last moment before the call. And so that's my concern. But you know, I'm not opposed to it. So I'm bringing it up for the group to discuss. I can't do it though. This is Chris. You know, I respond to saying, I don't know that we're there yet, where we only need to meet once every other week. You know, we may have had a little bit of light agenda when everything was hitting the fan, you know, a couple of months ago, and people had other things on their mind. But I don't think we have a shortage of things to work on. And I'd like to keep moving in this direction where we're getting a lot more engaged, and we're working towards trying to bring a little bit more collaboration and so forth. I think we have a lot of work to do in that regard. And so I'm not a fan of cutting back. So you had said something in your note about project collaboration. And I was wondering after the fact, wonder if there was a different forum for that, where we got the maintainers in on a recurring basis. Because I still don't know that the maintainers generally are well engaged with what happens here. So our ability to affect that inner project collaboration has always been kind of limited. There is a maintainer's email list, which is basically unused. What more would the TSC like in terms of fostering communication and collaboration? Yeah, and when I said forum, I meant discussion like this TSC call. So if we were to alternate weeks with the TSC meeting and a maintainers meeting or something like that. I don't know if there's interest in that. But my point was that for us to meet as a TSC on a weekly basis doesn't necessarily solve the issue that Chris was pointing to. Anyone else who hasn't heard from a lot of people on something that should matter to everybody? Sure. I see arguments for both ways. I mean, sometimes we talk about relatively, you know, inconsequential stuff, but a lot of times we do have full agendas. And I think to Chris's point, if we can use the TSC meetings to sort of push more inter-project cooperation, that would be fantastic. So in my experience, for this to happen, somebody has to make concrete proposals or something, you know, put on the agenda. And you know, I always call for agenda items. The reality is, you know, pretty much nobody ever suggests any agenda item. It's very rare, right? Yeah. No, that's that. Go ahead, Tracy. Sorry. No, I'm sorry. So I was just going to say that, I mean, I feel like we can keep them that weekly. And if we don't have something we can cancel, which is what we normally do, especially like around the holidays and those sorts of things. But like today, a short agenda, right? We're currently at 15 minutes still, right? We spend a lot of time on that pull request, which I think is great. I think having the discussion is good. Obviously, I'd love to have more discussion offline. But, you know, I do think that we're, we have the opportunity to make some progress on different sorts of things. I look at, you know, the fact that we want to bring over all of the current governance documents to this repo, right? Are we going to have conversations when we do that? Or are we going to bring it over as it is and then make the changes? But at some point, I think there's going to be a lot of discussion around even that governance documentation. So my, I guess my recommendation is keep them weekly. And if we don't need to have it, we cancel. All right. Thank you. Anyone else? Nathan, for instance? I think we need to, instead of reducing the number of meetings, we need to work at filling the means with better content, I think we still have some unresolved things about how we help people engage with one another and cross project collaboration. You have some things about how the architecture of, you know, community events works, which is hard to talk about right now while everyone's kind of locked down at home. But there's, there's a lot of those issues that we just haven't really taken the time to address. And I agree with Arno that a lot of that's going to take initiative on our part to propose them and put together something to actually completely discuss. But we don't, we don't do that by having less time to discuss them. We do that by having more things to discuss and pushing the cream to the top. All right. Thank you. Anyone else? All right. So I'm not hearing much support for switching to every other week. So we're going to keep it weekly for now. I can, you know, commit to canceling maybe less, you know, with less hesitation than maybe I normally do if I feel like the agenda is too light to be worthy. And by the way, feel free to respond in that, you know, in that way if you feel like, hey, I'm not sure this is worth having a call this week. Let's postpone to next week. And, you know, I'm definitely welcoming input on that. And I think we can go from there. But I have also no problem. I don't know how other people feel. But for me, it's easier to hold this on my calendar on a weekly basis and cancel or keep them short. You know, if the call we're only half an hour, I'm totally fine with this. I can use the other half hour very quickly for something else. It's not going to be a problem. So while, you know, creating a new, inserting new agenda, new invites is always much harder. So can you find no comments or reactions? This is not a great fun of meetings in general. So for me, it would be nice. It would be fine even once per month, as long as there is enough to discuss and something important to discuss. Personally, that's my usual approach also for work for inside my company. Because most of the time we, it's a waste of time. So that's my, not to refer into these meetings, but in general, the less meetings, the better. I would say because there's work to do. That's, that's also the thing. So that's my personal opinion. I understand. Anyone else? All right. If not, then is there anything else anybody wants to bring up now before we close the call? All right, hearing none. I don't see any hands raised either. So I take it we're all good with calling it today. So well, thank you all for joining today. I think we had a good conversation and I think it was helpful in moving forward this issue on the guidelines. So I think it was time well spent personally. But let's keep the discussion going offline. And we'll talk again next week then, although I take it from what you said, Dan, you won't be able to join us, right? So yeah, I'm on vacation too. All right. So we'll have so few people missing, but that's all right.