 All right. Welcome everybody to the February 16th type of ledger technical oversight committee call. As everyone on this call is aware to things that we must abide by the first is the anti trust policy notice that is currently being displayed on the screen. And the second is our code of conduct. All right, for announcements today, we have two announcements we have the standard that weekly developer newsletter that goes out each Friday. If you want to include something in there about a project release the pull request the community event or anything that you have that you'd like to include. Click on that link and find the lady find the link for the upcoming newsletter and add something there. My announcement that we have is related to the hyper ledger mentorship program that has kicked off. We're currently looking for mentorship project proposals and those need to be in by March 15, and we will be having been talked to us more about what mentorship program is in case you have any questions related to that. We will get there very shortly. Are there announcements that anybody has before we head to the quarterly reports. Tracy, can you hear me. Yes, I can hear you. Good morning. I just wanted to let everybody know last night I went to a developer week it's a developer conference here in the Bay Area, and hyper ledger was awarded the Debbie for blockchain web three and cryptocurrency in that category. It's great there's hundreds of people there and you know a lot of folks came up to us and talked, you know asked about hyper ledger, and I would recommend that we look at making sure we submit lots of talks next year because there's definitely interest in the work that we're doing. So, congratulations to the community for that. And it's on Twitter, I think I put some pictures on Twitter if you want to go take a look at it on our Twitter profile. Thank you. Any other, any other announcements. No, okay. All righty so the quarterly reports. So we did get a row hot in it was on the agenda last week's but we didn't have it on the agenda last week so I made sure to include it here for anybody who hadn't had a chance to take a look at it. We do have some, as far as I know I haven't looked this morning because I've been in calls for the last hour and it's only eight o'clock here, but we have some of those quarterly reports that hadn't been reviewed by everybody in the TOC. I do have a question about what we want to do for the quarterly reports now that they're on GitHub do we want to wait for everybody to review those quarterly reports before we emerge them do we want to have the majority of us have had to review it before we emerge it or what sort of thoughts do you guys have about about getting everybody to sign off before we merge. Like my suggestion would be to give 14 days time for somebody to review and, and if it's still not reviewed in the TOC should be reminded, but PR can be merged within that period. Okay. I support the same idea there should be a period of time specific that is there to read yours can I ask questions already. I was just sad that if there's any ongoing discussion that is just for any reason still going on after the 14 days or whatever time you choose then we shouldn't merge until everything's being discussed. Thanks, Peter, right. Well, Peter in a room just laid out exactly what I was going to say that it should be up for a couple weeks, some short bound period of time. And if they're an auto merged and if there's ongoing conversation. You know, give it a little give it another meeting or something. So, I agree. Okay, thanks for that. Yeah, so some time out policy makes sense for me but so what was the approach when the reports were on the on the wiki. So they were kept on the agenda for for like, so they were put on the agenda as soon as they showed up. They showed up on the Thursday of a TOC meeting, they were put on the agenda for the next week so that people who might have missed it previous week could review it and then they were not put on the agenda again, and most likely forgotten there's I would guess probably some some reports out there that still don't have checkmarks from some of the TOC members in the past. So I guess that's maybe a similar sort of approach that's being recommended here is that two weeks and then merge unless they're still ongoing discussion. Okay, but so what about the case where, I mean, nobody has a TTC members would basically, I mean, approved this thing I mean they reviewed it but don't approve because they're just not happy with the contents, then they're just the time out would make so much sense right. Yeah, we I mean we've never really had the case where people weren't happy. Right. I don't, we've always discussed that there's been any sort of concerns that were brought up in the, in the quarterly reports in the TOC call. I don't know that we could resolve any sort of potential issues that might exist out there. But yeah, I don't think there's really been any case where you know somebody's been like I'm just not going to approve it because I don't think that it's valid. They either didn't approve it because they, well I don't know why they didn't approve it because. Yeah, I'm not that person so I can't, I can't speak on their behalf, but. Right. I mean I just think that I mean the the GitHub term approve is maybe a little bit misleading right I mean it's not that the TOC here approves the contents of the report they just, we just use this as a tool to mark that we basically reviewed it. Right. That's correct and if anybody does have comments and they provide those comments directly. All right, thank you. So I think I think there is a way to catch that case that Marcus was talking about is like, you know, I think the policy you talked about is pretty good, but I think the catch is to say, after two weeks, we need a majority of the of the talk to have approved. And if there is no ongoing discussion or issue that was raised then we can merge it. And that would allow for the case where somebody has raised an issue, or not enough people are really looked into it. Could I ask a question along these lines. So this report's been here for a week. The majority has approved it. Jim is the last remaining TOC member. Should this just be merged? I mean, there's, I was looking down here. It's not been two weeks. So no, we wait another week. Okay, well that's what I was getting at. Like, it's not just the majority. So okay, so we're going to wait by two weeks. Sorry to be super pedantic here. No, no, but you're right. That's what we need to write the policy so that we agreed this is it. By two weeks. Do we mean two TOC meetings? Do we mean two calendar weeks? What if the meeting is canceled in the interim? Like, what do we mean by two weeks? I say we, I mean, you. That's what I was going to say today. From the time that it was submitted is how I took that to me. If anybody has any objections to that, please, please. I agree. That's what I was going to say too. Okay, I'm getting some thumbs up. Hey, this Jim here, by the way, I just approved it, but I still wanted to double check. Did we say unless it's being united unanimously approved, we don't merge it. I think what we're saying Jim, I think what we're saying Jim is we wait for 14 days from the time that it was submitted. At that point, one of two things is true. We do not merge it. If there are still ongoing discussions, we do not merge it, or if there hasn't been over half of the TOC members, we don't, we don't merge it. Okay. Is that makes sense to everybody? Yeah, sounds good to me. Okay, so for this sawtooth report. And then wait, wait, one more addition to that. If everybody has approved it before the two weeks, we can merge it. Okay, so I agree. So this sawtooth report was submitted on the 31st. Yep. So I don't see any ongoing conversation. So this should just be merged. I would agree with that. Right. Any objections to that before? Right. Right. That better not be an objection. Not an objection. Governance by GitHub, I think is a is a. Is is an important thing to get out in the community. So the whole request model that that you're talking about and the need to write things down and the right and the need to have exemplar versions of using this is really helpful. I've been trying to push this site type of governance. You know, so many times governance documents get written in Google Docs. And they're really hard to use for reaching consensus and this type of consensus that we're talking about I really appreciate this quite detailed discussion and this idea of getting it down to a concise set of notes. And, and, and sharing this out with others because other projects and the whole idea of the centralized governance. The, the, the GitHub model or the use of pull requests and get how to do this type of things to do human governance based on this type of contribution model is actually, I think super important. So I think we, that's one thing we can demonstrate to the community and encourage others, you know, the projects in the community to do this type of thing. You know, to reach consensus on these. So thank you. So I am going to what I'm going to do is I'm going to take the notes that I just written up he's a post note, I will submit a PR to the GitHub repo with basically what we agree to. You guys can check my wording and see if it's correct. And make a comment here if not, and then we'll get that merged into to ensure that we've just captured the discussion that we've had. Okay, that's the only comment that I had on the quarterly reports any comments from anybody else in quarterly reports before we hand it off to me to talk to us about the hyper ledger mentorship program. So thank you for that discussion men over to you. We're interested to learn more about the hyper ledger mentorship program and what we can do to help. Yeah, thank you Tracy. Thank you to the TOC for giving me the opportunity just to talk briefly about our annual mentorship program. I think many of you on this committee know that hyper ledger foundation runs an annual mentorship program, and this is actually our seventh year of running this program and the program has grown steadily over the years you know we started with five mentorship projects to last year we have 30. So, I think it's growing in size and also impact. So yeah, I think even I was looking at the, many of you are on this committee actually have served in the mentor role in the last, you know, last year, even I see Peter a room Bobby. If I'm saying your name correctly. So you know, you know just first hand experience, you know how this program has been run and so I really appreciate you volunteer your time to be to participate in the program. So really this rice showing this, the screen here this gives you kind of overview of the program. So I think really, you know I think we have a lot of people who are interested in entering into our community but finding it, perhaps hard. Not only just the space of the technology but I think there's just so many resources sometimes it's hard for them to find an entry point. So I think this program kind of creates that avenue for those people who are seeking in entry into the community, giving them sort of that hands on learning opportunity. And because we have a program so it creates that structure to connect the mentees with the mentors, and we also create structures to kind of help the mentors and mentees to do project planning. So in the program, there's the regular, you know, checking and evaluations to make sure you know things are progressing. And I think, you know, because of the structure and the existence of this program, you really provides that sort of guided consistent learning for these new contributors over a sustained period of time versus you know people come and casually, you know, learning or maybe getting a little bit mentoring here and there. But this really is, you know, these people are here, getting consistent guided that kind of learning experience over a really sustained period of time so I just want to emphasize that. And if you look at, you know, previous year's projects, they're really deliverable based right at the end of the mentorship project. The mentees are expected to do, you know, a BC these three things, you know, things might change, you know, over the course of the mentorship but it is very much deliverable based learning based and so, so yeah, it's been, I feel like I've been running this for the last few years and I've talked to a lot of mentors and mentees and staff and we are making some little changes over the years and for this year particularly. So we want to reserve some spots for, especially projects or labs or any other, you know, projects within the community who are looking for help with documentation. I think last year we even had one or two projects, you know, with the main delivery of being documentation but this year we want to really make it pretty explicit. So, right if you go to the mentorship projects and click on the 2023. On the left, the label. Yep. 2023 projects, you can see actually we already got two projects. And we have a new label called primary focus so these two obviously the their primary focus is coding, but if somebody is submitting a project with the primary focus of being documentation that label or show documentation so just make it, you know, put, you know, clear labeling and people will know what's the primary focus of the mentorship project so I encourage all of you. And also, if you talk to any project maintainers if they have any needs in, you know, obviously coding documentation or research, you know, encourage them to submit a project proposal. And the project proposed were accepting project proposal now through March the 15th. So there's still about a month. So there's ample time for people to think about what kind of gaps and needs they have in their projects, and hopefully you'll submit a project proposal and will connect you with those who are looking to enter into our community and work on those projects and help you out. Otherwise, I just want to emphasize yes I this is really a win-win right for all of us it's, it's a win for those who want to come to learn to contribute and become a productive contributor to the hyperledger community, and also win for all of our six or working groups who are looking to address gap in whether that's coding documentation or research and as a way to onboard new contributors. And I've this year we actually created a mentorship alumni group on LinkedIn I was just looking at it actually the last few days. Many of them actually are still, you know, working in the blockchain space, or they've found some, you know, software engineering jobs. I, you know, it's my hope that what they did here gave them that leg up in their professional or academic pursuits. So, you know, this just makes me feel really good at the end of the day seeing you know what what we did here really help them in that pursuit. And many of our mentees also have, you know, wrote about their experience in our blog post so I'll post the link here if you, you've probably seen some of those posts, but just so that chat is disabled. Okay. So I cannot post the link. But if you use discord. Oh, okay. Yeah, if you just go to hyperledger.org, you know, we just recently posted about 10 blog posts, and those are written by the mentees who graduated from a program last year they reflected about their experience what they learned and highlights and what they are planning to do next and many of them, you know, hope to continue to contribute. So I think that's, you know, that's kind of the outcome we're, you know, looking for. So as I mentioned, proposal is open from till March 15 and one last thing I do want to mention, I would like to. Once we close the proposals submission phase, we are looking for four to five members from this group to review all the proposals that we get to see just to evaluate to make sure you know the ones that we are getting, you know, mentees who are receiving a stipend, those proposals are relevant to our community to our projects adding values. So what's Tracy's, what's the process of getting, you know, for us and fortified people from this group to have to have them to have to review the proposal we get by mid March. Yeah, so I think last year what we did was we just asked for volunteers on this call. And I think we had four or five people step up on the call and say that they would like to be part of that group of reviewers. So, yeah, I guess if you all would like to volunteer. I guess raise your hand now. And, okay, Peter, Peter, that's one. Marcus, that's two. Okay. Sorry, quick question. Yeah, I did hand for two purposes. So when is the strict period is going to be. When is the Right, the review period. Yeah, so it'll be the two weeks after we could close the proposal so right if you can go to the haplogen mentorship program just the overview page. Yep. Scroll down. Yeah, the program dates. So right now the proposal is open, and then from March 16 to the 30th is the mentorship project proposal review by TLC. Works for me. Thank you. Thank you so much. So one question, do we have as a TLC already some evaluation criteria in order to better estimate if a project makes sense or not or maybe requires more information or details. So, yes, I have documented this on the week key. Right, if you could go to mentorship projects page. Just go to that overview page, the project. Yep. And then review the project proposal guidelines. This is just, you know, based on over the years, I've asked mentors and staff, this is what we came up. And, you know, we've made, you know, slight modifications over the years just to clarify certain points. But this is basically the guidelines and then when we review and select, that's kind of the process and criteria. I welcome any feedback if you have any. Okay, thanks. This is good. We have this already in place. I mean, it would require me to look over it and think about it, understand it. But yeah, that certainly helps. Great. So we have three volunteers. I will really like to have, I think four will be good just to have a bigger group. And then we'll do a more extensive arm twisting on discord. Okay. Well, I figure, I figure the more quiet we are maybe we'll get somebody to put their hand up. The reason I am not putting my hand up this is last year I had to serve as a tie breaker. So I assume that's going to be the case, particularly in this year. Oh, if you as a TLC member, if you do decide that this is something that you would like to participate in is willing and welcome to have your hand go up to volunteer to review the proposals. Absolutely. Yeah, so thank you. And if you have any questions, please let me know or you can email mentorship at hyperlegia.org. I'll answer from there. Any questions that anybody has for me. Peter, your hand is still up there. I assume that's still from the volunteer. Okay. Any questions that anybody has for me. Marcus. So I think last year I was wondering if some of our project also participate in different mentor mentorship programs like Google Summer of Code or whatever is out there. And if those mentorship programs are also encouraged or supported by by hyperlegia. Yeah, that's a good question. So this mentorship program that we run here, obviously separate from Google Summer of Code. But yeah, community members are definitely encouraged to also, you know, you leverage other mentoring programs out there such as Google Summer of Code. There's also outreach. Those are the two main ones that I know of. And there's the Google also runs a season of docs, kind of focusing on kind of documentation type of. I think it's sort of also considered mentoring. But by the end of that, you know, mentorship, the intern or the mentee are expected to produce documentation. Obviously, you know, Summer of Code or any other programs that they run outside of Linux Foundation, you know, they have their separate process, you just follow their process. Here obviously, you know, we are focused on hyper lecture, you know, any projects that are going to advance our community work and our projects and labs, you know, you're more likely to get, you know, approved and get that stipend funding to get a mentee to work on it. But if you do as Google Summer of Code, you know, Google obviously has a lot of funding and but you're competing with, you know, many other open source projects out there. Did I answer your question Marcus? I mean, yeah, I mean that pretty much makes sense for me. I mean, I also understand, or if I think about that, so I could imagine that the motivation by Google could could also say, look, hyper lecture, they have their own mentorship program. So why would we accept any hyper lecture project in the Google mentorship program? I don't know. Yeah, I do know CNCF, they run, you know, a lot of their projects, you know, they have their own very sizable mentorship program here run at the Linux Foundation, but also a lot of their projects also go to Google Summer of Code. So it's not like, you know, their projects get rejected just because CNCF already runs a sizable mentorship program within the Linux Foundation. But so do we know of any hyper lecture project which was participating in a different mentorship program other than the hyper lecture one? Not that I know of. I know several years ago maybe before we even started our formal mentorship program, I think maybe there was a try somebody tried to submit one to Google Summer of Code but it was rejected. And I think last year, David, correct me if I'm wrong, did somebody submit something to Google's Season of Docs? Exactly right. We did support a submission to Season of Docs. We weren't accepted. I think part, as we learned in the process, the, I don't think it was, we didn't have an exact reason why it was rejected. They don't really provide that. But from what we understood from talking to CNCF and others, I don't think the criteria that Google uses is if a community has a separate mentorship project, but what they do look is they try to have organizational diversity. So I think we were competing basically with other people from the LF. So there was a limited number of LF slots. And the Season of Docs went to other LF projects. So it seemed like that was the big limiting factor. That's why we looked to see what could we do on our end to support documentation more. So I'm really excited about explicitly adding documentation to this year's mentorship program. As men said, there has been documentation projects in the past such as the CACDAI workshop project last year, but I think making it more explicit and explicitly inviting people in to do a documentation project will be helpful. That having been said, if somebody wants to try to submit to Season of Docs again this year, we're happy to help you with that. If you want support submitting to that or a different program, let us know and we can help. But yeah, as men said, we've tried a couple times in the past, but haven't had a lot of success with other mentorship program. Thanks for the question, Marcus. Any other questions that we have for men before we move on? All right, I'll make one last call. Did anybody have a change of heart or decide that they wanted to volunteer as well? Okay, we'll have to do some outreach. Sounds good. Thank you all. Thanks, men, for presenting that to us. Hopefully we'll see a lot more project proposals coming in from folks. And also, if you know of somebody out in the community who you think would make a great mentor, please reach out to them as well and encourage them to submit a project proposal for the mentorship program. So, any other kind of discussion items that people would like to cover before I move on to the Task Force discussion? No. Okay. So I think then the Task Force discussion, Bobby, actually, I think you wanted to cover documentation today and not the onboarding content, but I picked the next one in the Task Force list. Do we need to cover the documentation one today or shall we cover the onboarding content? I think we can touch on both. I'm really prepared for the documentation, but both meetings are basically kicking up around the same time. So it's okay if we do them together. So I'm just going to screen real quick to talk about the documentation. Is everybody seeing a wiki page? We can. Hold on a second, that shouldn't be going to get rid of my zoom. There we go. So the documentation Task Force initially started a year and a half ago through the Learning Materials Working Group. We really didn't get into recommendations, but we did a lot of fact finding and surveying. So I incorporated that into what we're looking for now. So now the mission is to just establish some concrete documentation standards for the community. Like it's open source, so it's everybody has choices and a ton of ways that they prefer to do things and we're not trying to step on those. But as I show you when we went through the survey answers, a lot of people do want some guidance. They just want to know what their choices are or what is recommended to get started. So that's our goal is to provide the developers, users and stakeholders with high quality technical documentation that's accurate, accessible and easy to understand. So you've got to be able to find it. It has to be correct. And you have to be able to use it to your end goal. And it's easier when there are standards to develop on these platforms and utilize them better. So each project and each team comes with different maintainers and different ideas and we're really not trying to force any of these suggestions. We're just saying, you know, we have this tooling set you can use we have this project uses this and this is how they do it, you know, we need to come up with those types of suggestions. And then we're going to go ahead and look at some of the things that are available for the community to use. So I guess the tasks we need to complete would be to evaluate the current environment which we did gather the information for that. And, you know, look into what people are using what are the publishing platforms that are popular in our community. We're going to have a steering committee. We're going to start having regular meetings. Everyone is welcome to attend. And we're going to go over, you know, the results of what we found out and try to figure out what are the communities best practices for creating documentation. You know, they have to be, you know, what are the resources that hyper ledger is offering. What are the training materials that you need or technical documentation that you need for people. And can we use this and this is where the best practices task force which really isn't kicking off just yet, but where that will come into play at the end. What documentation do incubated projects need as opposed to, you know, active projects what you know it needs to kind of also slow with the life cycle of a project documentation to me is a living thing so you have to keep it moving and keep it going. What are the different needs for docket for technical documentation new projects they're looking for complete guidelines they like where do we start where we start, you know they need the templates they need, you know, to know what we offer for them to support them and existing projects they're updating you know do they want a re redo their look do they want a new look what again they might have questions. So, I think Tracy and I, or the group had discussed some of these deliverables will be creating a common style guide, recommending some publishing platforms that are available to the community, creating best practices for documentation like what tooling is available and what audiences do your technical documentation need to target and create those templates so it is, you know just as easy and user guides you know you just can't. And again who's never really created the documentation from GitHub there needs to be a primer for that you need to be able to go watch a video or something that says you know this is what hyper ledger offers these are how you select what you want this is how you you know add this file to your command line to get it going you know whatever you need to do to get that easy for people creating documentation so that's not a roadblock for them. In my estimate we should be done with this in three to four months. There have been people who have volunteered. Hopefully there'll be more names added to this list this is. I know it's going to go over in GitHub but right now it's just easier to throw all these thoughts on a wiki page for me. So that's what I did and I'll put the link in discord. For each of the task forces in the discord channel. We're talking David and the learning materials working group which is no more by the way. We say goodbye to learning materials working group we're revamping it again for more specific functions that it did rather than just as general. No one really knows what it does working group. So, with that, we're going to take over that time slot, unless. I think that folks who are in the task force decide that's not a convenient time. So right now, I believe David was going to change the calendar link to show on the 20th I believe the 20th that's President's Day the next following Monday to reflect the two task forces that will take over that hour half hour for each task force. There is a discord channel meetings. There is a discord channel for discussion on this task force and I put that link there. Some of the references for some of the material I'm going to go over really really quickly. Here was a survey we gave out to the maintainers 14 or maintainers and community developers and 14 people answered and I'll show you a little bit quickly results. I put a link to a page which I'm going to go to hopefully my computer will agree with me. Yes, that Tracy supplied that lets the community know some supporting resources that they have available if they in fact want to use them so I put a link to that because one of those is what the community suggests for the technical documentation. So that's that link. And then this was just a best practice guide from several years ago that was in a templated and the learning materials working group for people to review. So again the survey I just grabbed three or four points most people really want to redo or have the documentation reflect quick starts examples graphs, all of the above so it's definitely a need in the community. A lot of people think that a modern look. Simple easy to read is the way to go. I mean that's very clear. And most folks want a quick guide and example projects in their user guides, which I think is a great idea where you have links to other things if you need a deeper dive in any concepts. This one is very interesting. Very important for product adoption is visual aids graphs and charts so right now if you look at like the landscape page. That is very visual very graphic lots of charts lots of graphs but you look at the hub documentation. It's very you know it pulls right from the code so it's not really spiced up and apparently the audience or the community really would like some incorporation and guidelines on that I mean, you know it's hard to develop graphics and they're already developed in the community why not use them. So that was basically some of the things that came if you want to take the survey it that the surveys right here. So go ahead and then responses, if you want to see the other responses, they're right there. And then, moving along to discover what we are using now. So most of the project use read the docs few projects use non traditional documentation so this graph here doesn't fit on my screen, but it basically shows what each group is using at this particular time. And basically just for reference purposes to get an idea of what the community is using and when the task force starts meeting hopefully will incorporate what we can gain from that table into our best practices so then moving along we're also going to be working on, you know creating doc best practices for documentation and you know I just threw a few ideas before we meet next to discuss, you know, what does that look like what do we want. Is there different for maintainers and developers who's your target audience general guidelines for you know writing technical documentation, and then a badging system is this is a link to a style guide for publishing through a picture that was put out there by the marketing department that's available for everyone to reference. And then basic documentation, I know David in heart had talked about and rune had kicked around some of the criteria needed for graduated projects and I'm thinking of incorporating or hopefully the test courses thinking of incorporating some of the things we come up with possibly to this information and then then just some ideas. Again, I think standardized graphics. A glossary section and basic concepts like a common blockchain primer that instead of having these new projects labs come in and think that they have to write this enormous move for their specific project, maybe hyper ledger can supply a glossary and some basic, you know, blockchain concepts that they can just link to and not have to worry about anything but how to use their particular software. So that is basically for the documentation. The onboarding. I should ask for. Yeah. Well, I wanted to bring up something that I've done since we met on Monday, related to the documentation passports I did put a link in the discord channel but I'm happy to share it here as well. If you would like to see kind of what's happening there. You can open it as well. That's fine. So I, I took some time to use the. That's not the one that was in the answer to somebody else's question this morning. So it was my message before. Yeah, so. That's not the one either. Yeah, we're getting here we go. So if you want to click on the second one there. This one. Yeah. So I put together a documentation template repo that we might start and utilize, which is basically intending to bring together all of the different sorts of material that I think is useful. If you hit the hamburger, you should see a menu that kind of covers the different items that that are available to to start looking at and so the sorts of things. Obviously, Bobby, I didn't look at all the material you had there, which was really great material that you shared with us. And this is a basically a template repository that somebody could start with and then basically build out for their particular documentation to see information about how to get started with the project. Right now there's just placeholders for a lot of this stuff. The only place that I actually building information was in the contributing section, where I found some documentation that was kind of interesting for going through and trying how somebody might contribute or report a bug or request change. Obviously, all words that can be changed, but just something for people to react to and kind of see the different sorts of things that are probably useful to have in the documentation Bobby I think we should align this with with kind of what you guys have already done. So I'm going to share in the learning materials working group to see if there's anything that was missed that we should add to this or anything that should be changed. So, but I think, you know, by providing a template repo for people to just start allows them to understand the sorts of things that they should include in their documentation and work through and this uses the material for make docs which is something that is the recommendation for future documentation projects I think from hyper ledger. And so yeah, I think we could take a look at that and provide some thoughts be that full request even on the repo itself. More creation of issues that sort of thing so just wanted to share kind of what I've been working on since we met on Monday. That's awesome thanks for all that heavy lifting. So basically, I guess to continue. Am I on mute. You're not on mute but Marcus has a question. Go ahead. Yeah, Bobby thanks for showing those outcomes of the survey I mean this is super interesting. So, so when you showed this I was actually wondering if if there's a particular project, which basically covers all of the needs of, let's say the general users. So, I'm wondering if it would make sense basically to also I mean add to such a survey the question hey what of the hyper ledger projects. Are you happy with in terms of documentation so which projects can improve, not in the sense that we would like to raise the point with the finger of a project and in order to say hey you have to make it better. More as a to figure out what people actually would agree that this is already good documentation. And which can be then also be used as an example for the project. Yeah that's exactly what the task force is going to try to determine. So hopefully we'll see you on Monday Marcus. I'm going to put your name to the list. So that's basically we were trying to pinpoint that exact concept. All right. Thank you. So I'm going to try to navigate back to the. Take me a moment. And just after I body, your share has stopped. I don't know if that was in control. So let me share again. Any other comments on the documentation stuff before we move on to the onboarding. Bobby, all yours. Great so onboarding again I set up a wiki page really just to throw the information somewhere that people can edit and manage before we put it back in the in the GitHub as a recommendation. We talked about onboarding. The learning materials working group had kind of always thought that their meetings were accomplishing that but as participates patient went down and obviously needed to be more topic specific. So instead of a general meeting that talked about whatever anybody needed. We're going more with specific meetups or specific topic driven ideas. So onboarding is always been an issue of how to do it where to do it and how to conquer it so that's what the onboarding task force is going to try to define and come up with suggestions so there's different groups that need onboarding content that's geared differently and I think that that's where the group has decided to more start like to try to figure out what each one of these community members need and how we can and how we can deliver that again this is not filled out we're going to start doing that on Monday. We meet for the bottom half of the hour. So we're going to be doing the onboarding and the documentation kind of together on that time if we need more time we can always add it and this also has a discord channel I'll put that link in here. So we're trying to again try to make it easy for developers to find the technical documentation and get started like one of my questions on the survey was, you know, when you read your documentation can you take it and create your own project or you basically just following this and when you're done have no idea where to start your own project so that's something to look at to you know we want this to be usable docket technical documentation. And that's just one of the things that for onboarding, we have to consider also the onboarding here the content is for the onboarding. We have big chairs how do you run a meeting what do you need to do that kind of stuff we want that also easily and at people's fingertips. You know when you're a to see my new to see member discord. You have the wiki pages, you know where am I going what am I doing that kind of help. So we're hoping that these guides can onboard whether it's a button on the main hyper ledger page. Or how to get started or start here I know is one of our rooms and again they're on the task force to I just haven't filled out the information yet. We're going to take a whole lot of people whole lot of thinking whole lot of good energy and try to figure out how we can get more people who are interested to go past that first click of what is hyper ledger and actually get involved. And again, men is absolutely correct the mentorship program is one of the best methods for that. So hopefully we're going to be doing meetups that are geared to getting people into the mentorship program in the next few weeks, stuff like that so if you have any idea or want to help with onboarding task force to get people into the community working in the community not just looking at the community but actually involved in the community. Please come out to that Monday, 1230 Eastern Standard Time meeting, and we'll get started with that one as well. And then take questions on the onboarding in a second, but after these two are kind of done that's going to like migrate into the best practice badging task force that got approved also. But we want these in place first before we move on to that one so if there's any questions on the onboarding task force. I know people are afraid to ask is when you're on the task force. I'll recruit you right away. So hopefully everybody will come out that will make the calendar invited and announcement will be sent down and I'll put the information on the discord channel which is easy to find on the discord under to see. So thank you for letting me present these and I hope that these task force gets started with a lot of energy and a lot of people come out. So, thank you. All right, thanks Bobby for covering both of those today. Any questions or comments on kind of what's been done or what the intention of these task forces are. You know, everybody's hoping to have three minutes before the next meeting. So I'll give that to you. So thank you all for coming today. We will cover I guess the fourth task force next week in the TOC call and we'll see what else comes up on the agenda for us to include. We'll also been reaching out to some folks and seeing if we can twist some arms to get that forth or fifth volunteer for the leadership project proposal review. And with that, I will let you go. Have a great week everybody. Thanks Tracy.