 Welcome to the July 21st type of letter technical stern committee call. As you're all aware, two things that we must abide by the first is the antitrust policy notice that is currently being displayed on the screen. And the second is our code of conduct, which is linked in the agenda. As far as announcements go, we have the standard announcements that have weekly developer newsletter goes out each Friday. If there's anything that you want to include in that newsletter, please leave a comment on the wiki page that's linked in the agenda and go out to hundreds of head ledger developers. Any other announcements that anybody has or would like to make. Okay, no announcements. So as far as quarterly reports, we don't have any do this week. I did provide a link for you to check any open task or previous reports in case there were any that you haven't had a chance to review yet. The hyper ledger transact report is due next Thursday. So we may or may not get that before the meeting next week. But we'll obviously cover that next week. I did not have any specific TSE business to discuss this week, but please if anybody else has something that we should be discussing. And now is the time to speak up. If I just wanted to quickly mention that I wrote a process that checks a bunch of our repos for things and I found that there are 50 something repos that don't have a maintainers file. So we're going to plan on reaching out to those projects and asking them to add them, even if it's just a redirect. So, okay, great. Thanks, Ryan. Hey, Tracy, thanks. So we had a brief legal review over our charter language. Okay. While, while the essence of what we wanted to capture in the charter and the overall plan is fine, it looks like some more of our language is going to have to be modified. So unfortunately, this is still going to be an ongoing process. And we will keep everyone posted on this. Thanks, Hart. And we did review that just the overall essence of what it is that we wanted to change with the governing board on Monday. And there were no sort of concerns. So I guess next stage heart is to finish up the legal review and any sort of wording and then take that back to the governing board for their vote. Is that still the correct next steps. That's exactly right. We just need to get everything polished. Well, apparently our charters now on the older side of charters in the Linux foundation. And there have been some desired updates. Again, not changing anything about how things actually work, or the essence of the charter, but just the terms themselves. So, Great. We'll look forward to seeing that when it's ready. Any other TTC discussion items before we move on to the task force discussion. Okay. I'm not seeing anybody come out from you or any hands so Jim, I think it is over to you to talk about the project health task force. Yep. Thanks Tracy. We share the screen. Okay. I did some fall work from the discussions we had in the last call that we talked about this. I feel like we're at a pretty good place in terms of recognizing the different types of data that needs to be collected to accurately reflect the health of a project and where they will come from. I think I feel like the next step is figuring out what do we do. And what are the things we should look at first to get things to get things going to get data actually collected. To that end, I categorized the stuff that we listed in this column the supporting data column into two different ways. One is under this bullet list in three categories. What are the things that are quote unquote easily collected with API calls, because they came from a developer friendly platform like GitHub or discord. They don't really exist behind any API so we have to manually collect them. And the third category is they don't necessarily exist anywhere, even in digital form, they pretty much exist in people's minds. So we have to think about ways to pull those out using surveys, for example, it's just one measure that I could think of. So we have to ask people for this kind of information. So, as you can see it's pretty straightforward the GitHub and discord information can be can be pulled from API calls. We'll talk about separately who we contact or you know who do we work with to make those API calls happen. So in the second category, we need people to go to these different places, they may be in documentation section of a project they may be in wiki pages or meet up in various places, and just collect them manually. There is also a third category where we should maybe work with the marketing team to think about, can we create can we create surveys or polls to ask people about about things. I won't go through each of these bullets individually but are there any questions or comments or feedback on on this part. So especially in the third category, besides surveys. Do we think there are other means to collect this type of information, for example, how do we know if a community, a project is actively and effectively involving the community to define their roadmap. So I would like to ask the, the participants of that community that are that are not committers to ask them how do they feel right how do they feel do that do they feel they are being included in defining the roadmap. I don't think there's any objective data that exists anywhere that would tell this story. The second bullet about can new ideas be accommodated similar to the first one. There are outside voices being respected, and that's it's pretty subjective that we may have to just actively ask people about. So, all of these are in this kind of category. So can polls and surveys is the only way to create this or do we have other other ways to do this. Maybe, I don't know, I don't know if folks have ideas to contribute here. I think you used an interesting word when you use the word subjective. You know, I, I think that the challenge when it comes to measuring project health based on subjective type of criteria versus objective type of criteria is going to be very challenging. From the perspective of you may think people respond to you very quickly, I may think that people don't respond to me very quickly for project rate and what what is the difference between you and me in that case or maybe it's the question that's the problem right it's not the individual. I just, I think there's a whole lot of challenges that come into play there. So, I think we need to be careful about criteria that might be considered subjective for measuring project health. Although, in some cases, the feeling that somebody gets when they tried to enter a new community is so much more important than anything else. Like, do they feel like they're welcome. When they join a community call, are they immediately welcome even if there's somebody who's never been on that call before, are they not welcome. That's going to have a big impact as far as whether or not somebody decides to stay in that community, right, or whether or not they decide to go. And so it's, it's, I think this is the, the important part to being a welcoming community like this is how, how, how much people feel like they belong to that community and are welcomed in that community so I don't know that that's a, I don't need this anywhere but I think it's something that we need to really consider with this particular task force of measuring project health versus measuring the, the desire for people to stay once they've joined. I very much agree with, with the comment, Tracy that this category touches on the more soft side of things, which is still very important. It's addressed in multiple different ways and it's very hard to measure with data, how welcoming, you know, the tone of voice, the presenters are during the community calls, when people raise a question, how are they treated. Do they feel welcome and respected. So, I, I, I chose to work subjective because that's definitely from each individual's point of view is subject, subjective feeding more than anything else, and I do agree that it's a pretty important part in people's decision. I don't want to continue to engage with this project or not, because every time I said something, it's either neglected or shut down, you know, why would I waste my time, because I'm not making any, any impacts. My first question, you know, led to a great discussion that that ended up being a feature that lands in the next release that's, you know, that's a great way to engage people and it's hard to collect data along that along that process to say this is what the project team is doing right. You have to, you have to ask. So I think the third category is probably the most challenging part, but it could also be very straightforward because we know how to create polls, we know how to design the right questions. We just need to decide if if that's that's something we want to do. Go ahead. Right. Thank you. Jim and Tracy. So I believe the topic that we are discussing kind of ties back to being responsive and in the community so that people feel welcome about it. So very common very similar topic that ties back probably ties to both of these roles right for instance, how friendly a particular project is and then what other alternatives do we have and apart from surveys. So, this also came up in our security process task force and then Tracy I saw your replies as well. I'll try to address them. Was that some of these issues that are reported through these tools that are again linked to Hyperledger Foundation right for where for instance the security issues are reported. We need a mechanism to address them in time if that's not done then when I say address it should at least be a reply saying that hey dear effort is considered and we are in process of evaluating right so even such an response would matter to us. So these external tools that we currently have. I guess that's the security reporting tool that we can consider for now but there could be other tools which I'm not aware of could also play a role. I agree with that. So, besides the discussions that happen on Hyperledger properties, you know the community calls and whatnot. Those external tools should also be considered. Yeah, thanks for that input. Cool. If there's no other feedback for now, maybe we can continue. The second thing I did was for each of the items I listed them with different color, trying to decide what are the things we can start doing in the first phase to collect them. So, green means easy blue means a little harder and red means very hard. So, if we can agree on the list of green items, then we can think about doing them. So, I guess, I don't know what's the best way to run through that. Maybe just give folks a few minutes to look at this list and see if the coloring makes sense. And we should and then I'd like to start talking about how do we how do we go about collecting them. Who do we talk to. So, folks, please maybe take one minute or two. Just take a look and see if any jumps are at you that's miscolored. And we can talk about those and then we'll move on to the how part. So, third diversity the first bullet, the number of organizations contributing to the code base and roadmap. Ry you sent out a link recently to a tool that collects some data. I forget what the tool is called, but I had a look at that and they did have organizational data associated with that and I'm wondering if we could get that information if we could also get that information in some way shape or form and maybe that's a green instead of a blue. Are you talking about the GHE thing. No, no, no, the external tool. Let's see if I can find it. You have this cord. The open something to I'll. Yeah. Okay. Yeah. So I'll go link and drop it in the TSC chat. Okay. Is that a tool that tells us the organization behind each of the GitHub handles. It's OSS insight that I owe. It's what it is. I found it. Right. When you set it open, I was able to search. And you can specify a repository and it gives you a lot of data on, on the particular repository. Trying to grab a link. Yeah, I also did a thing about. I added a thing for hyper ledger as well. I put a link in the, in the discord channel for today's meeting. So people would like to take a look at it. I think there's some really interesting information in that that you'd found there right. And so could be, could be something that we use as we go forward. Oh cool. That's, that's great. Thanks for that input Tracy. Let's give folks another minute to run down the list. I also, I created, I posted a link to the hyper ledger collection. And I also created collections for Bezu and fabric and I will post a link to the fabric one as well. OSS insight. Okay. So let's talk about how to go about collecting them. The first obvious place is get up API's. A lot of us are developers we know those API's and we know you can make a lot of composite API calls and process data right some simple programs. For discord. API's. I guess the main question is, who would be doing this kind of thing. I know I can do it, but I know a lot of people on the call can do it, but we don't really have the time or the resources necessary to make this a mission for ourselves personally. I don't know if hyper ledger has the resource for doing this kind of thing. I'm, I'm completely asking for your opinions. It's something that we can automate, then preferably by a get up action, then the answer is, yes, if it's something that we can add to LFX. The answer is maybe. The second one. Insights LFX insights. It's undergoing a lot of change right now. I can't even add like new projects to it. Once they get the new version public, then I'll see what we can get. Yeah, please are. Yeah, I just wanted to second right here that in the long run I think a lot of this stuff is a great, you know, it's great suggestion for what LFX should include. So, you know, if some people from the community want to go talk to the LFX folks. I think that would be a fantastic thing. I think they would be interested in hearing from you all. And, you know, it might be a way to push things that that, you know, we want into, you know, places that would actually benefit everyone at the Linux Foundation is where I correctly pointed out. These folks are extremely busy and behind right now. So this is again a longer run thing than a shorter run but you know, it's something we should definitely consider. Sounds good. So, if we want to talk to the LFX team, I guess it will be just me and right getting a call with them. Is that as simple as it is that. Yeah. We can we can set that up. Okay, sounds good. So I heard get up actions. This would be asking each project team to set this up in their repositories or this is something that the hyperledger team can set up in at the level. I would prefer to set it up in probably the, no, not for every project. That's just terrible. I mean, it would be code for no reason. I'll find a repo or make a repo where it can park. Great. And did I hear right you volunteer to, to looking to this. I think we can definitely help, you know, with in terms of finding the API finding the right end points and that sort of thing, but would you be responsible for looking after this, this repo and the content in it. I can. I, my preference would be that I don't develop it. But let me take a stab at it. I'm already collecting a bunch of this data in other ways. Yeah, I saw those. So let's just give me. Let's just say no firm answer at this point. We probably can ask for help from the community as well. There's a lot of There should be, there should be people who are willing to help in this way. Okay, cool. We should get the repository set up and then at least make one or two endpoint calls to show how things should be implemented and then we can we can grow from there. I think between you and me we can at least get something going to show as an example how things should be done. And then over time that can be built up. Okay, to you, right? Yep. All right, sounds good. So that covers the GitHub API is in discord API is. And that is majority of the green items. Let me think. There are also these other things that are marked as green, but not API driven. Meetups, for example. The meetup platform has any PIs that we can use to say how many Meetups were organized by the hyper ledger ones. Do we, how do we even identify the hyper ledger ones. I don't think that there's a single organization that owns all of the meetup groups. There is we have a paid meetup account. And there is pretty nice API as far as I know I've looked at it but we haven't really used them but I've looked into it and they do have pretty extensive. Okay, that's great news. I haven't looked at them at all. So that's great news. So all of the hyper ledger meetup groups in different locations they all belong to the high level hyper ledger org. I mean there may be one or two that are outside the org that just people set up but that's pretty minor yeah all the ones that we run are on one word. Okay, that's great news. Okay, so we can look into those as well. Let's see. There are other sources in the green. So Docker, Docker polls that's pretty straightforward and Docker.com binary downloads. Don't know if GitHub provides this but it would be a GitHub API if it's if there is one. Same for all of this. GitHub, GitHub. Okay, so I think that covers all the green items. So if we move on to the blue ones. I think the blue ones are mainly manual, manual collection. Yes, my first question is how do we feel about asking each project team to self report or do we want to have a team that the TSC designates that would be doing this for every project. In this manual collection somebody has to do some busy work to collect that data. We want to decentralize that for all the projects to do that for themselves. Assuming everybody will do it diligently and honestly, or do we want a specific team to be responsible for all projects. So one thing that I'll say is part of the reason for creating this task force if I remember correctly was the fact that we thought we could automate a lot of the project reports. We're asking a bunch of questions of the project maintainers to answer in doing the project reports are we doing, are we taking a step back right from where we're at today with the project reports. And so I just let's keep in mind that the original intention of this is to make things easier for us one to determine what this help of the project is but to to make it easier for the people who are creating the reports to not have to provide data that is you know, over and beyond something right to make the project reporting easier. Yes. Thanks for that reminder Tracy. So, I think it was just just naturally coming out of the discussion that these data sources were listed here that are at least at at the moment, not automatically. So I guess this changes the question to, do we want to just put these aside for now, until they become automatable. We can totally make that decision instead. So I based on what Tracy just reminded us I like to propose that we don't get collecting those that are not automatable. Are there any objections to that. Sure. Peter please say that I support that because I think the low hanging fruit would be all the automatable ones and then we can always iterate on the manual ones later. Thanks Peter. All right so that solves a big problem for us so we would focus on, I think these three major data sources that are API driven. I think 80% or more are between GitHub and discord. There's some behind meetup. And, Ryan and I will look start looking to maybe at least one call, or two calls to each of the platforms and create a new repository to show how those should be made. You know, the bash script or Node.js or Python programs right so people can contribute to that over time and grow this, this footprint. I think the, the red colored ones are also falling into the same category of not being automatable for now. So I think we should just also leave those behind but should we consider still creating a space for those to be reported if people would like to contribute to to that. For example, I would imagine some research. Folks would like to to say our effort has resulting the publication of these, you know, 10 different papers. For now site, for example, where would they so that they would have a place to report that what would be the right place for that kind of reporting to be done. I think it should be a long running thing. So maybe create a page on the TSC site dedicated to that. I think we could allow people to self report these custom metrics that they have, but the real question is, then how do we take that into account if, you know, if it's there. Then must be then spend time sort of processing it manually as well. Because I wouldn't mind people just collecting the data so that maybe in the future can be used. I wouldn't necessarily want to be then obligated to then do myself it myself to something with myself that would then end up being yet another manual process. So I don't want I wouldn't want that to leak into or grow itself out into more manual things. Basically, I'm just a huge proponent of automation. So I think what you're saying is definitely allow people to report, but don't necessarily have to take those into account when evaluating a project's health, because that will require making those reports. Accurate and comprehensive which would generate more manual work. If they want to call the information out for whatever else reason, it's always there in the acknowledged existence. I just don't want it to be additional manual choice. Hi everybody. I keep some of these metrics on a frameworks and tool page for each project. Let's go back to the basic one. If that helps, I continue to do this so it would be there for people to look at and get metrics from. I'll put a link in the chat right now. Hold on just a second. Oh, do I have to use discord chat. Yeah, I guess if you. Okay, no worries I'll put it in the discord chat. Yeah, if you are, if you are there. It's a great place. Great. Thanks Bobby. Okay. Let's see. So I think for me at least it's a pretty good place to end the call. I feel like we have some concrete actions to act on and we agreed on the, the types of data we'd like to collect with the automation. Right. And I will take the action and report to folks on the next call. Are there any other last minute comments or questions. If not, I give the call back to you, Tracy. All right, let's jump. So as far as I know, I haven't seen any sort of items come up yet for next week's call. But if they do, that's fine. We can get them in the agenda. But what I was thinking is that maybe we needed to use the task force discussion next week for continuing some of the security discussions since I know there's been some movement on that since the last go around. And then we'll go back and start over again with Daniel on the project gaps and just continue that way with the task force so that's my plan if anybody has any other ideas open to hearing them. Bobby. I was just wondering if the documentation task force can get on the calendar the first meeting I think it's the second of August. I'll just double check that for the, it's the fourth of August to report what we've concluded. Yeah, sounds good. So we'll do security next week, the documentation one the following week, and then start over again. If that sounds good to everybody. All right. So with that, we'll close the meeting and we will talk again next week. Thanks, Tracy. Thanks guys.