 Hey Peter. Hey Rama. Nice to meet you. Sorry for being late. Can you hear me? Yep. Yeah. Hey everyone. Yay. Give me one second. I will do the screen share, screen agendas, can you see my screen? Yes. Ellen recordings on. So I'll just say welcome everyone to the Hyperledger Cacti maintainers meeting. Please abide by the antitrust policy notice and the Hyperledger Code of Conduct which you can find linked to on the agenda document. And with that said, documentation is the thing we're here to discuss. Before we go there just a couple of quick things for me to get out of the way. Okay. Isru, do you have the original for that diagram that you linked to the other day? Which one are you talking about? Sorry. I feel you could discard that I have linked the discounted asset trade image BNG. Oh probably if it's not in the GitHub I have to a little bit look around to find that one. So I'm going to discard the asset trade image. Oh image has only. Yeah I mean yeah. Image slides here. The original is also definitely in the GitHub. I think original is in PowerPoint or something like that. So I have to look into my local or corporate folder. So give me some time to find that one and if I find that one I'll tell you about that. Thank you. Okay. Thanks for that. The other thing is there's a Sandeep Omondas small PR. So it's very minor thing. I approved it. Can you guys? Peter also just approved I just saw. Oh Peter also just okay okay I approved it this morning I think for last night sometime. Okay okay sorry about that. I didn't check the status. No problem. We can move to documentation then. So yeah so where there was a particular site and a particular format that we are supposed to publish documentation right? There's recommendations but there isn't actually anything mandated by the TOC. It's just best practices which I agree we should follow but also if you have a good reason not to then we can just do that. Okay let me just quickly send you a link. Are you putting it in the Zoom chat or Discord? Zoom chat. Okay yeah I know this one. Right so we have to I think if you click on the get started what we have there this is what we have to import and put inside a a larger set of documentation on around cacti. So there's a few things that need to change inside here as well but I need to first have the packages up so I can then run some tests and then make some changes in the tutorial instructions. So how should we go about that? My idea was that menus are tree structures. The same way that directories are tree structures so we could just do for now the all in one kind of merge with there being a top page in the documentation that says hey this is cacti it is at the moment or for now it's consisting of two larger components or component libraries or whatever you want to call it as the old cactus code and weaver code and so there's two menu items cactus and weaver and then basically what you see right here this entire menu structure is what goes under the weaver menu item and whatever we have on the other one which is the cactus read the docs.io thing can go under another one and then we can slowly after that we can start actually changing the documentation piece by piece but at least this will get us into the common website the common structure so it will be a big step even though we will not have updated the documentation itself it will be more of an administrative change to begin with but it will still be a huge step because we will have to move probably both of the the entire documentation both of those will have to be moved to some other directory or something uh yeah that's that's my idea if someone has a better idea i'm all for it this is what i came up with as a first step no that's kind of my idea as well i would i think we can just add a third just third high-level menu item saying integrated system or whatever and have the our roadmap ideas that including the integrated architecture diagram that we can offer oh good point we already worked on that so we should put that in the common structure yeah sorry actually i liked your idea but i have one question about the timing because is it okay to just say there are two documents here and and ask architecture to agree that it can be shipped as version two point zero point zero or do we have to clean them up before releasing the version two we should clean it up a little more before we release the GA like the final 2.0 okay and that doesn't have to be perfect but yeah sorry about that no please finish it so yeah it does have to make sense as in yes if if you really just have two big complete seemingly completely independent sets of documentation then people will get super confused so we do have to eliminate at least some of that i don't think the toc would nitpick too much on it but it is a very reasonable request if they ask it which i think they should or would for us to consolidate so that for anyone who comes in fresh who doesn't have the history of what we were is or was what cactus was they should still be able to understand what this whole thing is yes as long as we adhere to that i think smaller like duplications or extra information that wasn't strictly necessary because it's documented somewhere else or whatever i don't think those things matter too much it just has to not confuse people who are first looking at it yep thanks yeah i i agree with that about the g itself do you think when we have that and also at the time i'm expecting we can come up with that example that we can show can be triggered in two different modes using two different sets of components can we then make a pitch for graduation yeah if we have working examples and we have the artifacts published and they all work and we have the tutorials or the examples working with those published artifacts so that if someone wants to actually do it and implement it they can and they don't have to copy paste the entire frameworks repository just to get it done then i think we are at the point where we can apply for graduation but it is important that it's a framework with reusable components that you can use so i want us not to encourage people to just copy paste the entire source code because i've seen people who tried to do that because for some reason they just want the mono repo and they want everything and they don't want to create their own project from scratch but then it doesn't work the way you'd think it is because instead of installing the dependencies from the published sources from the published repositories like npm and and the rust crates registry instead people just end up building their own project within the source code of the framework so i think that's the big litmus test of whether it's actually ready for usage or not as if if you can build things with it without having to copy paste the entire repository okay i get what you're saying i think we haven't had the problem because we've actually used this people have used weaver published packages and some projects there was the one that you've heard me mention before the one we did with the bank of france and hsbc and there's another one that's ongoing which hopefully we can share sometime over the summer it's getting just getting towards its conclusion so i think yeah what we want to do is just show that you can do that through cacti as well so uh at least for people who have been using weaver in the past so okay let's uh i will uh yeah i'll work on the example and let's try to get that let's try to get one example together that that will be a big big step on that actually did you see my i don't know if you got a chance to see my message last night about quilt and ilp uh there's a guy the pc student in italy who emailed the toc saying asking about quilt which has been uh which was sunset sometime in 21 the last comment i saw there was in february 21 and so i was wondering if that guy's interested and i replied to him accordingly you can probably hear emails uh maybe try and get that pulled within cacti i think that would be that'd be good but we have a ilp is one of the uh the the things that the sort of it's not exactly standard but it's a uh it's just kind of standardized protocol that people use uh for interoperability and i think it'd be good to have something uh representing ilp within within cacti because we are like a broad family of protocol i think it's a good idea the only question i have is if it do bring that code in who will maintain it that's a good question and if meteo is willing to do it then we can uh we can have him otherwise yeah we don't need to deal with this question like right now it's uh i just read this if meteo wants to if he's interested he can reach out to us and we can we can talk about yeah yeah if if anyone is if there's literally anyone out there who puts their hand up and say yeah i'm going to maintain that then that's it you have my vote they should bring it in as is and then we can figure out the rest later i think uh if he because code already existed in quilt i guess uh what should we do it's like what other people are doing right the ursa is being important to aroha and uh there's something else that i mean being important uh we need the toc's permission to get the code from there to here if uh if we are so inclined to lose it honestly we might not even need the toc's permission but i think it's just uh polite to to kind of say it before we do anything you know say hey if you're going to do this and it's the quilt maintainers like the old quilt maintainers are they on board or or do they not care or just so that if someone has a problem with it then they can voice it but i don't see why they would have a problem and also even if they do like i don't think they can actually do anything about it if if there's someone else out there who will maintain it yeah and they want to maintain it under cacti it's all apache too anyway so no one really owns it that way so we can do what we want yeah okay hey i'm also done uh so i didn't have anything else i think we covered what you wanted to yeah yeah shoot i also have another meeting uh i can i can stay for a few more minutes it's not a big deal if i'm late but if i mean if you're done then we're done then it's good just wanted a quick like uh where do we uh port it the uh like the weaver docs are right now under the publishing it to doc is ours so where would you publish the joint documentation well i would vote for either the one that tracy recommends in the best practices or to read the docs thing just because both of those support i think they both those support uh the versioning so you can select on a drop down if you want to see the documentation for 1.0 or 2.0 or 1.1.5 or whatever and i think that's important because there's going to be once people people start using it a lot of them just won't upgrade and then they will want to have access to the older documentation as well okay you have reference between the two uh i mean if you're gonna rebuild it from scratch anyway we might as well just do the one that's recommended uh the the one from tracy okay because uh either way we are going to have to move everything around it's going to be a big huge pull request even if we don't actually change much in the text of the documentation so then it's a good time to make a drastic change like that and then it's good because we're filing the recommendations makes sense okay let's go with that cool all right then if nothing else i'm thanks for joining sorry i was late uh i'll talk to you next time see you bye bye