 All right. Welcome everybody to the March 23rd hyper ledger technical oversight committee call. As you are all aware, two things that we have to abide by the first is the antitrust policy that is currently being displayed on the screen. The second is our code of conduct, which is linked in the agenda. For announcements today we have the standard definitely developer newsletter that goes out each Friday. If you have anything that you would like to include in that newsletter. Please leave a comment on the wiki page that is linked in the agenda. Anybody else have any announcements that they would like to make today. Okay. For quarterly reports, we didn't have any quarterly reports that came in, but we do have the firefly one that is out there. That I wanted to make sure that we brought up to figure out how we get it merged. It's been over two weeks since that firefly report has been submitted. We have a comment from Rama about the screenshots that were added that they're difficult to read. According to our rules, if there's any sort of outstanding commentary on that report we cannot merge it. Until that discussion has been completed and so wanted to kind of have a conversation here and see what we could do to work through that and potentially get that merged here shortly. Yeah, Rama. Yeah, sorry Tracy I completely missed your comment I responded to short while ago. Also at this gym on it, maybe I mean, Jim if you can take a look. If you can resolve it in a few hours. Good, otherwise, I'm happy to just approve it and you can update the pictures later. Okay, we'll give it a couple of hours to see if we can get that resolved and if not, then we can potentially move forward with that to get that one merged in place. Okay. Thank you from for the comment I did see it come in just a bit ago so appreciate the response on that. So, past due reports. We do have the transact report that is past due the last that I had seen on that was a conversation that I was having with Sean about getting a list of maintainers so that we could make some sort of determination about the status of that. I'm curious as to what people think we should do moving forward with this project. I feel like it's potentially even past the dormant state where potentially it's an end of life, sort of concern. I'm just wondering if anybody has any suggestions about how we proceed with hyper ledger transact and whether or not we open an issue similar to what we do a grid to either move it to dormant or to move it to end of life. So, does anybody have any thoughts on transact. Peter. One meeting recently so I'm not sure this is all the answer or not but have we tried to contact anyone has anyone from the TLC try to contact the maintainers and if yes did they respond and. And what was that, or is it completely radio silent. Yeah, so I did reach out a couple of different times on the transact discord channel. Let me make sure I'm not getting it messed up with grid. So the transact contributors channel I reached out on March 2 to let them know that their report was overdue. I did get a response from Sean on March 3. And I think that they're going through the process of merging transact into lip sawtooth. And so there's no real project update, because the project status. Well, well he's wondering if there's a project status that would remove the need for reports, basically. But allow it to remain active to do maintenance sort of releases and I suggested that dormant was probably the closest that we had to that sort of status. Then Sean responded back a few days later, saying that for his party, not speaking for other developers he thinks the transition to dormant seems fine. I asked whether or not it was dormant or end of life. And then I asked if there was a good way to reach out to the rest of the transact maintainers to see if we could potentially get a response from them. I got a response from Sean saying he put a list together, but I never did see a list come back so trying to figure out what's the best way to reach the other maintainers since they don't seem to be active on. Moving forward, is it through the issue process. If it's the issue process, do we create an issue for moving it to dormant do we create an issue for moving it to end of life. And so that's kind of what I'm asking of the TOC is to see if anybody has any sort of direction that they think is appropriate here for moving forward with transacts. So two things I mean so you know personally I never feel like the urge to move things faster down the the project lifecycle line and so I think if we you know I wouldn't push for moving it to end of life before we gave it a chance in dormant state for a while. But I think what what if I understood correctly what you're saying show me say is they're moving basically transact into so to which means transact disappears and all the attention is going to be so to it because the people were interested in so maybe working on transact basically they're going to be working on so to. Do I get that right do you know. Yeah, that's that's correct so basically the intention is to move transact into live saw to with transact basically moving towards end of life. So once that that move is done right you can consider transact to be completed because the code is now somewhere else. And so that's that's the only reason that I would potentially push for end of life is because I think in in general it is truly end of life and nobody should be looking at transact at the stage. To, to, you know, move forward with they should be looking at saw to that that's the direction that they're interested in headed. Okay, that makes sense. Thanks. Yeah, no worries they make it clear that this is the states they are in. You know, just looking at the repo. It doesn't say anything about what's going on there. Yeah, and I think that's my biggest concern is that if anybody were to come in and want to look at transact is that they don't actually know that it's truly heading towards an end of life path, and that there's no further work that's going to be done there. Okay, I'm with you. I, you know, I think it's unfortunate because projects should be, you know, it doesn't take much all they have to do is change the read me put a warning notice. Yeah, you know in the read me to say hey, watch out this is actually this code is moving to sort of if you're interested in this go over there. You know, I don't know. Sometimes I don't know why projects don't take the like this takes five minutes. I know we are busy, but come on. Sorry, that frustrates me. Appreciate that. I appreciate that. Peter. I would base on everything that's been just said, I would do two things. Open an issue to update documentation regarding project status. And then to fix that issue, I would send a pull request. I can volunteer to actually do this. I would send a pull request that puts it on top of the read me very clearly with very large font that says that this is being merged into slip saw to that has a repository under this link. Please go there to explore whatever it is that you want it from transit specifically. And that way we redirect people who are interested into the new place. And it doesn't matter too much in the end if the maintainers respond back or not. If we cannot reach them, then we can do end of life. If they do respond back and they have a preference, then we can do whatever they prefer. And I did find a code owners file with about eight or nine GitHub handles so we could tag all of those GitHub handles on the issue that we create to update the documentation. And that way we could get a quick survey of who are the code owners who are still paying attention and what is their opinion. And then I would give it one week or two weeks for them to respond and then after that, I would just send the pull request and take it from there. Right. Thanks, Peter. Rama. Just curious, I mean, transit is supposed to be a platform independent. Provide platform independent support so if it's being merged into sawtooth is going to be something sort of specific now. And that's like a change of manifesto right, or are we saying we don't particularly care once the sawtooth maintainers have decided to accept it. Yeah, because this is a case of, you know, a project that wants to be independent but never really was it was never used anywhere else other than so to. Okay. Marcus. Yeah, I think I agree with what I know and Peter said before, I mean, it's much better to, I mean to be prance transparent here for the users who are actually going to the transit repository. And then there may be reading about it and they find it sexy they wanted to play with it. However, the reality is actually different and it seems that the maintainers trying to go somewhere else with this project which is fine. And therefore I mean creating this PR on the repository and on proposing a big fat note hey this is going, going to be merged to ABC. We can see that we, I mean just shut down this project at all. I mean, they can, they can still get the code from the repository in order to integrate this into sawtooth directly right. Yeah, I think that's definitely the case right like we're just going to archive the repository of it in the life so it would be the code would still be available for anybody who is interested in looking at that code. No, I think from the end user perspective would be much nicer to just I mean, I mean, go ahead and quickly communicate what what's going on here. And I mean, if someone then decides to hey transaction. Resurrect. Why not but as long as this is not the case at the moment. So it's good. Right. So these are, I guess you can't see my command line here. So I crept for all the transact maintainers and did a sort. These are the transact maintainers. I emailed all of these about sunsetting grid. And almost all those addresses, almost all their email addresses bounced. The only ones that were still active are like these. This one. And this one. So that's just, I just wanted to put a little bit more flavor. You know, I've already reached out to all these people, all their emails bounced. So we can do it again. I will provide another list of emails. Right. That was for grid correct that you reached out to these folks. I mean, obviously there's the same set of people, but that's the emails that you're talking about. Yeah. Yeah, those, those emails, I mean, I don't know how many. That's who I reached out to for grid. And you'll see that there's a large overlap. So I will send. I will provide you with the emails. And then we can decide how we're going to move forward with that. Okay. Daniel. I'll reach out to one of the main maintainers on these projects, Sean. I recently listened to a recording specific to sawtooth, where he indicated that he didn't know these kind of conversations were going on. So I'll have a conversation with him. I'll reach out. I'll let him know that again, these topics were discussed on today's talk call and recommend that he reach out to the talk and maybe come and have a conversation with the talk in the near future. Okay. Sounds good. And Peter, did you want to move forward with creating the issue and the pull request? Yeah, if everyone's okay with that, I can actually just go and send a pull request. Okay. Okay. Any objections from anybody on the call? Peter doing that. Okay. I see a couple of thumbs ups. I'm assuming those are for Peter doing the pull request. And didn't hear any objections. So Peter, you wouldn't mind taking care of that. That'd be great. Thank you. All right. We also have the Ursa report that's coming. Or that has passed. It's been a week now. I don't, I think I may have reached out when I put together the agenda to the Ursa maintainers to remind them that their Q1 report is due. Oh yeah, I say right here. I did on March 20th. I sent a reminder. So we'll keep reminding these folks to see if we can get their Q1 report to come in. As we move forward. And then we'll be on to the Q2 reports. In a couple of weeks. All right. For discussion items today. Two discussion items that are decisions. The first is. The conversation to move grid to end of life status. So we did get some responses. Here. Some thumbs up, but I did want to bring this up for a formal vote for today. Any discussion on that before we have a vote? Okay. No discussion. Right. Do you want to take us through a vote? Crazy. On the matter before the, I'm sorry. There is no motion before the TSC at this time. Oh yeah. I'm sorry. Can we get a motion in a second? Motion. Thank you. Peter. I second that. All right. Thanks. Okay. Now take us through. On the motion before. The, the TOC, which is to move the grid to end of life status. Tracy, how do you vote? Yes. Timo. Yes. Steven. Yes. Brahma. Yes. Peter. Yes. Marcus. Yes. Jim. Yes. Dave. Yes. Bobby. Yes. Arun. Yes. Arno. Yes. The matter passes unanimously. All right. Thanks for that. And thanks for giving me in line, right? And the second item that we have on the agenda for a decision is the update to the maintainers guidelines and the. Sample maintainers document that Steven has so nicely helped us through any comments or questions on this. I know we have the three approvals. Directly on the PR, but any other questions or comments for the maintainer guidelines. Peter. I just wanted to. Say verbally that I agree with it and I liked it when I read it. I just forgot to actually prove on GitHub. But I think it's great. Okay. Thanks for that, Peter. All right. So if there's no comments or discussion on this, can we get a motion to approve this? Motion. Thanks, Peter. One second. Sure. I'll move. Second. All right. Thanks. Arno. I'm sorry. I'm not really sure. What is the motion thing? Is there a guideline somewhere where I can read how this process works? Because I'm not 100%. Yeah. Informs on it. Which part? The vote or the updates to the maintainers guideline. No, no, the vote, like that you say, like that too, other people have to say motion and that we then get sent. Yeah. If you look at Robert's rules of order. Those are the rules that we use. And those are going to be enforced on all. Linux foundation meetings. In the future. So I'm just trying to get everybody used to doing it now. And just so you know, it's a very common set of rules that are used very broadly. Administration governments across the world. And, you know, there are some details we kind of. Skip, but I think for the better. All right, Steven. I get that for the previous one. I'm moving grid to end of life, but this is just a PR. Shouldn't we just. Get it approved by the majority of, and then when that happens, we just merge it. Just. Suggestion. Yes. I agree. I think I suggested that before. I think I just approved the PR. So I, I disagree. Slightly. The reason I disagree is that this will be a change to the governance. Okay. So I, I, I agree in general. Something like if there was already an existing. Maintainers guidance. And this was typos and fixes like that. I would agree. This is essentially a major rewrite. Got it. Thank you. Thanks. Right. Yeah. Okay. So on the motion before the TOC. I know how do you vote? Yes. Arun. Yes. Bobby. I agree in general. Something like if there was already an existing. Maintainers guideline and this was typos and fixes like that. I would agree. This is essentially a major rewrite. Got it. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Yes. Dave. Yes. Jim. Yes. Marcus. Yes. Peter. Yes. Yes. Steven. Yes. Timo. Yes. Tracy. Yes. The. Motion before passes unanimously. All right. Thanks. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thanks for holding the ban. Doing it so well. Completely agree. All right. So that takes us through our decisions and. Topics that were. On the agenda. Except for the task force discussion. Before we get to the task force discussion. Are there any other topics that anybody would like to discuss? I have two and I'm sorry I missed some of the previous meetings also due to like the conflict with AFJ meeting and so if they're already been discussed then please ignore it but I think one is the issue with like the pipeline and the runners and what the short term thing is we should do about that because it's causing quite some issues or whether maybe we should discuss that in this court but that's one topic and the other one is that meetings for hyperlature are all anchored in US time zones and as a global foundation I'm not sure if that is the most accessible to everyone and whether that is like a decision that has been made on purpose or if there's a specific reason behind that. So, as the person that usually ends up scheduling the meetings, I put them in the time zone that the person who requests the meeting asked that they are in. So, for example, the AFJ meeting was previously in GMT. It's whoever requests a meeting. In general they get whatever time zone they want when they want to do it. Steven. I'm going to say, having it in a floating or UTC time zone when the most of the world is still using time zones is a bad idea. So, I think, because it messes up everyone's schedule as opposed to some people schedule so I agree with what I said which is it's up to the person to root it in whatever but I would recommend they not root it in. It's not a non-changing ones until the world figures out that we shouldn't do these changes anyway. But anyway, hopefully that makes sense. Yeah, okay, I think it makes sense. I think, yeah, we had it in UTC and in the end it didn't end up really well because everybody complained every six months when times changed. I think it doesn't always feel like the nicest and there are some people that aren't in like, like, doesn't our work time zones change and then it's sometimes where that whenever the US changes it changes for them as well. But I think if the decision is every meeting can decide it for themselves, I think that makes sense to me. I do want to cover your first point so that everyone is aware the limit for get up runners on a free plan is 20. And we have been well over that limit forever. Get up never enforce that. A few weeks ago, without any notice they started enforcing it, which is why we're having problems. We're trying to find a more cogent solution than the one we have. And that is a discussion that I'm going to have with Daniela and heart about the CI thing. So I'm not ignoring it. It's front of mind. And we're trying to figure out how to go forward. So I had that I saw some interesting discussions in the community architects discord channel on this topic. Some suggestions around how to make how to make improvements to your actions, your GitHub actions to ensure that things are canceled. Multiple requests come on multiple commits come on the same pull request that it cancels the initial run in that you're not duplicating the testing. So I think there's some interesting conversation that's going on in the community there in that community architects channel that you know if you have any ideas or suggestions I think adding to that would be good. And, you know, trying to get everybody to think about the ways in which they might, you know, help help this problem until some sort of resolution, long term resolution can be had. Stephen. I was going to say, given rise on it and doing things certainly delighted by that and suggest we talk about it next week or, you know, once or when right feels like we can hear more I think we can be a good conduit out to the projects and figure out the communication plan for this. So, happy to defer it. It's absolutely top of mind for us and I know I know right knows that, but happy to defer it. Thank you Timo for raising it though and, but happy to talk about it next time. Okay. Any other items to discuss before we hand it off to Bobby to talk about the documentation task force. Okay Bobby I think it's on to you. Hi everybody. So that I have to apologize I've been out of service on Mondays for the past two weeks when the documentation and the onboarding task force have met. So I've caught up on the recordings, but there's really going to be a push forward on both of these task force this week as I will be able to focus on them now. I'm going to share my screen real quick. So the first thing I want to go over is the mentorship. So I have applied for mentorship for the documentation standards. And this isn't just the standards for the maintainers when they're creating documentation to read. It also has to do with like maybe best practice badges to make sure that you can, you know, train business people as well as developers on, you know, get information out to who it needs to go to. So we're going to be developing guidelines and templates and I know Tracy has taken a big step forward with the maintainers guidelines for creating documentation, and we're going to be working on that in the future. So one of the things that I want to discuss and I'm not really sure how this is going to go over I know that Peter and myself, and a few other people on the TS TOC call are reviewing the mentorship programs that are up for, or nominated for the mentorship. And a lot of them have to do with individual projects documentation. So I'm kind of hoping this week to go through those and maybe reach out to the people who supply those to see if there's any synergies with what this main documentation and maybe get the mentors working together. You know, maybe one on one project and one on other but with the same idea of a continuous look and feel for hyper ledger stuff. That are output that we produce so again I'm going to be reaching out to the other documentation and onboarding mentorship applications and see again if there's any and I'll work closely with men and David on that to see the only other let me just minimize this for a second is the actual wiki page for the overall documentation task force. Again, my to do items are survey for the meetings as we're discussing the 12 o'clock noon on Eastern Standard Time isn't really a good time for anybody but people who are on the Eastern Eastern Seaboard of the United States so I'm going to be sending out that survey more has to do with the outcome for the task force so I'll be adding to that survey a convenient time and getting it out to everybody who's shown an interest so that we can maybe meet at a more convenient time for the entire globe. So there, here's just some tasks that we need to go over. And again, if you're interested, please just reach out. There's a link to the. So this is in the on the wiki page you can just, you know, search out documentation task force and you'll get this page. And it links right to the mentorship application, and it discusses like the deliverables that we want to accomplish. And again, these are the people who have shown interest. I know I talk with john all the time so hopefully everybody else can jump on and we have a discord channel. I check that all the time too so please if you have any comments on that reach out there and again here's just some references to some tools that are made available to the community from hyper ledger that we're going to incorporate in some of this stuff. Again, this is the same as last week with the outcomes, what everybody's using and again Tracy again has worked on the get hub for the maintainers to get that done so Tracy if you have any comments on that. Yeah, I'll just add to create a lab proposal to bring in the template that I had created the documentation template that I had created into hyper ledger labs that proposal was accepted and I did transfer the repository over to labs. So it's now available I'll make sure to put that link in the discord channel. I don't think I have done that so let me let me make sure I do that. So that everybody has a reference to it but yeah if there's any sort of updates or anything like that. Anybody wants to become a maintainer for that repository, you know happy to get people to make changes and become a maintainer and to make changes and happy to add you as a code owner to that. So, like I said I'll add the link to the discord channel and feel free to to use it or make it better. Thank you. As we were talking about the documentation standard I know the onboarding meeting was held and I listened to David to the recording and we also feel for the onboarding. Mentorship as well as the task force, we want to work with the people from start here. We want to make sure that we have not again recreating information so much as just making the information available to where people go to join hyper ledger like the web page the wiki pages we want to make it easy for people who have to create something or want to want to learn something really easy to find and we feel the best way to do that is if we all work together from the developers to the business we want to make it possible to everybody so that when you hit hyper ledger you know where to go and get the information you need instead of spending a lot of time searching through pages and pages to find your what you need so we're trying to figure out how the user interface will start here for developers start here for you know is this right for your business a start here for you know you want to help the developers with presentation you know whatever whatever your goal is in the community to get involved. I want to make that easy for you. So again that task force is gearing up. We're reaching out to the start here people and hopefully on Monday everybody will meet until we find a better time and discuss anything that they heard here that they're interest to help out and again I'll be reaching out to the mentorship people if there's onboarding spots in any of those programs as I go through them to see if there's any synergies that they can be combined and put efforts together to work towards one goal. So does anybody have any questions up Peter. That's not a question sorry Bobby I just wanted to plug in that we have the mentorship project proposal coming out of the onboarding task force and after a long while of just promising to get it done I finally actually added some specific tasks to the expected outcome. Section of the document and so what I wanted to but the reason why I wanted to interrupt with this is because I wanted to make sure that the people on the committee for selecting the mentorship project proposals. Double check the document itself because if they already sort of scored it based on the content that was there before then I just wanted to ping them saying there's a little more content, a little more specific content. And that's it. Thank you. Sorry for interrupting. Oh no worries and I can check on the matrix that men gave us for the mentorships, if anybody has actually read it already so I'll double check to make sure. Thank you. Any other questions yet. I just want to maybe I don't think we ever took the TOC through this. I think we took the documentation task force through this so maybe it would be worthwhile just to have people take a look at this as we go through is that okay with you. Sure, fun. Do you want to go through it or Sure, I can go through it. So this is the lab that exists it's under hyperledger labs documentation template. It uses make docs as the mechanism material for make docs to generate the particular website, you can see that it is hyperledger labs dot get hope.io slash documentation template, which is this site here. And this is really the first page is just instructions on what would need to be changed in order to make this fit the needs of a particular project. It kind of goes through the configuration updates that you would need to change in the make docs.yaml file how you replace the logos that are here, and here on the particular website, different information about what needs to be updated as far as the documentation. That would exist is basically just mark down files that are created. So we've got concepts and tutorials and guides and references contributing in an FAQ and a glossary, and you can see those all linked up here at the top. There's placeholders there now so there's not real content in any of this except for the contributing section I did take this from other places you can see the credits on this come from the sawtooth contributing documentation. But you know this was just something that looked like it was fairly complete as far as what should be included here. Information on how you go about reporting a bug, requesting a change for a project, and then asking a question, which just basically points to chat in a different mailing list that exists out there. It's all just a template for people to use and to do what they want with it. This is attempting to kind of say these are some of the things that you should include. It's, you know, if you want to add another section or change this in any way shape or form, you know, that's completely up to the project as to what they want to do. This is something that I thought was a good starting place for new projects that might be coming in doesn't have to necessarily be a replacement if you've got a good already documentation system for your project but just something to help. The other thing I'll point out just quickly is that it does provide for versioning, although it's not really great in the template right now for the different sorts of versions. So that's going to need to be improved as we move forward. You know, with this particular template. So right now, you know, it just basically creates a point one, regardless of whether or not you're doing releases or that sort of thing. So there's going to have to be some updates to the GitHub action to handle releases and how you would create those different versions. So anyway, it's out there. If you're interested in taking a look, feel free to do that. Any comments or questions. Steven. Awesome stuff. We've been struggling through trying to retroactively put a documentation site together. My first question was going to be about the versioning so really interested to know, you know, any any progress you've made on that or any any guidance you can give on how to do the the versions that would be helpful. Presumably, this is in. I mean, it won't be hard for me to find that in chat. Make sure that that goes in there. I'm going to take a look at it and see if it can help us with what we've got. The first try we did was overly complicated. Now I think we've now got it down to reasonable. But still dealing with versions is hard. And that's the biggest thing I'm worried about. So, and definitely interested in any guidance or learning shared on on that part of it. Thank you for doing this. Yeah, no worries, Steven. So right now it uses Mike to do the deployments. You can see right now right it's very much hard coded as to just creating a point one and assigning also the latest so that you set the default to latest. But there is some examples of different sorts of projects that use this as well that are are basically on the release right the CI happens on the release and you can deploy based on the release number that exists in there. I'll find a link to that and make sure to include that as well in in what exists I think it's already out there on the documentation. Task Force channel but it's probably not easy to find at this point. So anyway, that's, that's what's happening in the current template is just really something that's very stupid but I wanted to be able to at least show that we could do versioning. We need to do versioning for the different versions that we'll have for our projects. Who's Mike. I don't know who Mike is, but it's an application that exists. That will work with make docs to do different sorts of deployments version deployments. Is the recommendation these days to put the source of the docs in the same repo as your main code repo or in a separate repo. I don't know that we have any sort of best practices there Dave. Okay. Go ahead. Yeah, I'm sorry I personally like when it's in the same repo just because I'm lazy and don't like to look for the second repo. I always like to just go look for the docs folder. But that's just me right like, I don't know that that's a good practice or not. We concluded for fabric as well and what I was getting to was the releases so we'd have release branches and fabric for minor releases and it's pretty, it's lined up pretty well with the docs. So the doc versions are just aligned with our release branches which has worked really well. I don't know if this can do that or if this would be different. I think it should be able to do that without a problem. Dave, I think that it would actually make a whole lot of sense. Basically what this does is it deploys to the GitHub pages branch so that you have basically a github.io. So obviously that's, this looks like labs.hyperledger.org but basically this is github.io that it's pointing to. Okay, so we found it's very useful to have the docs follow the same versioning scheme as the code. So if that's possible with this, that'd be really good. Yup. Peter? I just wanted to plus one, keeping the documentation source code with the source code that it documents so that they're always tightly coupled in this sense. If you tag the source code, the documentation with that automatically gets tagged as well and then there's never any question about which version of documentation belongs to which version of code. And if you have multiple repositories, they could diverge. And also if you have multiple repositories, you have to manage multiple repositories. And there's a maintainer who does a lot of the administrative chores around configuring repositories. I am on the opinion of the opinion that the less repositories you have to manage for a project, the better because you will always make some mistake where the configuration of one repo gets out of sync with another and then things just don't work because of it. Yeah, I agree. I was just raising the slight concern that it looked like the versioning here might be different from the versioning of the code, which I would not agree with, at least for my projects. But if it is possible to align them pretty easily, then that'd be great. I was about to say also that there's these GitHub variables and the ML files and the workflow files that you can use. GitHub.ref is one that you can use to extract Git tags. And so if anyone's interested, we have in cacti, we have, for example, workflows that automatically notice if the workflow is running on the main branch and if the current commit that it is running on has a Git tag. And then that's how our release automation works. It just picks up when you tag something in the code with a tag name that starts with a V as inversion. And so we could tailor this YAML file that Tracy was showing to do the exact same thing. It just picks up if you tag the source code and it automatically builds it with that tag. Yeah, Peter, I'd love to have a reference to that. I think that is exactly what we want to do and then I would be able to tie like you and Dave have said to the release that's being made. You know, this was, this was Stephen had said, Hey, can we do versioning on this? And I was like, I don't know, let me see. And so I just did the, you know, the stupid change of making it a 0.1. But I would really like to see about changing this YAML file to reflect based on how you do releases, right. So it's not tagging the release of the documentation, but tagging the release of the project itself going forward. So I'm not a GitHub actions expert in any way, shape or form. So that's why what you see here is pretty dumb and basic. Stephen. One of the things we're doing and I just want to bounce this to see if anyone has advice, but what we're doing is keeping the documents themselves in the repo in the product repo, but having a separate documentation site that is really just automatically populated and then and then published. So I don't know if that is a model that's good, bad or indifferent. It made sense to us. And especially to manage the multiple versions. But so anyway, a possibility and be interested in feedback on if that's a really dumb idea. I do have to say all of these things I will put into the task force best practices. So thank you for all your ideas. And if there's no more questions, I'll turn it back over to Tracy. If anybody does have any thoughts for Stephen, you know, definitely reach out to Stephen or raise your hand now and we can get a potentially an answer for Stephen about the best practices. They're around websites for documentation. And I'm going to take that as nobody has any suggestions or ideas that will help you at least at this point but if you if anybody does please feel free to reach out to Stephen. Or on the documentation task force even channel. But yeah that's all I had scheduled for today. No down. If there's nothing else we can go ahead and close out the meeting. Alright, well thank you all for attending and we will see you again next week, Dave I think you're up next week for the task force discussion. Okay. Thanks a lot Tracy. Thanks.