- Discuss documentation structure spec from Joao Luna
- Docs site 2.0 next steps?
- Look at new documentation added to Gitbook recently
- Update on Console Documentation (if available)
- Date: Tuesday, February 28, 2023
- Time: 7:00 AM PT (Pacific Time)
- Recording
- Transcript
- Benjamin B
- Denis Lelic
- George Pro
- Joao Luna
- Robert
- Rodrigo Rochin
- Scott Carruthers
- Tyler Wright
- Pain points for non-Web3 users: Tyler Wright brought up that dependencies outside of Akash but required to create deployments (e.g. crypto wallets) can be a pain point for users who are not familiar with them already. An example are the full wallet and funding steps, where users need to install wallets, understand how the wallet works, figure out how to acquire AKT, and spend time going through these friction points in the deployment process.
- Is the proposed structure agreen upon? Scott Carruthers highlighted a number of factors and questions that may not yet be finalized and have answers yet. The question that Scott Carruthers is asking is whether or not finalizing these details should be done within the SIG or through a working group.
- Which client should the user first be introduced to? Tyler Wright asks Joao Luna whether or not the user should be introduced to all clients to begin with. Joao Luna responds by saying that the first deployment should be done with CLI before the user is introduced to multiple tools. Scott Carruthers asks if the documentation will be written under the assumption that the new CLI is released or not, to which Joao Luna responds that it is not.
- Which platform is the best to create a user-curated experience? Scott Carruthers expresses concerns regarding picking an appropriate platform for hosting the user-curated experiences, as it is not possible through GitBook.
- What should happen to the current documentation? Tyler Wright says that creating new documentation from scratch would be an enormous task and opens up a discussion asking what efforts should be prioritized: updating the current documentation, creating new documentation, or re-writing current documentation to fit the new structure.
- Pain points for non-Web3 users: To the issue that Tyler Wright brought up, Scott Carruthers mentioned it would not be as big of an issue if "Economics 2.0." included stable payments.
- Is the proposed structure agreen upon? Joao Luna mentions that the documentation structure can be developed over time and that it shouldn't be too big of a focus to begin with.
- Which client should the user first be introduced to? Everyone involved in the discussion agreed that the learning curve is too steep and that the CLI experience is too bad to introduce users to the current CLI for an introduction to Akash. Tyler Wright and Joao Luna agrees on that multiple paths could be created for users to choose between, with short explanations for each. Scott Carruthers also strengthen this point by adding how docs 2.0. in his eyes should be a "user-curated experience."
- Which platform is the best to create a user-curated experience? Joao Luna mentions that the discussion has already taken place and that Hugo would be appropriate, to which Scott Carruthers agrees that he also believes it would work. Joao Luna also says that a sandbox environment could be created for the user-curated experience, which could be referenced from the documentation but be hosted elsewhere.
- What should happen to the current documentation? Joao Luna says that the current documentation is valuable in its restructured form and that there is no need to discard it in the beginning and create everything from scratch. Furthermore, Joao Luna mentions that the navigation is what should be improved and focused on for users to have a smoother experience.
- Find someone that can setup Hugo: Joao Luna mentions that he will likely not start the Hugo project, but that he might (it is a stretch) be able to find someone in 2-3 weeks if nobody volunteers. Joao Luna adds that he wants to be kept in the loop in case someone volunteers. Tyler Wright will write in sig-docs regarding trying to find someone from the community.
- Migrate documentation to the Hugo page: The participants agreed that the current documentation should be used and migrated over to the Hugo page once it is set up. Both Joao Luna and Benjamin B mentioned that they are able to help migrate documentation, and anyone is welcome to help with this.
- Discussing changing the structure: Tyler Wright says that if anyone has anything they wish to be changed in the structure, they can place comments on GitHub or create a thread on discussion regarding the topic.
- Adding possible new documentation topics to future agenda's: Tyler Wright wants future meetings to also include discussion on which documentation to create based off what community members are requesting and what does not yet exist.
- Since the last meeting, Joao Luna has started work on the specification regarding documentation structure.
This editable transcript was computer generated and might contain errors. People can also change the text after it was created.
Tyler Wright: Right. Welcome to SIG Documentation monthly meeting. Number two, I'm going to put the last monthly meeting.
Tyler Wright: Information from the last monthly meeting in the chat. But really, the agenda for today is really around. Out of last meeting, we talked at high level about the state of documentation, Greg attended to that meeting and gave some of his thoughts, on how he would like to see documentation improved over time. Scott has been leading the documentation efforts for Overclock, Labs, for well, over a year and has gotten to us a guide us to a point where we actually have documentation for most things in the community has been able to take that documentation and actually implement again, new solutions, new features, etc, on the network. But again, as we evolve into Doc, Docs 2.0 out of the last meeting, Luna develop the PRD or beginning of a spec, rather, for documentation structure. And I know that some people
Tyler Wright: Viewed that but I thought we could take some time to go over it from the start and see if there's anything that we want to add or any additional feedback that anybody from this group wants to give before. We start to think about how we're going to map out docs 2.0. So, without further ado, again, we can just get it started. Can everyone see my screen right now with a link to the work that Luna's done.
Tyler Wright: Cool, excellent.
Joao Luna: yes, like
Tyler Wright: All right. Um, so again, at a high level, you know, I'll just go over this again, The scope is about the structure of the documentation. So, like, you know, the flow, the content, the mapping of how users go from docs, various areas on docs to other areas on the docks. Some of the things that out of scope is anything related to like in-depth blockchain concepts. I know that there's another effort that Scott Carruthers is leading about developer documentation. So for those that are trying to understand go, those are trying to understand the code base, no code for, for providers, and on the node side, there's some separate documentation being developed, but this is more so for again,
Tyler Wright: As Luna's outlined first time, users frequent users, and then just like developers that are looking to build on top of Akash. Does anyone have any questions or thoughts about any other user characteristics that we should be thinking about as it pertains to our docs datacos.network?
Tyler Wright: Cool. I would agree with first time users being You know somebody that we want to have the documentation be like really appealing to and so that anybody that doesn't know about Akash comes to Akash very quickly. Go to website, goes to the docs, they can kind of navigate and start the process. Without like too much searching too much, adding too many apps doing too many things. Frequent users is obviously something that we also want to.
Tyler Wright: Focus, the Docs on, you know, there's a number of people that we've sold that the community, you know, members of community believe in Akash, they use Akash frequently. And so, as new features new functions come out, we want to update the docs. So that again some of those frequent users can unlock that functionality on the network for other users. And I think the last group that and Luna correct me if I'm wrong but this is more developers like yourself like the groups like Prey Tour and Cloud. Most that are you know, doing it for specific workloads. You know and and adding it to their workflow as well as developers are. Looking to build tooling and clients and other things on top of Akash. To leverage the decentralized.
Joao Luna: Exactly. Yeah that's yeah. That's exactly.
Tyler Wright: Perfect. Scott. Dennis Ben, George, do you all have any other user groups that you think or user characteristics that we think we should like highlight that are not mentioned here?
Scott Carruthers: no, I think and…
Tyler Wright: Cool.
Scott Carruthers: end users, which are Are marked with first time users and frequent users. And then the developers in it. No, I don't I think that Hits the user characteristics.
Tyler Wright: Beautiful. Cool. All right, I see Ben and George also commented. Um cool. We'll go we'll move on to the assumption section now um, I think again some of these assumptions, make a lot of sense, you know?
00:05:00
Tyler Wright: You know, we assume the first time users are not familiar with the cost network and cryptocurrencies. I think one thing that the Overclock Labs team has been thinking about in the past and this is for up for community discussion is there's been a real focus on Web 3 users. So obviously with the some of the limitations in the product for Akash as it pertain as it stands right now. The real focus has been folks, that kind of already understand, Web 3, Understand crypto, a little bit understand how to use a wallet and then up up gearing them to use akash for some of their compute needs.
Tyler Wright: I I do think that makes sense that we want to assume that some folks may not be familiar with Cryptocurrencies, but I think that also to your point about to Luna's point about dependencies, that brings in another element of now, folks have to get a Kepler wallet. Understand what a Kepler while it is find Akt, take this extra step, which is again, something that has been outlined in the documentation. But I know this might be A pain point for those that come from web to or elsewhere. I don't know Scott. If you had anything to add about as it pertains to like the dependencies of getting folks, especially newer users to understand what the wallet is and maybe some of the things that you've seen. In, in the support realm as pertains to that.
Scott Carruthers: no, I think the only thing that I would Highlight as obviously some of these dependencies and they familiarity with with crypto will go away if we introduce stable payments. So
Scott Carruthers: Yeah, that's obviously dramatically going to impact that that could reduce the friction if we Introduce stable payments as part of economics 2.0.
Tyler Wright: No. Absolutely. Absolutely. Um,
Tyler Wright: also assume the limited knowledge of cloud software technologies. I think this makes sense as an assumption. I do think and we talk about this with Cloud parody. I do think when there is the idea that we have limited knowledge of cloud and software technologies, I do think it's a job at the documentation or tutorials or guides to provide case studies, and examples. So that folks that may not understand cloud software technologies, at least understand how things that they do in the right everyday. Life can be leveraged through the cloud and software technologies. I think it's something that we as an organization and that thing is kind of separate from the docs have to do a better job of is kind of incorporating. Here's an example of how to use it, you know. That's kind of low-hanging fruit and maybe we can determine what how, you know some of these new users.
Tyler Wright: Come to use Akash out of the gate when they're first trying things out and then make it easier for them to do those things.
Tyler Wright: Cool. Moving on to frequent users Freaking users are soon to be looking for quick copy and paste. Examples, And/or, Quick references, I think This is something again We just kind of talked about with new users But I think it's more This is something I know Greg's always found is like you know as a developer or it's a frequent user. I think something that Greg wants is for things to be as easy to do as possible. So he could just grab some code real fast. You can understand via the docs, what it does, and you can just drop it in and then implement it right away. So I know that's something like in the docs 2.0 that he wants to make a focal points, just like easy to understand where the code is and then how to copy and paste it so that developer or frequent users life is as easy as possible. Even at the documentation is like clean and clear. I think ease of use and ease of copy and pasting is important.
Tyler Wright: um, developers are assumed to be looking for client documentation Java, go and or Yeah, I think there's something that we're working on with client libraries as well, as the developers docs. So, I know that there's some folks in the community as of recently, Pablo and some others via Neil that have been trying to understand, you know, the go code and the setting up environments a little bit more. I know that's something as we continue to make this radically open source that again, Scott Carruthers, our tour, and some other folks, from the Overclock Labs teams are really prioritizing that so that other members of the community can build that environments, spin things up, really quickly. And then again, contribute and even larger ways and they are now
00:10:00
Tyler Wright: Cool. Any other assumptions that we feel like we haven't covered again Scott, I hate to keep on calling you out but you've been working Around the docks for a while, but more importantly been working well in support. So you kind of see when folks, new users frequent users, the questions that they're asking the things where they're caught up and probably have a better understanding of some of the assumptions that we should probably take into consideration.
Scott Carruthers: Yeah, I mean I think for our immediate needs and at this point these assumptions are fine.
Tyler Wright: To go ahead. Luna.
Joao Luna: and yeah just touching a briefly on a point that you mentioned not related to the documentation who is the responsible to for this new environments, set up initiative that you are taking on from your site from the overclock clubs I
Tyler Wright: Yeah, absolutely. So that is an effort that Carruthers and Archer are working very closely on. I don't know. Scott wants to talk about today,…
Scott Carruthers: If?
Tyler Wright: but I know that Luna you are somebody that Scott wants to.
Tyler Wright: Have look at the developers documentation in, it's like in experimental state and give any feedback. I don't know. Scott, if you want to talk more about that now.
Scott Carruthers: Yes, I think specifically around the environment set up, that's something that Archer has been working on. So So, I guess there's two things,…
Joao Luna: Yeah.
Scott Carruthers: there's the overall documentation around, you know, the deep dive into the the code base and developer documentation that overall documentation, I'm working on specifically, the environment set up is something that Archer has been working on and he responded in a discord. Response recently that he expects to have environments set up documentation done in the next week. So specifically on that front hurters working on
Joao Luna: Okay, yeah, I'll try to sync with him because I do have an idea. For or settings the environments up that maybe you'll be interested but I don't want white jacket. The documentation meeting.
Scott Carruthers: Okay.
Tyler Wright: No, you're good. If you could put that in Sig chain, that would probably be great. Right. That
Joao Luna: Okay.
Scott Carruthers: Yeah, I think that's where the previous conversation was when were that's where the previous conversation is, and that, that's where our chair committed to having someone within the next week. See, I would agree that that's probably the best place to post.
Tyler Wright: Yeah, I do think and we can probably talk over time. I do think that elements of that documentation should be a part of this SIG, so I don't think it's a waste of energy. Luna, if, in future meetings, we want to highlight how that's progressing. I know it has a slightly different user base but Again, I think that falls under like SIG documentation, it's not our major major focal focal point, which obviously is docs Dot Akash.network, but I do think that documentation is important, as we continue to move forward, hence, why we have Scott working on it.
Scott Carruthers: Well yeah so it's important. We have those conversations. Yeah and then it's just a matter of, should we have a SIG specific for. End user documentation than a six specifically for developer documentation or but we can decide that in the future.
Tyler Wright: Yeah, exactly. I would say right now. No. And I would also I know that out of last week, we, we were theoretically talking about a working group That focuses on docs 2.0. I am of the belief right now that we should take this time for the six docs and try to We have a good group right here. We can we have us? We have a spec authority that we're obviously going through right now. I think we can take the next steps and just straight implementation or like strategy and then implementation without having a specific working group. I think this again, this SIG is already done a good job of developing, a spec. We're talking about next steps and we can just go straight into implementing if we need to have more frequent meetings, while we're in that implementation phrase, I have no problem, but I don't know if it needs a specific work in group, if we're going to be doing the work straight out of this SIG,
Tyler Wright: And then again, I would also make the point and then we can discuss this later that the documentation that Scott is working on. the environment documentation should also be fall under this SIG, ultimately
Tyler Wright: cool.
Scott Carruthers: some of my only thoughts on whether the work comes directly out of the cigar, the working group it would be based on And this is actually something that I was interested in getting in to during this session as the mechanics behind how we're moving forward. So when we consider those mechanics then, Tyler, I would this be appropriate to bring into a working group and have discussions within that working group, or do we just want to do it as part of the cigarette. It really doesn't matter to me. But it to me, it seems like we have a ton of mechanics to really, the only thing that we've discussed at this point. is the the proposed structure that's at the bottom of the screen now, and I think even that was not Intended to be a finalized draft but it was some of the Luna created and then I think we were going to have some working sessions around discussion and possibly even start to get into that today. But to scrutinize and determine if this is our
00:15:00
Scott Carruthers: End state or if others have opinion on what the structure should look like. So I think that needs to be more structure or conversation about the Proposed structure and it might may end up being what we have here, but I don't think we've really got into those discussions. And then also, when I talk about the mechanics of how we're moving forward, I don't think there's been any discussion yet of the mechanics such as Where is this being hosted and things? Like are we taking existing documentation and basically just restructuring into
Scott Carruthers: Um, this new structure or is he ever here to completely overhaul? Our documentation. So, even things that are already created. We're going to go through, and scrutinize, and possibly recreate that documentation. So, I think we need to get into all those discussions about the mechanics of how we're moving us forward. So I don't know if we would rather do that within this SIG or talking about those mechanics would be appropriate for a working group.
Tyler Wright: I think those are all wonderful questions. I think that we should start talking about them right here. And right now, I know that this is the requirements and the functional requirements outlined by Luna or just, V1. And I think you've actually put it up on here that their V1 but again, I do think it's in we can comment in here, we can talk about this between meetings but I think some of the points that you just talked about are worth talking about in this discussion today. Go ahead. Luna.
Joao Luna: Yeah, I just want to to add that this is this is The first version could be considered a draft. It's basically based on on research, on other open projects and mostly also Kubernetes. I did design it to be.
Joao Luna: It's not like a fixed structure in the, I think the way that it is oriented, it's kind of scalable with more stuff that comes. With time. There. We should discuss this.
Joao Luna: If you want, I can present the structure and the functional requirements.
Tyler Wright: Yeah, that would be that would be stupendous Ben. Are you able to talk? I'm trying to understand what you're saying and know that you may not be able to inmates. I want to add that I can't contribute much to this discussion to be safe. Not sharing information together for them, another project. I just don't understand that last part. But maybe that's just me. Oh, all right. Yeah, sorry about that. Go ahead, Luna.
Joao Luna: Okay. So yeah, from the functional requirements perspective, there is really not much that I added For now. I think regarding the communication, we shouldn't just start it. We should start small. So the only requirement really for the documentation of this functional, is that it should be available. It must be available in English. We should not prioritize other languages as for as of now, although they should be concerned as soon as we have the presentation. Ready? Not for now, we shouldn't focus our efforts on that. And that's really the only requirement I see. I don't know if you If you. If you have any,
Joao Luna: I I guess we could argue that we could have more fine-grained requirements, such as the user, should be able to get started in five minutes. I guess that's, but I'm not really sure whether it would be functional, or Or some other kind of requirements but I do I think I specify that below so that thought was not lost. It's just didn't make it to the functional requirements list but from learnability and from usability is perspective. I think I'll find it there exactly the first time So these are things that we should strive for. So, for instance, that's those five minutes are really important. We want from one to be able to have their own website or a Hello World website as soon as possible on a cache network can see that it works instead of like wasting 20 minutes and Spread the word that it doesn't work. I think this should be something that we should strive on on.
00:20:00
Joao Luna: The documentation. I know it it will be hard, it will be a challenge. We don't have a faucet. We the user should find to be quick. It's should be familiar with with crypto or at least not to use a wallet, which is, well, not for everyone. Yeah. So the first chapter, I would say our first section would be setting up the environment. This would be setting up the environment variables and setting up the overall machine where we assume the user will be running their first deployment. And subsequent deployments.
Joao Luna: This includes stuff like exporting the variables to the BIOSHARE C file. So on startup, the user has the environments, installing the binaries that are required the provider services, for instance, and explaining those variable variables briefly, but the user should be able to just copy a copy like a code, a code snippet, paste it and have the environment setup, all the variables, everything And then the next session or subsection would be. Doing the first appointment, which could be. Really, really should be really, really simple here. It can be with the current CLI or later stage with UCLA that we discussed.
Joao Luna: with Frank and that would simplify So imagine if we have that new CLI, that would abstract stuff such as having to beads on having to accept the beads and querying the beads and all that stuff. We would omit that at this stage, we will just have something like Imagine the new CLI is called. I don't know. CLI we will do CLI create deployment and specify like the SDL file and the user wouldn't have to worry about all that stuff of creating the deployment, sending the manifests creating the lease. Accepting querying beads. So that this action should be as simple as possible and that's the goal. Yes, Tyler.
Tyler Wright: Um, I think this makes sense. My only question is when you talk about getting started, I think I love that we have the CLI as a as a path and it obviously should be one of the main paths I believe that when 90% of folks deployed on a cost or using cloud. Most um, my my question to you is in this like first deployment section is the idea that we would have all the potential clients there so that we could walk folks through like again. As we work towards this like deploying in five minutes or left less,…
Joao Luna: Here.
Tyler Wright: like if the CLI is clunky, Can we have folks? All right, if cloud most, here's a tool that you can use console, here's another to sphere on FLEEK and it's like one. Click to that tool to a deploy, or like what those tools are best used for with that fall in this section or someplace else.
Joao Luna: I made I put it in the section 5 the guides but we could include like as a third subsection on this one section called Like Third Party Clients or…
Tyler Wright: Mmm.
Joao Luna: other clients. And it would be basically like an explanation or a brief explanation on how to do that first deployment but we the other tools So not like it as detailed as the first deployment or not like required to be as quick as the first deployment. But like so for instance, deploy with cloud modes and we send a link to our show like some screenshot or describe little bit. What's cloudmose and deploy with Tyler? For we give a brief.
Joao Luna: Description of, What's the telephone provider some links? And it's kind of like you did. Your first deployment. You should always run your first deployment with the CLI and then you can explore these other tools. so, I do think from a developers perspective that the first contact that they should have Should be the CLI, of course.
Joao Luna: A The better design the CLI appear Of course I think it has been discussed at the current version of the CLI is not as user friendly or developer friendly as we'd hope. But we should strive to make that as well as an experience as possible.
00:25:00
Tyler Wright: Makes sense to me. I don't know. Scott. Do you have any thoughts on that?
Scott Carruthers: So I think foundation is what's important. Here is Are we writing this documentation with the assumption that the new CLI will be available or we writing the documentation under the assumption,…
Joao Luna: no, we are not assuming If there's a new satellite,…
Scott Carruthers: that the okay, so I don't
Joao Luna: this first deployment would be simpler with the current CLI. It might be a little bit harder, but we should also strive to have a deployment in less than five minutes. It can be a little bit more complicated. But the good overall goal is in five minutes. The user has a deployment and then a yellow World app running that you can see Either, with the new with the new CLI, or with the the currency alli.
Scott Carruthers: Okay, so my opinion would be if and so I think we have a number of people here, I'd be interesting to get prospectives of many from within the room, but my personal perspective is we're making the assumption of the new CLI is not going to be available and we're just assuming current state that we would not want a user's first experience to be the Acostioli.
Joao Luna: Yeah.
Scott Carruthers: that's,
Tyler Wright: I would I would agree with that, especially if it's like a first time user. Um, or really like any user.
Tyler Wright: You know, that's not like a Luna, you know. Because I think there's a Significant learning curve that we've that Overclock has seen in the past has turned some individuals off to the network in general, because the first touch point has so many has so much friction using the CLI.
Joao Luna: Yes, I do agree. I do agree.
Tyler Wright: Versus that. This is why I was asking about the first deployment because I know that theoretically we could take like some really The shoestring together like duct tape together,…
Scott Carruthers: It.
Tyler Wright: path to get like a CLI deployment in five minutes. But again it would be such a high learning curve that my my question was. Could we have like alright terror if you're trying to do this, use Terraform, If you're trying to do this use cloudmose and then it just fit under that one Getting started column. Because something that we discovered out of the SIG, I had the working group for the cosh website Julius brought this up, is he thought that? It'd be great from a storytelling standpoint and Denis. And I agree that when you go down the page, you can understand some of the, like, the clients out of the gate and…
Scott Carruthers: If you.
Tyler Wright: you can go from the homepage of the cost network and…
Joao Luna: Okay.
Tyler Wright: click into a terraform, our cloud. Most, and get right where you need to, go to start the process, you know, as opposed Yeah.
Joao Luna: Okay, I like that. so, we would Okay,…
Scott Carruthers: Yeah, and… actually that Go ahead, Luna.
Joao Luna: so, we would basically make these your first deployment as like, let's say, three separate pages. So your first deployment and you choose between each tab, whether you want to do it from the CLI through terraform or through like cloud modes. That's that's how I imagine what you're saying, right?
Tyler Wright: Yeah, or like, it could be any number of clients, you know. It could be like a week for a sphere on a fleek,…
Joao Luna: Yes, yes.
Tyler Wright: a console, whatever. But just like having those paths and maybe like one or two sentences on like the best use cases for those specific clients, you know, if you're used to terraform,…
Joao Luna: Okay.
Tyler Wright: this is your path if you're used to,…
Joao Luna: Yeah.
Tyler Wright: if you if you're a new user and don't know what a cautious at all. Use cloud most or console, you know, if you're, you know, like we could figure that out what the terminology.
Joao Luna: Yeah, that's perfect.
Tyler Wright: But yeah, cool.
Joao Luna: That's perfect.
Scott Carruthers: I was just going to say, so I think this is an important foundationally to this discussion as well that we don't necessarily have to think that Documentation 2.0 is Documentation one dato, but just better structured like using the current like if we think about it in its current form and get book it doesn't. Yeah. Documentation 2.0 does not necessarily need to be
Scott Carruthers: Our current get book documentation site but just better organized, right? Like it could look completely different. And I so going over like a year ago there are a lot of discussions about and this would be important aspects. So we Denis could be involved in and we could go down the path. I think. This is what we're basically suggesting now is when somebody first access is the documentation site is not just a get book structure documentation site, but it's a user curated journey. So you see this a lot with like Solana and other crypto projects where if you research documentation site it's a curated journey of, you know, like a box or several boxes linkable boxes that you depending on the user journey and where they're heading, they can click on a specific journey and then go down a curated path. So there's a lot there and a lot to consider, but just my overall point being again. Foundationally, this doesn't just need to be get book.
00:30:00
Scott Carruthers: 2.0. It could be and I think this is what we're currently discussing the getting started or your first deployment could be more of a user created journey than just flat documentation.
Joao Luna: Yeah, it does.
Scott Carruthers: Does that make sense?
Joao Luna: And I think Touching on that point. Something that would maybe be worth the effort and solve some of the problems regarding the faucet would be to have some kind of like small interactive page where the user would go through the process of creating an appointment. So, for instance, you would be running commands on his browser. But like not really running against anything just that Whatever, the user types goes to a back-end that has like a wallet and some some security measures and limiting factors.
Joao Luna: Where he would be able to, for instance, we would provide. So, this is your address and it has like an X number of tokens try to create a write this to create a deployment. Now, write this to have the bids now from the list of paid,…
Scott Carruthers: and,
Joao Luna: and we could show like, Imagine half the screen would be like a command line and the other half like Quick guide and insights into whatever. Is the output from the left? Something more like interactive. I do like the idea would be much harder to implement, but maybe it will be worth the effort. Maybe it could be something. For like an acathon theme as someone would build this experience. But yeah, just ideas to complement. What you said, I do understand the vision.
Scott Carruthers: It.
Tyler Wright: Descriptions and some of the boxes and then he threw. A reference say, I want to put the what Scott put in. The chat as well.
Rodrigo Rochin: Yeah. So what? Yeah, like I was imagining a section. If you go down the page, it might come. There's this boxes for tutorials in a short description. are what that password would do it if it's a beginner into mayor and then, and it's if you go down quite a bit more.
Rodrigo Rochin: There. Something like that. What Scott was talking about to?
Scott Carruthers: Yeah, that is what I was generally. Yeah, that that is Talking about.
Rodrigo Rochin: I mean something like something, similar.
Scott Carruthers: Yeah, yeah. And you could Tyler,…
Rodrigo Rochin: I'm sorry clicked on the card.
Scott Carruthers: if you want to click
Scott Carruthers: Um, Tyler if you want to click on the Solana, getting started link as well. That's another representation of what I was talking about. I'm and I'm not necessarily saying that I love this. I think this could probably be done. a little bit better, but just again, to paint the picture of Salona documentation is not just simply You know hardcore text-based documentation but more user curated journeys, which then if you click on one of those then it's going to drill down into specific, hardcore, documentation. But again, I think just foundationally these concepts of how we're guiding users is gonna be very important to documentation.
Scott Carruthers: So I think we're all, I think we're all on the same page that that's Well, I don't want to put words in anybody's mouth. Um Luna what it what is your perspective on this? Is this generally, what were you thinking? That getting started would be some of this years. You're curated journeys as well or…
Joao Luna: No, I do.
Scott Carruthers: do you you like this?
Joao Luna: I do like the idea of great journeys from my side that I think some, the only thing that I think we shouldn't like, put on the side is the five minute rule so it's really that's that's the main And they use that, of course, the expiration should be as good as possible. So,
Joao Luna: I will agree with everything.
Scott Carruthers: Yeah. Okay. So I think one of the things that's important with this and…
Tyler Wright: Absolutely.
Scott Carruthers: I don't want to get ahead of ourselves, but obviously our capability of Developing this kind of user interface is going to be and coming on. What? Platform. We're using so this one to be possible and get look and I don't think anybody is suggesting or believes the future is get book, but I think currently,…
00:35:00
Joao Luna: Oh, we we have discussed you go as far as I know.
Scott Carruthers: they Yeah, that's I think that's probably the the path is using Hugo.
Tyler Wright: Yeah.
Scott Carruthers: I don't know who would be doing? They development on Hugo, but again, maybe that's getting out of ourselves a little bit.
Joao Luna: I mean even even let's imagine we indeed end up using it keep books. I don't think we should be limited by that. The first, the first department page could be just like a small paragraph saying, a girl to this website and it would lead to send like something like a Sandbox.a Cash dot network and it will be the user created story or documentation, like the journey, the journey, and where he would grow through, its first appointment on a browser based interaction. so, we shouldn't be limited even if like, Kid book ends up being a requirement for some reason.
Tyler Wright: Yeah, I would say that we're probably not going to go against get. We're not gonna go with get book because of the opens, open nature. We I'm I have to imagine this is something that we want to host in Github through Hook Hugo, Um, versus like having to credential everybody for get book.
Scott Carruthers: Yeah, I mean, get book is integrated with Github as well, so you could go through the same PR, kind of flow, but, yeah, I don't think anybody believes that Github get book is the, the future and I think it probably is Hugo. So, again, I'm just kind of interested in Actually, when we start Creating work and and actually launching it this project where those development efforts are coming from. But again,…
Tyler Wright: Yeah.
Scott Carruthers: that's quite getting that of ourselves a bit.
Tyler Wright: I mean, I do want to add to it because you have brought this question Scott. I know that Ben put in in the chat. I know Benjamin is somebody that had may not be able to contribute specifically to these conversations from a strategy perspective. But has said, he's able to write documentation down the road. So I know we have some folks that are like committed to writing documentation. I know some folks that can't make this time for the meeting. But I've also talked about documentation, but I do think the fundamental thing is Um that Hugo piece. I know that Greg previously attempted to transfer the stuff from Get book to a Hugo and I know that I think you need some help during that because he's got other things to these focus on. So that's a big effort that we need to us figure out who can support, but Scott to your larger question.
Joao Luna: If?
Tyler Wright: Ultimately, I do believe that the over time we can scrutinize and improve quote unquote, I guess. Um, some of the documentation but I'm of the belief that there's been a lot of great work that has gone into getting the documentation to…
Scott Carruthers: and,
Tyler Wright: where it is right now. And the first step would of to me of docs 2.0 is taking the current documentation, maybe updating like the getting started, or some of the areas where it doesn't kind of directly line up with the structure that we are kind of talking about right now that Luna kind of outlined. But we start there and we just start updating the documentation over time as opposed to trying to create a new effort where we're starting from basically scratch and rewriting documentation because that is a hell, a heck of an effort, you know, that will take a long time.
Scott Carruthers: Yes, so that's a happy to get into this conversation. So Luna I was actually wondering your perspective on this because I would largely agree with what Tyler just said. I think there's some things like We would make the assumption that getting started, that section needs to be created. From scratch, it doesn't really exist today, especially the user carriage journey, so assume that that section. And I think there's some things in like the architecture section, like getting into user, overviews for Containers and Kubernetes. We don't really have that documentation today. So there's definitely some things primarily getting started that we need to be developed a new because it doesn't exist today. But as you were going through, I know that you you shared that this documentation structure or largely borrow from Kubernetes. So, I will, What was your perspective on this? When you were coming up with these sections, where you thinking that they first iteration of this is going to be taken?
Scott Carruthers: The current documentation especially like around providers and things that take a very long time to create the documentation, taking that pre-existing documentation and fitting into the structure or were you thinking that instead that this was rather a journey down like going through and recreating all documentation to fit into the structure.
00:40:00
Joao Luna: So, what I was thinking is taking what's already available on the computation? So not discard, what has been written already. So, because it has value It's,…
Scott Carruthers: Okay.
Joao Luna: it's not that we are with documentation to the roads not that we are replacing. The current documentation feature is we are these first stages, we are Restructuring it the value is still there.
Scott Carruthers: Okay.
Joao Luna: We just want to to have it in a structure,…
Scott Carruthers: Yeah.
Joao Luna: that's more appealing. And more easier is easier to navigate. That's, that's the That's the goal and also help the user through the journey. That was great here. Create the mental model in a way that makes sense for them. And and have these if you if you look at this this is layered in such a way that the more you go down.
Joao Luna: The the deeper knowledge you'll get from the network. So we are not considering like providers to be a deeper knowledge. It's once you go to. Once you survive the getting started, you start with the simple concepts. Like It's a provider it's deployment but what are beans and lees is what's like this sack g-sec all sec and these did for instance those the second alsac world. Something there were on the on the previous documentation, we're not.
Joao Luna: I know that now there is something, but it was not mentioned much on documentation artist, was not easy to find. Also the condition regarding the SDL and what are validator notes, so, to separate those from the providers, because that's a point of confusion that I saw people having. Then, once you survive that, it'll be like, Okay. Now I can I do understand the concepts. Let me dive into the network. What, what does it provide? It provides deployments. It provides presentation storage. I believe is GPUs. Okay? I don't understand the services that they provide Now. How is this all working together? How is architecture? Okay, so this is using Kubernetes and…
Scott Carruthers: and,
Joao Luna: containers behind the scenes. it's
Joao Luna: I have the the Akash node service running. Okay, does this this and that I have the provider service, what does it do? And so on maybe the US the hostname operator as well, if we want to go to that level.
Scott Carruthers: Yeah, yeah. The and that's how I was interpreting the structure when I first reviewed this as well, when I think it, that makes perfect sense. So, going back to the original point, just want to make sure that it was captured that we're going to repurpose a majority of the documentation today. Obviously, there's a lot of stuff here, that hasn't been written yet. So, I think we're gonna get a great contributions from the community for that.
Joao Luna: Yeah. Right.
Scott Carruthers: So, yeah,…
Joao Luna: Yeah. Regarding these documentation.
Scott Carruthers: the same page. I also love
Joao Luna: I do, I I can write it as well. So that's something. I'll be open for documentation, I'm not sure on. I'm not,…
Scott Carruthers: If?
Joao Luna: I'm not really sure that I'll be able to
Joao Luna: Start this, at least with the yugos stuff, I haven't really touched it. I think we should and I don't really have that time to start that you go project. But once that is set up, I can I can start contributing to to the documentation.
Scott Carruthers: Yeah, and I think those are some what to separate efforts that Hugo just renders marked down files, right? So, anybody could write a documentation and mark down and then they the effort to actually hosa would then Hugo possibly could be a separate.
Joao Luna: Yeah.
Scott Carruthers: So, yeah, I'm sure we're gonna get some great contributions from yourself on documentation. Writing. Benjamin is also been communicating in chat that some of the he wants to contribute to. So yeah, I think we'll get a lot of great community contribution and I also love era if you survive getting out of the getting started. It's, yeah.
Tyler Wright: I love that too. That made me laugh that made me laugh. Um alright, I also appreciate Luna. Um you know, with all your efforts, across very sigs, where you can support and you can support, I think that's great. One of the things that I want to make sure that we do out of every special interest group is start to, as figure out where folks can directly contribute. It sounds like we need to find somebody from the community that can help with the Hugo setup process. And then we have a number of people that can then take it from there. So I do think that's the next act item that I will.
Joao Luna: Yes.
Tyler Wright: um, try to figure out through the community is have somebody set up the Hugo because it seems like Right now, we have a preliminary structure. I know the structure is just V1 and we might change some things but I think this is a good structure to start with. Unless anybody has up any objections and like try to get, try to start the process of moving, docks over and then refine from there.
00:45:00
Tyler Wright: Say something.
Joao Luna: No, no, I was going to agree and I wanted to add Keep me in the loop on, on the, on the search for someone to work with the US. If we can't find someone for like in the next two, three weeks. I'm I might be able to to get someone, but it's a stretch. So we'll try to get someone from the community. If not,…
Tyler Wright: Okay.
Joao Luna: the will will work it out, but I'd like to be kept in the loop on that search as well.
Tyler Wright: Absolutely. I'll put all that information as it pertains to finding somebody in Sig-docs and we can just monitor from there.
Joao Luna: Perfect.
Tyler Wright: Cool. Um I know we have about nine minutes left. I again I think this was a great conversation for me and I'll we'll map out some of these action items after the meeting. But really it sounds like the next action items are if anybody has anything that they want to. Um, change as it pertains to the structure that we've walked that we've walked over or talked over today. I think we should put some comments in either GitHub attach to this or just start a thread in discord and then we could talk about like updating the structure updating the structure over time but the real next marching order is it sounds like we agree on the structure at least as it pertains to right. Now, we agree on using the existing documentation. transferring it over and then where there's gaps filling in those gaps with new documentation, but the
Tyler Wright: the process is again, really around finding the ability to set the Hugo and then transfer some of the stuff over and then we can go from there.
Tyler Wright: So I was a little long-winded, I'm like looking at three things at once is that is that a fair list of action items for out of this SIG that will hopefully have in motion. But by the time we meet next month,
Scott Carruthers: Yeah.
Joao Luna: Yeah.
Tyler Wright: Cool. Is there any other documentation from anybody, whether it be Rodrigo? Or anybody else of stuff that you think that we should is not in documentation right now that you think should be.
Rodrigo Rochin: A thing that comes to mind right now. But, you know, this could
Tyler Wright: Yeah. Yeah, absolutely. That's another thing. As an action item between meetings if anybody sees and if any of our insiders or anybody from the community, or anybody that joins this SIG says like, Hey, I can't find documentation on X subject, please put it in the documentation, we can either help you find it or we can determine if it's something that documentation should be made for. I want to have that as an action item or excuse me as an agenda topic at the end of every single documentation meeting is we'll talk briefly about any new documentation that we should talk about adding to the DOC site.
Tyler Wright: Cool. Is there anything else? Anybody wants to talk about?
Tyler Wright: And terrific. Well, again, this was a great, great conversation. I'll post some additional messages in SIG documentation. When the notes are available in, the recording is available, as well as how the search is going for somebody to help with Hugo. If anybody has any additional comments as it pertains to the work, that Luna led about the documentation structure, Please comment again and github or in discord so that we can continue to refine this. But again I think this is a great starting point. So thank you Luna for putting this together.
Joao Luna: No problem.
Tyler Wright: All right, y'all everyone have a good rest of the day. There is a couple other meetings, I know, sick, economics tomorrow. So please take a look at the schedule. If there's anything else you want to join this week?
Tyler Wright: Alright, Yo have a great rest of the day. Thank you again. All right.
Joao Luna: Thank you, cheers.
Meeting ended after 00:49:37 👋