 All right. Welcome everybody to the August 24th Hyperledger Technical Oversight Committee call. As you may be aware, if you've joined a Hyperledger call before, there's two things that you have to abide by. The first is the antitrust policy that is currently being displayed on the screen, so we need to understand that there are a number of different organizations and folks here on the call. So we need to make sure that we're not participating in any activities that are prohibited under any of the antitrust and competition laws across the world. And then the second thing that we have to abide by is our code of conduct, which is linked in the agenda, basically be respectful of the other people on the call. So as we look at the announcements for today, we have the standard definitely developer newsletter that goes out each Friday. If you would like to include anything in that newsletter, please do leave a comment on the link that is in the agenda, and that will be included in a future definitely developer newsletter. Any other announcements that anybody would like to make today? I'll take that as a no. So we have gotten in the Hyperledger Bevel quarterly report. I've seen that most people have had a chance to look at that yet, but there are still a few folks who haven't. So we'll obviously wait for two weeks or until everybody has a chance to review that whichever comes first. I didn't see any specific questions on that report as of the moment, but does anybody have any questions on the Bevel report? Okay, no. So then we do have upcoming reports for today. We have the Solange report that's due. We also have the transact report that's due. Arun, did you have an opportunity to reach out to the transact folks to see if they would like to remain in dormant or moved to end of life? Yes, Tracy, I reached out to maintainers on private discord chart haven't heard back it from them. This week I'll reach out to them on a public channel. Okay, sounds great. Thank you Arun. And we'll see if that does show up if they're looking to report on that. The other one that's coming due next week is Cello. So if anybody is working on that project just a reminder that Cello is due next Thursday. Any questions on the quarterly reports? No, okay. So for discussion items today, we do have a few discussion items. If you would take me to the discussion. I'll know which one I'm supposed to do first. Okay. So the update on the security policy I did see Steven that you provided a example of what you think the security policy template should look like Dave you responded to that saying it took care of your particular concerns about the GitHub reporting. Other updates or comments or questions about what we've seen come in over the last couple days. What do we think about these suggestions. Dave seemed to like it but other thoughts on the separating these out into a template and policy. For me personally, the changes make sense. I, I, it has my vote. So I think from my perspective, we could go ahead with it. Okay. Thanks Peter art. Hi Tracy. So I guess my question is how exactly are people. So I looked at it Stevens document. It wasn't entirely clear to me how this is being separated out. You know, I thought what Steven did for Aries looked really nice. I just want to make sure that the people still realize they have options and they understand they have options. Does that make sense. Yeah, so if I could answer that. The plan would be to alter the proposed security doc that's been put in I think is, I think this is what's been proposed is that right. Yeah, this has been what's proposed and basically that this document outline for targeting be the audience be the maintainers and the document say here are where you have options. The template is what you should use by default but if you want to have options here's what your options are. The TOC document will be primarily a document targeting maintainers that contains the set of options. The template itself is simply here are the options hyper ledger would like you to use. End of story. Okay, so what are the main differences between the first document and what we have currently had the current currently what you propose what's proposed is the entire document in the TOC with all of its you could do this or you could do this is is proposed as the template. And what I'm suggesting is the template should be what we want everyone to use and the guidance be Oh but you know if you really don't want to use all of our options here's what options you do have. Okay, so correct me if I'm wrong. But if I understand correctly, you're saying we keep something similar to what was originally proposed as the guidance document and we have a simplified template is that correct. Yes. Okay, yeah. Yeah, that that makes sense to me. Sorry for not quite understanding it wasn't quite clear to me from the GitHub conversation. Okay, sorry about that. No worries. Yeah, that makes sense if you want an even simpler template, I think, yeah, it's totally fine as long as people know they have options. So if you want to, you know, propose like having a guidance document and template, I think that's, that's perfectly okay. So do you want me to so what I would suggest next steps if you know I don't want to cut up the conversation but if people are good with this, I'll take another I'll put a different PR in that is a new governing documents security file that has that bent to it. I mean sure that makes perfect sense to me if you if you can make the PR into two documents then it can be either two documents or one document where the bottom part is the template itself. People said they preferred that or not. I'm okay either way. I thought Dave preferred the separate one but I could be misinterpreting. I don't have a strong preference either, to be honest, as long as it's very clear that you copy paste the template part to make your project security MD. Okay, yeah either way. Yeah. Awesome. Thank you, Steven. I liked your areas template a lot by the way. Good stuff. Thanks. All right. Any other comments on the security. I think we have a platform for this. Okay, no other comments. So the next topic on our agenda is the UX research for the blockchain explorer lab. So I think we have as a guest here to Pika, to walk us through what it is that this topic is all about. So welcome. Hi, I'm Deepika. I'm currently working on the user explorer project. So what let me share my screen. I hope you can see your screen right. Yes, we can see hyperledger box chain explorer redesign. Okay, so this is the project I'm working on. So currently I am, I am beyond the user research part. So what I have completed so far as the user research. I had done a computer research, like we shared a Google phone from hyperledger's LinkedIn account, and also in the Discord channels, then that a qualitative feedback from one of our blockchain contributors group call. So, obtaining both of those I created some goals and pain points which the explorer currently have. Along with that I had done some one of the competitive analysis where I did competitive analysis on six of the competitors of blockchain, blockchain explorer. Where I got a bunch of information first I collected the general information we had, then how was the experience for that websites or then the interaction how what are the features are mainly available how is it accessible for the user and how the user for works and navigation mainly on the UX part, then what's the brand identity. So that's what I did and the commutative analysis part and currency. Yeah, with the result from the user research I said like goals and pain points I created goals and pain points. From that I have created some user personas so user personas are some like profiles which need a moment please. These are some profiles I created like as an example from our users. So, we had a couple of pain points and goals I sent for each. So, everyone has different roles like we had inputs from blockchain developers and also from the users we have also the users. So, from the input of user persona I created empathy map so here I follow the process of this one this template. So here what the empathy map of this person Amy, for example, what does she says when I bought the explorer, and what does she thinks about explorer and what she needs to done with Explorer and how she feels by doing that. So this is what the empathy map does and then with the user journey map. So with the user journey map what the user journey map does is it gives us a like a wrap about how the user uses our explorer like how they start using it and what are the processes they does. So when our user explores the network data it accesses the dashboard and gets their data. So, at that moment what will be the feeling objective and how we can improve the opportunities this is what I have done so we can improve them by streamlining the data directly well for faster insight and enhancing building capabilities. Then for other action we can like we had an input like customers visualization so for that what the user needs to do is to navigate to setting select visualization and if he needs he can set the color schemes, etc. So there also we have specified the emotion and also how we can improve it. And similar to that monitoring the system resources we need to monitor the CPU system CPU CPU performances and enhances visualization and with that we need to give it alerts look configure alerts simultaneously and for the user needs to define according to them and specify the recipients can specify. And these are the things I have done so far. So what I look forward is we will be having a card sorting activity by like next week or something. So I would like to get some input from the to see through for our activity actually and more more looking forward. I would like to have the battle team to collaborate on using Explorer for deployments and then the fabric team to give your inputs for the possible features we can do for especially for the user management etc. Then from the firefly team as we have connected, I request them to work with us to provide more input on blockchain and app level info for the users, then I request Iroha team to participate in user research base also. That's it Tracy. All right. And do you have the context to each of these different groups have you reached out to them already or you know, do you need help with finding out who the right people are to reach out to. We have got a country to start with the firefly team actually don't need to reach out with other members also. Okay. Questions comments from the to see and what you've just seen. That was a lot of a lot of stuff that you went through in a very short period of time I think there was a lot of great information in there, but other other thoughts from the to see Peter. I wanted to ask if this process, this analysis that you just did, does this have a specific name by which I could find more information on how to do this and the steps it takes. Sorry, Peter. I didn't get you. Can you go through that once more? Yes, no problem. I was just going to ask if this process has a name by which I could find more information about how to do it. About card sorting or. The overall UX research process that this slide information. Okay, okay. Let me show you that one. Thank you. Oh, the chat. Discord for chat. Okay. So, I'll send it on the to see channel actually. So, I have created a page on conference where I post what are the processes I follow and the documents I've created it. I think you can refer to that. Okay, thank you. Yeah, you jumped right into the details pretty quick. So I missed some of the, maybe context information at the beginning. So can you clarify what are the objectives and the expected outcomes of this effort? Are you looking to make improvements to the explorer? Is that the idea? Oh, yes, we are looking to make improvements to the explorer. That's why we started from the scratch from the user research we gained a bunch of. Informations. Like, they had a couple of requirements more from the existing ones. We needed to enhance a bunch of features. Okay. And do you also have some developers that will make these changes? Or are you just going to propose the updates and see what the community can do for development? I don't, can you clarify that yet? Are you actually intending to implement the suggestions as well? Or are you going to just release the suggestions and ask the community for help with the development? Okay. No, I didn't mean to interrupt. Thanks. So the objective of the mentorship program is to come up with the feature set for UX design that can be worked upon. And Deepika is a mentee who is running through this project. And in terms of development, there is a developer group, a community who is currently taking up a mentorship role of the explorer project. And they will be implementing these outcomes that Deepika will propose. And I see on the call, we have a few people from the explorer group as well. For instance, Wama, Manoj, Ravi. They're all part of the maintenance group on the current maintenance group. Okay. Thank you. That answers my question. Thanks. Thanks. Other questions, comments? Well, thank you for the quick rundown on what you've been doing. I think it's, it looks like it's great work that you've been working on. I do have one question. How long has the mentorship program been going on so far? It seems like you've accomplished quite a bit and you don't think the mentorship program has been running for that long, has it? We are halfway through. We have halfway through. Okay. Okay, great. Well, great work. I appreciate the effort that you're putting in here. It looks like it'll be very beneficial for hyperledger explorer. I hope also that it has shown other members of the TOC and whoever else might be listening to this call in the future. There's some interesting sorts of mentorship projects that can occur and happen with the UX UI sort of experience. So looking forward to seeing if other folks jump onto this in the future with future mentorship projects. Okay, so then the last item for discussion today is to talk about the best practices for automated pipeline task force. So I think Peter, this is up to you now. Yes. Could I share my screen? Yep. So one of my tasks was to evaluate the tool that we have for linting actions. And I submitted a pull request with it yesterday to cacti and it produced a long list of warnings or errors with the YAML files that we have for cacti. I'm not sure if the font size is good enough or big enough, but it comes in the structure of this. It goes through all the YAML files and then lends it for you. And personally, I like it a lot because it checks for problems with the shell commands within the YAML, which is one of the biggest issues that I usually have is the syntax that I have to figure out how the shell expansion works inside the shell quotes inside the YAML, inside the new lines, etc. So the short quick part is that this tool seems to work great. It's a complete drop-in sort of tool basically with zero configuration. I can show you the def if I can find. Yes. So the whole thing looks like this. Maybe I'll show it like this. Yes. So the entire thing just downloads the tool. I had to slightly modify their default recommendation on the way we install it because they specified the main branch here, but I always want to pin everything down to a certain version so that we have no issues with automatic upgrades, breaking things or deploying malware. So yes, it just downloads it and then it runs it and then it produces the warnings and it already has baked in the functionality that it sets the GitHub action to failed if there were unaddressed linter issues. So this is one thing. But what I'm actually more excited about the second part of my update, which is that I discovered that as I was making this file, this YAML file structured in a way that it gets to be used from our central YAML file, the CI YAML file. So as I was doing this little refactor, I realized that there's a syntax where you can specify other YAML files from different repositories. So here where you see that I just put a local file system path. Actually it would allow me to type out here hyperledger slash TOC slash automated pipeline best practices slash and then workflows. And what this immediately meant to me is that as part of the task force for automated pipeline best practices, we don't have to just produce the document with a checklist and generic guidance. We can actually write workflows and we can collect them in some central TOC related repository on GitHub. And then we can tell people within the best practices document that for example, if you want linting for your workflows, then you don't have to write your own. You can just go reference the one that we've already written for you. And that way it's an even lower barrier to entry. And I'm not yet sure how many of these we could have, but there's definitely a few of them. For example, in the security scanning area that I would very much like to collect into this repository because security is that. You see it as a feature that actually could treat that day. Of course, the most important thing. What I want to extend out having some sort of repository or creating another one with some specific name for the purpose and then collecting there these yellow files that the task force has wetted and wrote so that either everyone or at least the majority of the projects can reuse. And for that specific thing, my question is, what do people think? Where should this go from the overhead, from the repository maintenance perspective? I imagine that the easiest would be to just use one of the existing repositories, but I'm not sure which one. So does anyone have any thoughts on that? We could. Repos are free. We could create a CI repo to hold it. I don't feel either way. So for instance, if we put it in the TOC repo, that would mean that any change would trigger the entire TOC getting alert. No, that's right. So I mean, I'm neither here nor there, but repos are free. Okay. If it's no biggie from RISE perspective, then I would agree that maybe the separate repo is better because then we can easily make it so that the reviewers for these YAML files will be the people who are on the security task force and not everyone on the TOC. Marcus? Yeah, so I would also struggle to put this as part of the TOC repo because I mean, essentially what we were I mean, we're making a suggestion here for recommendation. Hey, look, this is a good example of what you could immediately use, right? But then on the other hand, we're also I mean, kind of responsible for maintaining this immediately. And maybe there are other people in the community who actually would like to do to maintain this. I mean, of course, everyone is free to jump in here and I mean, to help with the script. But in general, this is good thing that we either say, okay, look, these are good examples how you can use them. But if they are, I don't know, mature enough that we can actually also recommend to immediately import them and use them for their project. Yeah, why not? Thank you, Marcus. Okay, based on all that from what I heard so far, we should go with the separate repository option. What should it be called? Maybe it's better to even completely not mention the TOC at all. Just call it. If you want to just propose on the governance repo that you need a new repo and name it whatever. Okay. Something short templates, but then templates means that it's all sorts of templates, get-of-action templates. Okay. So maybe we postpone the concrete naming here because I mean, we maybe collect first a bunch of those scripts and really see if most of them are maybe just examples or templates or whatever. And then we come up maybe with a name which actually reflects the contents of the repository. And for now, just keep it somewhere as you have it here, for instance. That is a good point because some of them that I have in mind, they're not actually templates in the sense that they're dropping ready to use things. So they're not something you copy paste into your repo. They are the actual implementation that you just referenced saying that's the one I want to use, unchanged period. So yeah, good point. The verb template is also making it too specific and not accurate. All right. So then there's an action item for me to submit a request and the governance repo to create a task force repo for the collection. Collection of action. Yeah, I'm all set to come up with. Okay. Yeah, and just an aside that the things that the documentation task force mentees are working on is to get user guides for the maintainer so there would be a quick user guide for them to reference this materials. We could also store those there if there's no other place for them to be. We're going to try to organize that as the task force goes forward. Okay. We'll be calling you, Peter. So that was the most interesting, revelational task of trying out an action that showed me that they could have reusable actions. And so I have a few ideas on what else you could add there. But I know that I will miss a bunch of great opportunities for adding more. So I will also ask anyone either on the tax force or not on it to throw out ideas on what sort of GitHub actions we could put in that repository that some part some subset of the projects or all of them could easily use without. Further modification. And if you just have an idea, it's okay to send me the idea. I will happily go and do some research on the viability of it if you're not sure if it's possible. If you're not sure if it exists or if there's an actual implementation out there. That's fine. I just want to kind of expand our horizon on the task force with all the ideas that everyone has. And that's basically it from me regarding the automated pipelines for today. But I know we have other members in the task force. So if anyone else has any updates, then please jump in and share. Yeah, can you go to the document that we created the best practices? I forget who's sharing but. That was me. I just stopped the show. I'll go back to second. Okay, so basically what I did since the last meeting was I combined some of the best practice ideas that Stephen had with the best practice ideas that we gathered earlier in the year from the best practices task force. And I compiled them together in this more organized way that you see here. Basically it's got a few sections. The first one talks about branch protection rules. The second one talks about which CI checks to use. And then what we can do is where each of these have a short border to around the best practice on the left column and the right column put references to either external docs or to good reference implementations of some of these things. So I'd encourage everybody to take a look at this and to go ahead and edit in place if you've got other ideas. And then the next section down talks about how to most efficiently use the checks. Again, a lot of this information we gathered earlier in the year when we were having some issues with the CI times. Oh, yes. This is great. Thank you so much for this. This one I cannot highlight enough because I've seen it so many times that people struggle with a simple compiler bug or a compiler error. And for some reason they just don't want to compile on their local machine. Maybe their machine is not powerful enough. They just end up using the CI as their personal compiler, which was fine when we weren't worried about resource usage. But nowadays when we know that there can be trouble with it, it can be bad when I see sometimes people pushing 15 different versions of the same pull request in the same hour and they're just trying to make some fix and they don't really know how yet. So yeah, this, this is very important. Okay, let's keep going down. Let's see what else is there. Yeah, there's one open question for Steven. So Steven had something about pre-commit rules, which I don't know a lot about. So I asked even if he could clarify that one. I don't know a lot about the media. Quite frankly, I do know that in a couple of our repos, pre-commit rules are applied and used and basically they force the developer to run sort of local operation before they're allowed to do a commit. So it's just a useful thing for checking PRs before you submit them. But exactly how they work other than that is that's about as much as I know. Alright, so if anybody has additional information, you can go ahead and edit that document. I'll see if I can find somebody on the team that knows more about it. I can add some links there. We use husky and commitlin on cacti to enforce that you have certain format for your commit messages which then we use to parse the commit messages later into release notes. And yes, basically husky is a tool that generates a shell script for you that it places in the .git subfolder. And that shell script runs before every commit and it does the check on your commit message. So I can add some of these details on to that document. But also if there are other tools out there, I also want to know about them. So please still go and ask the team as well. Okay, great. And I didn't have anything down there for what Peter showed earlier. So Peter, if you could add the things that you're doing into this document, that'd be great as well. Yes. Okay, that's it for me. So actually, I think the document was data document was any questions, comments, etc. Cool. Then I think we're done with the task force discussion for today. Alright, thanks Peter. So any other topics that anybody would like to discuss today before we close? No. Okay. So I think next week is the badging lifecycle task force discussion with the TOC. We'll see what other items we come up with for next week's agenda, maybe closing on the security policy as another item. And we'll see what else comes up. If there's no, yeah, Arun, go ahead. Right, Tracy, I just wanted to call out that we are internally checking with the legal team before that discussion is brought up. But if you do have any dependencies. So there recently, Hashikov has changed their licensing policy, and that may impact. More projects I saw right posting the files that will be impacted due to that license change. So if you're part of the project team, then please do evaluate and see what is the effort in terms of avoiding any issues due to that licensing changes. Alright, thanks Arun. I mean, we had a discussion on Tuesday and that maybe instead of bringing it up to the TOC today, we would first check with electronic legal to determine if they have any sort of guidance on what needs to happen with the change from the Mozilla public license to the business software license or whatever that stands for. So anyway, there is that issue that was created to get this issue 151 in the TOC repo that basically talks about this and lists the different files that are potentially impacted here. So do you have a look, there's a number of different projects that are listed in there so a good number of our projects are there. Thanks Fry. So this particular issue, just have a look at and then we'll also see if we could get some information from LF legal on kind of guidance for what we should be doing. But if there's something that you already know you can do, then go ahead and take care of that. Rama. Yeah, Tracy, I think you mentioned that the badging task force discussion next week but the next badging task force meeting is on Friday and I think it'd be more useful to report back to the TOC the week after. Okay. See so just trying to think about the other task forces we just did the CIA, I think the other task forces that we have are the security task force for signing and then we have the documentation and the onboarding task forces and I'm not sure if anybody there is ready to report for what's been happening. So, Arun. Yeah, Tracy I can follow up on the, the artifact signing task force next week. Okay. And then with the six stores in one of the project, I can share the experience and the learnings. Sounds great. So we'll focus on that one and then Rama you'll be in the week after other comments questions before we close. Okay. Well, I hope everybody has a great week and we will talk to you again next week.