 All right, welcome everyone to the August 4th hyper ledger technical steering committee meeting. As you are all aware, two things that we must divide by the first is the antitrust policy notice that is currently being displayed on the screen. At the top, and then the second is our code of conduct, which is linked in the agenda. As far as announcements go, we have the standard and announcement of the deaf weekly developer newsletter that goes out each Friday. If you have something that you want to go out to the hundreds of hyper ledger developers, please leave a comment on the wiki page that is linked in the agenda. Another announcement I'd like to make for the TSE members I did in the discord channel. I just want to put a note about the hyper ledger, not the hyper ledger. I guess the hyper ledger proposal for so long that has been written. It gets kind of a general feel for what people think on that proposal, as the maintainers would like to, you know, have a fairly decent chance of getting accepted without, you know, knowing that they're going to get rejected. I guess is the key here right. So just let me know in the chat, your general feel for that. I'm going to get back to Sean and we can hopefully have that discussion here coming up soon. Any other announcements that anybody would like to make. All right, single hand, nobody coming off mute. That means there's no other announcements. The hyper ledger saw to the report came in last week. A number of people have been able to review that since it came in. I did not see any comments coming in but does anybody have any comments and the hyper ledger saw to report that they would like to bring up here in the TSE call. Seeing no hands are we coming off mute. I will take that as you know, we have the areas in the report that is coming due today. I have seen messages go out on discord about that so I'm expecting back to those to come in here shortly. The arrow have one is due next Thursday. We will hopefully see that one coming in as well. As far as discussion items for today, the only thing that I had on the list was the task force that Bobby and Benjamin have been driving. But is there any other discussion items that we should have before we get to that task force discussion. Seeing also no hands, nobody coming off mute. I will take that as no, and I will hand this off to Bobby and Benjamin to walk us through kind of what they've been working on with the documentation task force. Hi everybody good morning. I am going to introduce Benjamin, who's going to give the presentation during one of the technical steering committee calls about four or five months ago. There was discussion about badging and documentation in the community and what it looks like and there was really never any research done on it. So the learning materials working group took that as a challenge. And we have prepared a presentation for you today and I'm going to turn it over to Benjamin who I feel is one of the brilliant rising stars in the hyper ledger community. So it's all yours Benjamin. Thank you Bobby no pressure. Right. Am I able to share my screen. You should be able to thank you sir. I will go ahead and do that and please let me know if it's all visible and so forth. That's great. Great. Great. All right. Hello everyone. So today I wanted to share as Bobby was saying the weeks and months we've been working on this task force. Some of the gaps and opportunities that we found within the documentation. And we wanted to emphasize that ours is a fact finding mission and our conclusions and recommendations wanted to spur discussion amongst the hyper ledger community. For the betterment of documentation towards greater adoption and ease of use and learn ability. So our eight guiding principles that standardization makes adoption faster. Each project could use a similar hosting platform. I currently they all do not any documentation platform should use a common Markdown theme a language that gives you a little bit of style, a theme and an interface and we'll see a bit more about later. We also have done a survey and one of the questions is regarding a design aesthetic. We noticed some of the pages have a simpler, more minimalist aesthetic, whereas some have more of a complex deeper dive encyclopedic aesthetic to them. So we found that a simpler design aesthetic may be more beneficial, but again, we'll get back into that later. And we also found that some some pages reflected a newer web three or blockchain open source aesthetic, and that could be something for the future. We also recognize that there is an implicit uniqueness between each hyper ledger project. And we wanted to resolve that with the fact that most companies organizations have a standard theme for their product pages. So one to the next looks quite similar. We believe that the standards should be reflected in a consistent manner using a badging or check mark system. And that that system and our guidelines should allow for community involvement to avoid a top town approach, but instead reflects a collaborative open source nature. So our specific recommendations we found that most hyper ledger products indeed used read the docs for the documentation hosting. And so our first guideline or recommendation is informed by that that those who don't use the docs could benefit greatly by moving to that platform. That even amongst those who use read the docs that standardization could exist between content and context that inconsistencies and style graphics and other content could be minimized in order to maximize standardization. And that current and future projects could utilize a standard template or theme using an agreed upon documentation pattern. So what exactly is that pattern. We found that most projects use read the docs read the docs is populated by files on GitHub, which is also the source of truth for all code. And then a hyper ledger wiki page, which would host the badging. We found that there were some differences in graphics and glossary sections and could be improved in terms of better look up and user experience. And we noticed that some projects do use the discord, but the documentation by itself as a standalone read the docs was not necessarily reflective of the community. If the community existing for technical and non technical questions on discord. Those read the docs pages could be used through pinning on on discord. And finally, our last recommendation is that we utilize a survey to reflect the voice of the hyper ledger community, the various unique projects that within them have disparate themes styles and layouts to find some harmonization between them. So our task force has got four main sections to it. The first two are completed determining the status of all the projects tools and libraries. And that was done in a grid analysis and we'll get into that in a minute. And then we also used an examination of the current processes so that documentation pattern I talked about read the docs GitHub and the wiki pages. And these two are the ones that we're going to go over today quickly. The community itself wanted some involvement in terms of the survey and best practices to be agreed upon. And so this is a matter of having community involvement and a voice being heard. And then that would necessarily inform the integration of those best practices into badging system. Our work deliverables and work products included that analysis so a grid analysis, showing what platforms are currently in use. So the key takeaways for that we can, we can get into this is quite a big grid a lot of detail here I'm not going to, in the interest of time go through it all but I will say the documentation is mostly read the docs. So if we scroll down the screen here, we've got mostly read the docs with a few stragglers on Google docs, some on just the docs in a couple on docs.rs. But for the sake of simplicity, most of them are on read the docs and that is our general guideline for documentation hosting platforms. The survey itself, I will perhaps drop that in the chat if I can and we'd love to have some feedback on documentation standards. I just dropped the survey in the discord channel. Obviously, thank you Bobby. Our report itself, you know, it's existing on our hyperledger page. Please, you know, take a look at it and we'd love any suggestions or updates to it. Our recommendations, like we said, we wanted to that to exist in two parts. So our guidelines and recommendations, as well as the community voice through discussion on discord and the survey results. Finally, that would end up in a badging process utilizing that template and our perspective was that that could be integrated into an already existing hyperledger badging system. Why reinvent the wheel when it's already there documentation could be a part of that. So from incubation to graduation, we could include documentation in that system. We saw that read the docs was mostly used. Those products who do use read the docs are using Sphinx, restructuring text, RST files, or markdown or theme enhancer like MK docs with insider features. Those projects who are using non traditional, we do recommend that we standardize harmonize it those documentation projects. Since most 99 90% of those projects are already using read the docs. We talked about a documentation pattern. So essentially the trio is read the docs GitHub and the wiki page wiki page is where that badging system would live and be integrated into GitHub is a source of code code truth but also more importantly for our purposes, where the files live for read the docs. And we'll have an example of that. Now we noticed on the grid that most of these projects are using read the docs. But when I wanted to highlight for you today in two case studies is that even projects that are using read the docs, there are still some differences and start differences at that. So with this example, I'd like to just call into to mind a hyper new fabric versus basu on the right hand side we have basu which is adopting a more minimalist approach. Our task force enjoy the fact that it gave only about four options. And that if you go into basu there is a technical deep dive you can get quite deep into all of these. So you have that encyclopedia wealth of knowledge, but it does not overwhelm the user right away fabric on the other hand is probably the gold standard for a lot of documentation. However, it does use a different look and feel it's got a logo in a different place social media links as well as a more encyclopedic knowledge. And this is probably one of the starting points we've got quite a bit of information here. But we did find in our survey that the survey respondents hope we hope to get more of those enjoyed a more minimalist style. We do get into more detail there. Looking at both content and context so even pages that are similar in their layout and style. We did notice disparate elements in terms of content and we felt that that content was reflective of different context. And by that I mean, and let's take a look to to exemplify that fabric versus sawtooth fabric was necessarily a classic, not a newcomer but the gold standard in terms of documentation. It brings you into a deep dive not only into the product itself, but it's a blockchain into Ethereum, it's a Bitcoin, and to DLT, AML and KYC regulatory frameworks. So you get more of a holistic introduction as to the blockchain and Web3 community. So let's compare that with what sawtooth does for its introduction, which is getting right into the product itself. How do I spin up an instance? How do I get a node working very fast? And it jumps into sawtooth as modularity and how I can design my application. So even between the two of them, we see stark differences in terms of the context reflective of the context. Our task force also wanted to look at what is the rest of the blockchain community doing and can we compare that. And we felt as though some of the blockchain communities, one of our members recommended Cosmos. We felt that it had definitely a different look and feel. There were some similarities and these green lines are indicating some similarities between hyperliger fabric on the right hand side and Cosmos on the left hand side. And so there is a lot of similarity between the two of them. We did notice that Cosmos have these cards or buttons which reflected the idea that someone going to the page could have a very quick decision making process as to whether they wanted this first one, which indicates a deep dive into more technical tutorials. And on the second one, getting into SDK into a spinning up an instance on the right hand side. So we thought we'd try and jump into a read the docs and we did a little POC just to kind of get an idea of how exactly RST works with README. And can we use some of these more Web3 or newer aesthetic decisions? So on the right hand side, you have a develop our quick start button. On the left hand side, you have an introduction to hyperliger project key terms and concepts. And each of these are just links that essentially I was commenting to Rai just a moment ago about how some of the documentation pages are necessarily more 1.0 features. And some of these MK insider features could bring us into more of a Web2 2.0 framework. So read the docs itself is where most projects live. We would like it to be where all projects live. The discussion then becomes around themes and Sphinx is the platform where we where these read the docs themes are generated from restructured syntax is where you see a lot of this are the Markdown language used to say create buttons and so forth. And our POC kind of was informed by that and hopefully we'll work a little more on that with the MK docs insider features. Here's just a glimpse of what can happen with Sphinx or Sphinx themes. We noticed that there is disparate theme being used for each of the hyperliger project pages. You know, maybe picking a theme or picking a style of theme could allow for more consistency between them. And this is just going into our proof of concept. We do have the ability to use custom CSS and custom JavaScript. And Rye was obtaining me about the MK insider features which are also very nice to be able to push forward the functionality of of any hyperliger project documentation page. Thanks to Rye for that. I'll just kind of finish off and talk about some of the best practices and our questionnaire. We did have a great quote from a hyperliger community member and I'll just share that with you today. She says she understands that the hyperliger project is separate from our company and that it may require complete isolation of content. The style, the Marktown guidelines may need to diverge from their company's corporate documentation standards in the future. And their team is happy to continue discussion here at the next community call. What I wanted to emphasize with that is that there is kind of a disparate set of maintainers, project developers that we wanted to hear their voices from. So that leads us into our documentation survey. Given that uniqueness for each page, we wanted to have a questionnaire survey that gives us those types of results. So in order to share these types of documentation standards, we've got some responses. We would love to have more. So please jump onto the discord page. In terms of the survey responses thus far. We've gotten some who are more interested in a minimalistic style. I'm not sure why this is not jumping up. Let me just run you through some of the responses that we've got. Most of them said they did not mind a standard page. And most of them said that they were more interested in the functionality of being able to spin up an instance of their hyperledger project as opposed to having sort of fancy graphics and aesthetics. That being said, there was a push towards graphs charts and being able to include functionality in the documentation pages. So and if you'd like to take a look at that, you can definitely go into those results shelf. The questionnaire URL is also part of the page that we have. So please, if you feel that you'd like to have a voice in this, we've got just a few questions there. And a few minutes of your time would help us to determine our next steps going forward. And then our recommendations finally and in terms of a badging system. That's all for me. Thank you so much everyone and thank you to Bobby for allowing me to share our results. Thank you Benjamin that was a great job and now I'm going to turn it over for questions and back to Tracy then. Hey, thanks Tracy. Thanks Ben. That was, it was really good insights into what has happened and what is available across different projects and thanks for that detailed analysis and all the information that you have collected and recommendations that have been made over there. Quick questions in terms of some of the projects which you mentioned, which are not currently using Markdown or RST format. How do we, so in terms of efforts involved for those maintainers and if let's say a recommendation goes in and saying that hey all the projects are to be moved. What's the kind of effort involved from them for them for those projects. Sure. Yeah, to be honest with you, I can't speak to the actual effort because each project would have a different amount of documentation. However, however, let me say this, I did find, and maybe Bobby found this as well, that those projects that were not using read the docs or RST Markdown files and so forth. Also had a more minimal amount of documentation. So while I can't speak to the actual terms of of effort that it would take in terms of porting that documentation information from one platform to the next. I will say that those projects that we're using to say the RST files, excuse me the docs.rs for example so I think Transact and Ursa maybe also Firefly some of the documentation there was a bit limited to begin with. So I don't think that it would take too much effort to port that over to to read the docs. However, this will be project to project so some projects will have more documentation. We also noticed that some projects were in the more infancy or incubation stages of their project, and therefore their documentation may not be fully fledged or fully formed at this time. So again that may not speak to the actual amount of effort that it goes to port from one system to the other. However, it would be helpful to have a guideline of recommendation on that sooner such that the porting process takes less time if there's less to port over from one system to the next. I hope that answers your question. Sure thanks and since since this working group is also I mean since the task force has also been closely associated with the learning material development working group. And you may be connected to the community who are more interested in helping out on these aspects so in terms of gauging those interest. So is there a possibility of getting involved with these projects where they need some push or help in case if that's required. So, like, how can the working group or the task force get involved and get those community resources needed for those for them to get that help, because sometimes majority of the time the projects may say that they may not have enough resource or time. So even a little bit of help could take it a long way. Yeah, I mean, I can't speak for anyone else in the task force. I am more than willing and able to to participate and put forth some time in terms of that. Porting process. One of the things that we did with Bobby and our team was to get comfortable in terms of how does the read the doc system work. How does it populate from a GitHub page with a read me and RST files into the actual read the docs platform itself. So we did familiarize ourselves with that process, specifically in order to be of assistance if need be in terms of that porting process from a previous or other hosting platform into read the docs. Yeah, and it wasn't our intent to create more work for any of the groups. It was more for the vacancy of information when people are trying to create documentation there's no real starting point or templated way to go about it in the community and trying to fill that need so I don't think again these are only going to be recommendations I don't think at any point where there's going to be a criteria for existing projects to jump backwards into documentation, but we're hoping that it's a forward moving process. I completely agree. So probably this is not a question it's rather. I don't know compliment or things that I like through the presentation so far. So there were many aspects that I liked and then this presentation and one of the important thing that I could make much sense of was. I think when you compared couple of the non hyperledger projects with the documentation that we have within hyperledger, you called out and some of those projects they were calling out that the text part of it the documentation which talks about all the text the paragraphs and which requires somebody to spend a lot of a lot of time. And then they're within that they had created a category called hey here is a quick reference guide for developers, you don't have to read through and search through all these places. Here is a quick reference if you're planning to use CLI for instance for administration purpose. Here is a quick reference guide for you to use SDKs to get started with the development. I think those are some of the aspects that I really liked that probably we could recommend every project that is incubating to adopt. I know some of the project that we have already does make some distinction in their documentation in those aspects but having that distinction, the visual distinction that we will showcase that clearly makes sense probably that's definitely that we should recommend. And overall it was a good presentation. Thank you. Thank you so much. Anybody else have any thoughts or comments. I love the kind of encyclopedic dive that that fabric goes into so for someone who is. It's the very first hyperledger project or there's it's the very first, you know, they're spinning up an instance to be able to get that kind of overview. It's it's amazing, but then for a developer who may have already used 1 hyperledger project now wants to integrate or incorporate that into their their tech stack or their corporate ecosystem. Having that kind of a lengthy introduction may it may benefit for that not to be at all removed. I love it. I would not remove it. However, like, as a room is saying it's might behoove us to to move those into a separate section, such that if you're a person who wants to learn about that, you have that option. But you're not inundated with quite a bit of information all all once so. Thanks, Tracy. Sorry, I just wanted to reflect what a room was saying. Yeah, no worries. So, I guess, you know, I'll add my comments here. I'm not seeing any other hands. So, I, I think I had an initial reaction as well, very similar to a rooms where you're asking people to do a lot of work to make things consistent across the projects. Right. And I think that's going to be a. A hard thing to get started. Right. A lot of the projects have worked a long time on their documentation and had documentation working groups and things that took, you know, months if not years to get to the point where they're at. So, you know, obviously recognizing all of the hard work that people have put into their documentation already is, is extremely important. I do see that there would be beneficial benefit to having some sort of templates that new projects could use right to start their documentation. That allows for some sort of consistency as well as in addition to those templates right guidelines for what sort of things people should think about including right so. For example, right the four kind of top level bullet items that they do have right maybe those are the four sorts of things that are the most important to make sure that you think through as you start writing the documentation. You know, and if there's some sort of theme that we can use at the mk docs right that makes sense across hyper ledger I think that's interesting. Benjamin Thomas I'm going to just call out you know is there any sort of pieces that we would want to think about with the documentation for these projects when it comes to kind of the overall branding I guess is the right word right around hyper ledger that that maybe could be added as far as input to the work that this task force is working on. So I come off mute but I cannot hear you. Hi sorry can hear me now. Yes, we can. Hi sorry thanks Tracy. Yes we have discussed how to make sure the branding is brand guidelines are applied throughout all the projects and we also discussed that along the lines of the domains that they reside on as well. Ultimately, as long as they are all residing within the brand guidelines there isn't a major issue. We obviously want to make sure that each project brand is is is utilized throughout all their communications and so on and so forth but I'm. Yeah I don't think there's necessarily anything too much to worry about for me in terms of the larger projects yes. And I think it's probably more of a case by case basis. But if there's anything that I can help clarify in the brand guidelines let me know. Yeah, thanks Benjamin I do think you know there's obviously some good information out there around the brand guidelines and we should make sure that as we come up with these recommendations they include those pointers or references to the brand guidelines so that people are aware of them and maybe they're built into these themes that we provide as defaults. You know, just, I think those are the sorts of things that might be worth considering as you continue to move forward with the work that you're doing. Sure, I'm happy to also, you know, kind of simplify them and add them to the wiki. I've been talking to Ry as well about adding reporting as well so maybe that's something we can look into. And again thank you, I thank everybody for giving us the time to do this and Benjamin you did a great job. Our next meeting is Monday at noon. It's on the wiki page and we usually spend a good portion of the the hour talking about this task force so if anybody has any questions or wants to get into more discussion please join us then. Yeah, I just wanted to follow up a little bit on what you said I really feel strongly that you're on the right track there when you said, Okay, it's going to be hard to ask projects to just start a whole revision process just to align all the documentations with one another at the same time. I do believe that a lot of the variations we have merely due to a lack of template to start with right so everybody is trying to reinvent the same thing. And of course you're going to do things differently. And so I do think there is, there would be value in adding some kind of a template and sort of guidelines. Anyway, I do want to highlight also that I thought the information that you guys brought forward is very interesting. And so I can see how we would benefit from using some of these input as we move forward and update the documentation. And, you know, get inspired by some of this input to improve on the documentation as we move forward and it's, it's going to be much more gradual than just say, Oh, this is where you need to focus on because I don't think any project can can afford that at this point but so I do encourage you to follow up and have this kind of documentation available, socialize it across the project so that projects kind of have this like you know y'all stick to look at and say, Okay, as we as we revise a doc, let's keep an eye on this as a goal to align with and I think that you know over time, we could have a more consistency across the projects for the better. Yeah, just to resonate with that or respond to that there is. So, I was chatting with with right about this there is a Sphinx theme that's available for each and every project that's hosted on read the docs and I'd say, you know, 85% of hydrology projects are already on read the docs. Perhaps a less time consuming or taxing process to change and harmonize the theme for every single project, then it would be to say ask existing maintainers to refactor or restructure their entire pages. So just as a as a more gentler low cost low work solution. It may be to take those read the docs themes, select a common theme and then implement them, as opposed to asking for much work in terms of restructuring so. Yeah, I can just speak on the fabric side we're actually not very happy with our theme so we'd be happy to switch over to a better and more consistent theme so that's that's encouraged for sure. And maybe another piece to add. I'm wondering if it makes sense at some point to have a repo right that is based on whatever the sort of theme and standard are that we're trying to create as a sample, right that people who are starting projects and need to write documentation can start from right pull this set of code. You know, in order to create your documentation for project X. Right. I just think that having something that is already there right open for anybody to use going forward is a good idea. All right, any other comments. All right, looks like no more comments no more hands being raised. Benjamin, Bobby, thank you so much for the work that you put together for presenting this to us. It's been enlightening I think for all of the TSE members and I hopefully we've given you some information and feedback that will help continue to drive the work that you're doing forward. Thank you for your time and please complete the quick survey. Thank you so much, Tracy. Thank you everyone. Yeah, with that, I, you know, I'll make one last call to see if anybody has any other topics they want to discuss. Tracy, I was actually wondering if there is any update about the TSE revamping I forget the official title of that. We voted to, you know, on the proposal and it was going to be sent to the governing board. And I don't know where things stand. I don't think we have heard back from the board at this point. I appreciate an update because the timing of the election is coming up and, in theory, I believe we start in August to start ramping up, but so I don't know. Maybe as an answer. Thanks. Yeah, heart does have an answer so heart will hand it over to you. Yeah, that's a great question. So the answer is that when LF legal decided and take a deeper look at our charter. They thought it needed some substantial updating. It is one of the older charters and they write new charters in very different ways. So Scott Nicholas is rewriting the is making some not substantive but well, I should say Scott is updating the charter in ways that won't change how hyper ledger functions but will sort of more accurately, you know, reflect the legal ease that we need to say, if that makes sense. So that's what's going on right now. And that's why we are somewhat delayed. Hopefully that will be done soon now. Right. Yeah, I was just gonna say I think the, I think the expectation if I'm not mistaken and people can help me if I'm wrong here but is since we have kind of general approval although not official approval from the TSC and the governing board that the decision would actually be delayed until the timing that has been written into the charter, which I believe is that we do nominations in November, voting in November from the maintainers and then voting in December from the governing board which would start a new term in January heart is there any change to that timeline or the expectation for when the next vote would occur. No, so we will have to. We were told that that was probably something that we should include a supplementary document rather than the charter itself. Yes, yes, they're there. We haven't. We're not expecting any substantial changes and how things work or have the actual practices just the changes in the document itself. Just reflecting sort of more modern legal ease I guess. I think I think the question and the concern is that typically we would be having a vote for the next TSC. Probably starting about now right where we would be gathering nominations and doing all the work necessary to figure out who's going to vote and all of those sorts of thing. And so I think the question is, you know, is that happening on the same schedule is it changing to reflect the fact that we want to start the new technical oversight committee term in the new year beginning January. I'll talk to Scott and I will figure out what our timeline is for this. I'm hoping it's quite soon. I mean I cannot speak for everybody on TSC but I'm totally fine, you know, agreeing that we delay until all of this has been settled. But as things stand, we don't have such a decision on record and it puts us in a bit of a limbo but I mean I don't think anybody is going to take issue with it if there's you know agreement this is what's happening and we are cool with it. I just think it helps to to state that clearly this is what's happening. Good point. You know, I think that's the, that's the working assumption at this point. If there is a concern, definitely let's have that conversation. So that we know what we're, what we're up against and we can see if we can get some movement and speed happening on this. Other topics. Thank you for bringing that one to the forefront or any other topics that we should discuss currently. No. Okay, so I am going to then close the meeting. Thank you all for joining. I'm going to close the meeting. I don't know if this task force is up next for next week, but I will find out where we're at in the schedule and make sure that we're including that. Also, as I mentioned, if you guys could take a look at the proposal for so long and see just your general thoughts on what you think that would be great. We'll talk again next week.