 All right, welcome everybody to the March 16th hyperledger technical oversight committee call. For those of you who don't typically join us, but you're probably also aware we do have to abide by two things on this call. The first is the antitrust policy that is currently being displayed on the screen. So, basically, don't act in any way that's going to impact any of the applicable antitrust or competition laws that might exist. The second one is our code of conduct. Basically, don't be a jerk. And we will all get along just fine. And then, yeah, I guess for the meeting today we have our typical announcements that definitely developer newsletter goes out each Friday. If you have anything that you would like to include in that newsletter, please do leave a link or comment at the link that is linked in the agenda for the upcoming newsletter. As far as quarterly reports, I believe the only one that's really outstanding for us to take a look at is the firefly one. I believe there are six to see numbers who have reviewed that at least as of yesterday. If you haven't had a chance to review that please do. We do also have one comment on that report that is outstanding. And based on our rules, we cannot merge that until that is either addressed or the comment is somehow removed. So we do need to take care of that firefly one. As far as the past year reports with hyper ledger grid, you may have seen there was a conversation on the discord channel, we're looking to potentially move that project to end of life. There is a issue that I have opened in the TOC repo the will probably give a give a moment for people to take a look at that review that it's copied the grid contributors I know right has opened up a number of issues in the different grid repos to allow for the grid contributors and contributors to reflect on that and see if there's any comments and we'll probably bring that up to the TOC for a vote next week if we haven't seen any comments to the contrary. So, so far Dan and ROU have commented on that particular issue with a thumbs up, but we'll be revisiting that again next week. The transact one as I'm still waiting on a list of maintainers from transact based on the conversation that I was having there with Sean to determine what its status will be. We may just do a very similar sort of thing with that and open up an issue and see if we can get some responses coming from the different containers from transact. As far as upcoming reports we do have the Ursa one that is for Q1. I know we just got the Q4 one a couple weeks ago, but Q1 is now up for review again so we'll look to see if we can get the Ursa community to report on their Q1 work. We also have Basu and Calliper that's coming up next week. Any questions on the reports as we stand right now? Okay, I'll take that as no. So for discussion items today we do have three items we have the brand update from then we screen to tell us about what's happening there. We have the maintainer guideline PR that we talked about a bit last week but we'll hopefully bring that up for discussion and potentially a decision there and then we have the task force discussion for the onboarding content. So with that I'm going to hand it to Ben to give us an update on the brand. Thank you Tracy. I'm just going to share my screen here if that's all right. Sounds good. Okay. Firstly thank you, a shout out to David Boswell and Tracy as well for bringing this to everyone's attention and working with me to help bring this to the community and roll out plan for the rebrand. This is something we've been working on over the last four months now. Why do we need to rebrand? It's the current brand is seven years old. The stretch has been stretched as far as it can and we've the teams decided it needs a strong refresh to make it more marketable for prospective members and to strip away the frills and excess design appeal to appeal more to developers. Some of you may or may not know this is what we've been up to, but we wanted to make sure that we bring it to the community in a timely manner that doesn't upset or surprise anyone. I've been working with the marketing committee on this as well who've been heavily involved with us and the team throughout various stages of the rebrand. And we've also presented it to the governing board thanks to Tracy as well who provided some really excellent feedback. So at this point, I'm happy to basically present it to the TOC and the plan moving forward will be to roll it out into the community and hopefully launch it alongside a new website. Most of you probably know our website is increasingly performing badly. The load times are terrible. It's pretty much falling over at this point. So we're upgrading to a new HubSpot website that will usually increase performance and the thinking is to launch that with the new brand in about two and a half months. Sorry, the rationalization behind the new brand is that we want to have it be more of a direct representation of the blockchain business community. Have the brand colors reflect more of our three top values trusted open and enterprise grade, and most importantly differentiate ourselves from all other members and the crypto community. The current icon, I think is an improvement on the current one which doesn't scale very well across all properties in terms of sizing. It now represents the trinity of nodes foundation members and community, and while still retaining the character and memorability of the current icon it's essentially exact almost exactly the same shape ankle and known style but visually stronger. And yeah, as I said, it's, it's way more scalable. So without further ado, this is the new logo brand mark icon color scheme as well in vertical. And this is how it will look across the new website. This is basically a kind of mock up to give you an idea of the look and feel. It learns a lot stronger. And again, these photos are just for mock up purposes, but we're going to use photos sparingly with layered graphics to create more depth, much simply UX UI. And again, we're working the website to bring it up to speed and basically the whole purpose is to bring high pleasure foundation brand into the future, and make it way more appealing for prospective members. And put it future forward. I'm working with the LF team as well to the design team and the website team to make sure the website is a lot stronger. As I said, high, much higher performing, and that UX and UI really spot on. We, for example, most users spend an average of just under two minutes in total on the website. So we want to make sure that it's extremely clear the information is very accessible. And we're going to, you know, really start stripping back a lot of the convoluted information that's currently on display so that user journeys are much more straightforward. And if you need to deep dive and find the access the information, the detailed information you're looking for that is a lot clearer to find as well. The plan is to launch hopefully mid June. As you can see here's the, the website design timeframe. We had the final revision of the brand delivered in March. We plan, as I said, we've shared it with the governing board, we've shared, we've worked closely with the marketing committee. Now we're sharing it with you guys. And the plan is to share it with project leaders next, and essentially roll it out to the community over the next month, so that in mid June there isn't a big shock and surprise. If there's any questions, or any feedback, more than happy to take it, please get in touch with me directly. Thanks, Tracy. All right, thanks Ben. Any, any comments or questions for, for Ben at this point. I've seen a couple of thumbs up Ben, just for your reference. Right. So, so far no questions, no comments. Oh, I guess one. Will this spill over and will this impact the per project logos, or do they, will they kind of fit in. Do we think. Yes, good question. We, I think we're going to do it. We're going to do the transition slowly first it's going to be the website and, and the launch off of 30 brand of essentially what you've seen here. We would like to bring the, the actual brand mark just the hyper ledger font in in line across across the community. But I think the plan is to roll that out slowly again, you know, in a timely fashion. We're not talking about rebranding icons. None of the project icons are going to change. We may look at updating the, the SIG icons for example at some point but yeah, we're the plan is to is to is to do it collectively and in a fashion that doesn't, you know, surprise or upset anyone. Right. Hi, can you guys hear me okay. Yeah, thanks. So, I guess one question I want to bring up is that I also see sometimes we have an overlap between other Linux foundation entities like, especially like I said to AP. Are we also thinking of delineating up working like we do, especially in the field of, you know, the eye, like, compared to what other organizations doing I think that's going to be helpful because otherwise a bunch of times as a, you know, there's quite a bit of confusion between just a exactly like, like, of course we have, you know, areas and so and, and, and they, but there's quite a bit of overlap between what other organizations doing so I think it may be helpful also to have some better delineation over there. Can you help clarify the delineation exactly in terms of project logos and branding or Well, not just in terms of the graphics on right like like what I'm saying is that and correct me if I'm wrong maybe this is like if this is not the right, you know, scope for that, but basically what I'm trying to say is that I guess one of the reasons we're doing rebranding here is to because when people come in and you especially want to appeal to the dwellers and and have, like, not not just basically make this like marketing but people can have a clear understanding of what hyperledger involvement can help them with, correct like like to prospective members and also to the developer community. Right now. In my own experience what I've seen is that, especially people are like, I think there's a bunch of like obviously the major hyperledger projects, whether that's fabric or other ones they or all these other ones, they have a very clear use like and very clear set of use cases. But when it comes to decentralized identity, I think there's a bit of an overlap, like and I've seen the same thing happening in the identity workgroup, where I believe I brought that up in one of the previous meetings today that it's not very clear as to, you know, what what is the desired outcome. And from the identity practice we've working on and hyperledger versus and to IP and they're both of course falling into the Linux foundation umbrella. Now of course W3C is a completely different thing the IF is different, but at least within the Linux foundation ecosystem. I, I'm hoping we can, like, like when we are, you know, having some like when we especially when we have the project information here. I guess it'd be helpful if you can clearly say, well, here's what hyperledger is doing here's what like and if you want to do XYZ then do IP is where you better, you know, collaborate over there. Sure, I think I think I hear what you're saying, maybe this will answer your question. Hopefully, I've been working with closely with David Boswell on this and he's been leading the charge in terms of updating the project page for example. Yeah, I don't think we've been doing a good job of clearly delineating and explaining projects and the overlap of projects. We are working on an entirely new project page and project matrix which really is helping to define and explain exactly what projects are what they do what they use for and how they overlap as well. So there is a new matrix in the works and yet the goal of the UX and UI website update over the course of the next month is to is to make everything a lot cleaner, a lot clearer. Yeah, as I said, we've only got a few minutes to to make sure we direct people to the right things and explain everything as clearly as quickly as possible. So yeah, how does does that hopefully answer your question a bit better? It does, Ben. Thank you. And I think like in that matrix, I think it'd be also helpful if you can say also somehow show what is the relation with the other, you know, links foundation projects or in general with the other open source projects like like W3C, like, you know, like W3C is basically of course setting standards, but like for example to IP is coming up with and like like of course we talk about open wallet foundation. So, like, like anybody who's newcomer in the di space, then they would know it's like, oh, if you're talking about walls, then you got to work with the open wallet foundation but if you just talking about the cartographic thing then you probably focus more on the other side of things. I see what you're saying. Yeah. Good point. Thanks, David. Thank you. Stephen. A much lighter topic. Greens. A number of the logos have greens. I noticed the use of green in this. That was that would be my only concern about the, the project logos would be either contrasting or, or need for alignment of the of the greens being used in the projects and the projects I'm involved with are both using that. So, there you go. Yeah, thanks. Yeah. It is, it is, it's a complex design task and yeah we're making, we're getting many iterations of the, of the web design and layout to make sure that. Yeah, we're clean and power fine. All the first design elements. Thanks. Hey, I just wanted to comment on Sandy's point. So I will say Sandy that at the LF level, we are working on something that people have internally called the digital trust initiative which, although that will probably change in terms of name. What it is doing will stay the same. And that is exactly what you suggested to have a place where we put all of the projects involved in digital trust, like, you know, obviously identity and some others in context. So we explained the relationship between all of them. And, you know, tell people where to go for different things that they're looking. So we know this like identity, you know, we know there are a lot of projects in the LF that there's some overlap and identity. And we're working on this at an LF level to make sure that, you know, people can find them all and they know where they need to go. Thank you. Morning. Great to great stuff then my, I've always wondered about the members in the, the visibility of the members that support this phenomenal foundation, and it seems they're buried in the about section I think on the current website. And I just wonder whether they should have a more prominent standing somewhere on the within the within the website, but other than that, phenomenal work. Thank you. Thanks appreciate it. Yes, totally agree. We're getting away on the current site, but again, we're redesigning membership page. Members are going to be front and center and the two clear journeys for new developers wanting to enter the ecosystem. Current developers, maintenance and contributors, able to returning visitors able to access things a lot quicker. And of course, yes, members really completely redesigning membership page. The homepage again will be much cleaner, focusing a lot more on the members. So yes, the we've got we've got those journeys in mind and the plan is to definitely put them more funds and center thanks. Thanks. All right, well thanks Ben for providing us the brand update. Again, if anybody has any additional questions or comments, please reach out directly to Ben. We'll now move on to the maintainer deadline PR. I think the only item that is really open on this at this point is this question of what is required in the maintainers guidelines as far as information about the maintainers themselves this particular comments. It's here. So I think previously we required that you had to have all of these fields. I think the way in which the PR is written right now is that it is recommended to have these fields instead of a must. So I think that's as far as I know the only item that's open. So what does required mean. So, and I'll give you an example. When we retroactive retroactively go to create these the way you do it is you find who's on the team. The teams associated with the repo to see who has extra GitHub permissions and the only information you've got is the name and the GitHub ID. So, when we create these. So that's all you have. That is the minimum and so that's why I put it that way is that there's not a way to get the other ones there other ones are nice to have, but that's all you can get. So that's, that's where I was coming from. Second point was Ryan mentioned the the need is based on the ability to contact the person and GitHub ID as far as I know is sufficient to contact the person so that that's the second. So it's actually both of those reasons that I put those two as required and the rest is optional but I'm open to change I'm just saying that's that's the rationale. So I'm puzzled by what Stephen just said, how do you contact a person with just the ID an act and a GitHub message. Or or you can open often find associated with it. Sure. Yeah. I don't know why we're contacting so I didn't have a comment on that but that was good. So first I wanted to thank you for working on this I think you know you deserve credit for putting this together but beside that. I was going to say this, you know, it stems the initial information being requested the stems from the fact that it's not often easy to figure out how to contact people. I mean you just said yeah you can create an issue I guess and put a hat or something like this. But other than that, it's not easy to contact people and this is the aspect we wanted to have is to be able to reach out to people. So, unfortunately, I mean we haven't discussions before but how much of the identity of the person needs to be known. I mean, there are people basically say nothing on their GitHub profile. You really don't know what they are. Yeah. And so that was primarily the, and then the company company affiliation on that obviously has more to do with, you know, diversity requirements we have. In terms of the rest I think it had to do with this notion of, you know, the more information we can get on how to contact people the better off we are. Some of it would be historical though, because, you know, like an FID and child ID I think maybe we don't need all of that. Yeah, I think auto definitely chat ID is historical for sure. I think that, you know, we have today the ability to at, you know, a group of maintainers in discord. So, you know, maybe that's not as required. I do see, right, as we're dealing with say transact, the at transact maintainers isn't working to contact those folks in discord. So, you know, we'll, we'll issue in GitHub. Hit that I don't know, you know, we've only had one grid maintainer actually comment so far on that issue, right regarding the end of life. So is that really enough I don't know. It should be right because it should hit the emails if they're watching it but if they've stopped watching it for some reason because they're not actively involved anymore than maybe that doesn't actually gets them. So I think, you know, the biggest thing truly is how do we, how do we get in touch with people when we need to get in touch with people. You know, in these cases of, I'd hate to move a project to a status and then, you know, the next week have people come in and complain because they weren't notified that they, you know, didn't know what was going to happen. You know, those are the sorts of things that I think about when it when it comes to contacting Steven you asked like what would we contact people. That's really I think that the majority of what we would be looking for is to make sure that we can truly touch these people when we need to touch these people. And then yeah company affiliation truly was for the diversity requirement that we have for moving projects to graduate. I think it's worth pointing out, I mean, you know, Steven you talked about filling out that information after the fact indeed that's, that's hard. But if, you know, for at least new maintainers right if this is the information that is required and you use a full request to add a role to the table. It's, it kind of, you know, it's easy to capture that information at that time. Yes, absolutely. And that's, and so I'm just kind of hung up on the on the on the wording to use that's all. I'm really not sure what wording so if anyone can suggest the wording I'm happy to take it. I would like to see the LF ID and chat ID dropped. And I would like to see scope. Included in the required so that we can, you know, make sure we understand I think I've done a better job now of explaining what scope is. I hope that was that was the intention and I think it, it makes more sense in that it's mostly tied to what you can have privileges are on the repository although it can. It can be, you know, can left open the option to vary from, you know, unrelated to GitHub permissions. And I would note I did add from last week's discussion the point about pointing maintainers file for a given repository to another maintainers file. So that's in there as well now. But if someone can help with the wording on this little bit. And as I say, I think I think we're saying LF ID and chat ID come out. Oh, hearts going to stand up. Yeah, can I make a point in favor of the LF ID and the chat ID. It's going to be hard. Well, you can always make it. Yeah, of course. So, the LF ID is going to be very useful for analytics, right, like if we want to do LF analytics. You know, that that kind of thing is useful, particularly for correlating across projects like if someone's working in hyperledger and they're working in something else. They may not be using the same GitHub ID. Oh, interesting. If we can use the same LFI if they use the same LF ID, then we can potentially correlate across projects. And if there ever becomes a time where like, you know, we have to lock things down more substantially than LF IDs will be, you know, much more useful. I think we've been having a big issue. Well, a bigger issue. We've had a number of meetings zoom bombed across the LF. You know, and, you know, I mean, you could imagine a scenario where like, you know, at some point, you know, if this becomes bad enough where you have to have an LFI be to join a meeting or something like that right. And so, you know, I think that's good. And I also think it's important to link like chat IDs. I know this is sort of done informally right now but you know rye gives privileges in chat to maintainers. And he sort of, you know, does this by hand right now. And having this, you know, done officially would make rise life much easier in this regard I think a little rye can can speak out on this himself. I agree. I appreciate it. Yeah, maintainers do have special privileges in discord. And like, if it's not official, then it becomes a big pain. I think those two should be included. Feel free to do what you want, though. I have a suggestion. I mean, you know, would it be okay to say, okay, you can ask for all of this but at least two must be provided. And, you know, so that way we have at least one additional way of contacting people and then it's, if you don't really have those. I think, you know, in response to the point you've just made with rye doing by you could say well look, if you don't provide you have ID you won't get certain privileges. Okay. I think actually this is enough that I can put in the should be completed as much as possible. And here's the rationale for why, why the different pieces of data are needed how about I do that. I'll change it to discord ID. Let's just assume we're going to stick with discord for a while. Yeah, and Steve and I, and to our nose comments, I think, you know, the previous or the existing guidelines, right before this PR say there must be at least one reliable mechanism to contact the maintain or either chat idea. Yeah. So, you know, I think, I think what you're recommending is good. And then, are there other comments besides this one that we should address. What did people think. I was surprised there was very few comments on the list of example list of duties of maintainers. So I hope I got those down I did get a couple of places for comments. And I'm here for feedback on that. And as after last week's I added to it, the, the need it was it's in the sample maintainers. The security requirements. So it's that list right at the bottom of the screen there. Yeah, right there. So I'll stop after last week's discussion review responded act on any reported security vulnerabilities. And I see the word reported in there twice which is bad. So I'll take one of those out. But anyway, that's a list that I found to be useful. And for what I, you know, what I've seen and what I think the duties of a maintainer are. But I think this is actually the section of why I started down this path of, of adjusting this was to get this part right. And again, people can, this is a sample one, and people can adjust it to maintainers can adjust that based on their, their, their project. But I think this is the really important part. I think you must have done a good job of capturing. Okay, I'm just worried people didn't look at it enough. That's the other option. Steve, I just wonder why I'm sitting here. Just because I don't know how this works today. The one a sort of scan, like, is this some, like, like, is this some sort of like, like in our bank for example we won the tenable scan for the vulnerability so like how frequently is that one and is there like a specific team who does that on a routine basis. Sorry, what was that again. I mean, for the vulnerability scan so how do how do the maintenance actually know what will include is out there. They are there any scans which are run by like a central team. So whether the files out there and whether it exists. No, no, I'm sorry if I'm not clear of my body is not clear what I'm saying is that, like, how do we want the vulnerability scans like is like, like, hold on how the vulnerabilities get sorry. So vulnerability scans come or things come from dependent bought alerts. That's one which is showing here. And then the other is security reports on repository so security reports that's the securities tab there. Okay, the dependent bought results are there so those are the automated ones from essentially from GitHub, and then as well. Individuals can report security vulnerabilities through this or through hacker one. And when those are reported those need to be paid attention to and and that was the discussion from last week and that's why I put that as the highest priorities. So these matter, and we shouldn't have this many dependent ability alerts. I assume this is not a good example. Not a happy example I know of one in our world that's not a happy one that we're trying to get rid of the repository just because of it. I didn't. I was going through this earlier and that one just jumped out at me. Yeah, I will point out that the talk members of the talk have read access on these repos specifically so that they can see the dependent bought alerts. Okay, and that's across all of hyper ledger. Okay. And then I'm assuming that if we have to if we cannot resolve and remediate something on a time basis, then we have some sort of an exception process for that. So, like, like the example that just popped out here so if we for any reason let's say there's a product dependency or there's a timeline dependency we cannot resolve this say by the end of March. We follow like like me probably clear an issue and then put that on the on some sort of a chart up there. So, so there is an issue that those security like CBEs. So, you know, critical, critical vulnerability reports, those are issues and those get created as such. For example, when we had one on India couple on Indie last year, they got added to a discord this session we created a special channel for it and invited all the people to collaborate on it but the whole thing is to try to make sure we stay on top of these. It's up to the project to do whatever the project is going to do and it's up to, you know, all the maintainers on a repository. What I wanted to call out was I'm finding as new maintainers come on they don't really realize that Oh, I could, I could. So part of my duty is to make sure I'm looking at the vendor bots results often they know that, but they don't realize that oh you could get a, an actual person reporting something. And, and when that happens you have to deal with it. And it's important and so it needs to be top of your list. Coding, I've got coding pretty far down that list. So third from the bottom. There's lots of things that are, you know, important to do that maintainers should be doing ahead of simply rating code and putting it in. Hopefully the other things don't take a whole lot of time so that they that third from the bottom gets lots of attention but this is the order, the ordering matters I think that was the intention. Anyway, thanks for letting me highlight that. So I think the next steps and Stephen you're going to do another commit to this. Yeah, some changes. The TOC members please let's review it on GitHub. Provide any additional comments that you might have approved if you think it's ready to go. And then hopefully we can get this one closed out. And even for taking us through that. Bobby, you're up next. Thank you Tracy I'm going to share my screen real quick. So basically I'm here to talk about where we are with the onboarding task force. So there's like a few new things going on. One is that we are applying for mentee to help us with the sections. We are working on, let me just switch this over to the GitHub, we're working on the four spots where people come into the community, and the four different types of, I'm going to call them learners who need information. So the mentorship program, what we want to do is we want to have the mentee help us develop these and kind of make sure we're all on the same page. I did put out a survey, which is in the discord channel for the onboarding task force as well as the GitHub repository. So just to find out what time zone and what of the specific pamphlets or guidelines that you'd like to work on, and any comments you might have so that when we get that together I'm going to sit down with David, and we will figure out exactly what we need to do to set up a time and so that we can get this really rolling and hopefully get accepted into the mentorship program and have someone to help us do this. So again, I did post it in the discord, but my discord is being funny. So that's it. Does anybody have any questions? Bobby obviously expected to have one minute to talk about. I didn't think I'd have a lot of time, especially with the maintainer conversation. But again, we're just having trouble because people are all over trying to figure out a convenient time because the meeting on the Monday afternoon isn't really working out for a lot of people so we really want to get this started so if anybody is interested in in helping out with any of these landing points or these guides, please fill out the survey so that you can be included in the conversation. Thank you, Bobby. So I guess that was our agenda. We went through it quicker than I thought we would. So any, any other topics that anybody would like to bring up for anything that we should discuss before we close out. I have one question about the maintainers thing. Will there be. Will this be retroactive will we be expecting projects to come into compliance. And by we of course I mean all of you. I think we should promote it for sure. I think it would be a, you know, based on my, you know, limited but interactions with maintainers on projects I think there's not enough understanding of what the roles are and how you become one and like oh man I'm you know my, my PRs aren't getting reviewed fast enough well. Maybe that's a maintainers job but be maybe it's time you became a maintainer or, or, you know, when things like that so that's the conversation I'd like to trigger in the, in the projects and repository so happy to see that. Okay, so one of the things I've been doing over the last week or so is when people file a request to have someone add and get a, I've been saying find update maintainers and then we'll do it. Yeah, absolutely. And then, you know, this would also be an opportunity to say, you know, bring your maintainers file up to snuff, but yeah, you know, yeah, well let's get this out there let's get it available to be pointed to and then. Yeah, let's get going. Cool. All right, any other items for discussion today. All right, I will take that as please give me 10 minutes before my meeting, please. So we will post this meeting, we will talk again next week. Thank you everybody for joining. Thank you. Thanks.