 All right, so welcome to the January 27th TSC call. As you are probably all aware, there are two things that you must abide by in joining this call. The first one is the antitrust policy notice that is displayed on the screen. And the second one is our code of conduct, which is linked in the agenda. The code of conduct basically says don't be a jerk and make sure to take into account everybody's different opinions and ideas. So, we have three announcements today. The first announcement here is one that is always on our agenda. Just a reminder to everybody that the Dev Weekly developer newsletter goes out on Friday. And if there's anything that you would like to reach the hundreds of hyperledger developers, please click on that link and leave a comment. And we'll get the information in that newsletter that goes out. The second one is, as you are probably aware from our conversation, I think it was two weeks ago, the hyperledger challenge has kicked off. And they're looking for mentors across all of the different areas within hyperledger. So if you're interested in being a mentor, there is a link there for you to click on and volunteer your time. And then the last announcement here I'm going to let Min talk us through. Yeah, thank you Tracy. So to continue the theme of mentoring here. So the Hyperledger Foundation, we're launching the 2022 mentorship program on February 1. And that starts with the call for mentors and project proposals. So you can click on that link that will take you to the Hyperledger mentorship program on the wiki page. This is actually the sixth year that we're doing this program. This is a formal mentorship program. It's part of the Linux foundation mentor mentorship initiative. And actually over the, the last five, six years we have for hyperledger we have steadily increasing the funding and the number of for this program and the number of mentors and mentees were involved in this program, have also steadily increased as well. So to give you some data points. If I look at 2021 we funded 2021 projects. More than, I think we have close to 30, some mentors involved, 22 mentees involved. Projects except one were successfully completed. And I'm hoping, you know, just from the project presentations that I heard at the end of last year, and the majority of the mentees are planning to continue I hope they're still involved in the hyperledger community. So this is a great opportunity right for to connect those who are active in the community who want to mentor who want to teach with those who want to get their foot into the hyperledger open source community. So, we're so as I mentioned, we're going to be sending out the call for mentors and project proposals next week, February 1, the project. So Tracy, if you want to click on the program timeline. Thank you. So, let's see. Yeah, so starting from February 1 through March 9 that's the project proposal time phase, and then we'll have about two weeks to review all the project proposals that we receive. And then once we approve the project proposals will put on the Linux Foundation. It's called LFX mentorship platform to accept mentee applications for six weeks. And then we'll have two weeks period for the mentors to review all the applications that came in and select the mentees that they would like to work with. The mentorship will officially start on June 1, and the mentees can participate either as a full time or part time mentee so those are the timelines for the full time program and the part time program. Actually, even on the TSC roster I know many of you actually have been involved in this program. So I hope many of you will get involved this year as well if you have time if you're interested. Yeah. And also if you have any questions I did put on the TSC agenda please contact mentorship at hyperledger.org. And I am on that alias and watching that so if you have any questions I'll respond from there. Or if you have any questions today. Yes, Daniela. Hi, I just want to let everybody know that the Min has been, you know, fantastic and amazing over the last few years running this mentorship program continues to grow it continues to support the mentors and the mentees it's really amazing. You know, looking across the Linux foundation I think the hyperledger mentee program is, you know, probably the one that is, you know, the best managed and just fantastic so hats off to men thank you so much, and that's why we continue to invest in this. And as men said this is a great opportunity for all the project leads to, you know, to put forward a proposal for work that they are doing or want to be doing to get some some assistance and more importantly to bring in new talent, new contributors and new maintainers to our community so I really encourage everyone to do that. If anybody has questions about you know what does it take to be a mentor what should I do. Please reach out to men or anybody on staff and there's also a listing on on the wiki kind of feedback that men has gathered from a lot of the other mentors over the years that would be helpful. The point is that David Boswell and rye Jones and Sean bone are going to be just looking as well at some of the project reports that have been done over the last few quarters to see if there's opportunities, just to reach out to the maintainers even if they're not on this call today and having them participate so please think through who in the community if not yourself could leverage this program. We're going to be through our member membership funds, and we want to make sure that everyone in the community can leverage it so, you know, men, I can't thank you enough I know you get a lot of kudos across the LF when we're talking about mentorship program. But I want to say this in front of the technical steering committee without your assistance over the last few years, we couldn't have had, you know, 20 projects deliver code and and hopefully new contributors to the project so thank you. Yeah, thanks for adding in additional data points and also encouraging everybody to leverage this program it's fun days who are yes membership funds and it's, it's, it's been a yeah great experience for me to just to see you know, all the contributions coming in from mentees and getting the mentors and mentees connected through this program so thank you very much and thank you Tracy as well. You're, you have always helped me with the wiki setup for this program as well so thank you. Yeah, great. Thanks man thanks Daniela any questions from in on the mentorship program. All right, so you know questions. Are there any other announcements that anybody on the call would like to make. All right, saying no hands. Nobody coming off of you, I will then move us on to the quarterly reports. So we do have three links here southeast one just showed up yesterday so I noticed this morning that not everybody has had the opportunity to review that yet. The caliper and the fabric one came in on time for us to review and I see that most of us have reviewed it. I did not see any specific questions on any of the reports, although I don't know I did see your comment about the code of conduct on the saw tooth one. But are there any questions or comments things that we should take back to the maintainers or the project report failures on these project reports. So Tracy, I actually wanted to highlight for everybody to see in case they haven't seen my comment I mean, you know, this is a case where the so to team reports they have not really implemented the common repository structure they're missing the code of conduct, the change log, you know I can see the argument they feel like they are, you know, achieving the same result in a different way, and I can give them a break on this. On the other, they, on the other hand the code of conduct I mean now it's been several months we have been, you know we have asked the groups that all the different projects to align the repository with the common repository structure we have defined. I have to admit my patience is running theme on that one. I feel like this is a very low hanging fruit, and they should make the effort and, you know, I wonder at one point we start, you know, showing a bit of like, I don't know you call this like we put a bit more pressure on the project to say come on, get your act together, please. Yeah, you know I was just thinking as you were talking, it might just be worth while to create a PR. I think that if I'm not mistaken our code of conduct just will point to the code of conduct that we have that is standard. So it might be a really easy PR for us to And the thought also crossed my mind I was like, you know, it probably wouldn't take much but at the same time I felt like, why should I do this? It's, you know, it's easy enough for them to do it. They want to be part of Hyperledger. They have to, you know, we don't ask much from the project I think this is a very small thing they ought to do. All right. Thanks. I don't know. Any other comments on any of the project reports? Hey, so, so some of the reports I keep repeatedly saying that they are looking for more maintainers to get started with their project. So, instead of taking a passive approach, I guess how about taking an active approach where we know the list of newly proposed projects on the labs. And so far our ask has been whenever a new project proposal comes in the labs, we asked them to check with one of the existing projects and see if they meet their requirements and then join them right. So on the other side, we now see many of these projects are requesting additional support. They say we don't have enough maintainers or we need more contributors. So how about we ask the projects as well to do the same thing. If we identify a new project proposal, which falls in line with those, we should probably intimate those project teams and ask them to go and have a talk to those teams who are proposing a new project. Maybe there is a potential for expanding the project scope or there could, it may all end up to be a new project altogether, but it should be more active from the project teams. If they are looking for more contributors. So, yeah, thanks, Arun. I think the comment or the suggestion is a good one. I guess the question is, are we asking the maintainers to do that? Are we asking the lab stewards to do that? Who is the ask to that we try to connect the maintainers to these lab projects or labs? So the first point of contact will still be lab stewards because they keep a close eye on new labs being proposed. However, they're not entitled to handle this throughout. For example, you being a lab steward, you identify a new project proposed and you know basically the area or the domain that falls under. You can notify somebody from the project team that, hey, here is a new project I would like you to get in touch with them. Mostly the lab stewards then. Okay. Yeah, I know. And I try very hard in the comments for the labs, right, to make those connections. But I don't think we specifically call out maintainers for the projects. We try to put that more on the labs. So we're suggesting the labs to have that conversation. But I think, you know, we won't be able to tag them, tag the maintainers and GitHub. It'll have to be a separate process because they are two different organizations. All right, any other comments on the project reports then. All right, so let's then move on to our discussion items. And just a reminder for anybody who might be talking to the areas or the indie community their reports are due next week. So the first discussion item that we have here is one that we started last week but didn't make it very far through. It really is a question around how do we encourage projects to graduate, and do we have enough benefits to offer to our projects as they work through the life cycle. I think we were having a conversation at the end of last week around two sorts of things. One, Arno had suggested that maybe instead of adding additional benefits, maybe it's removing benefits. There's a tension there because we want the incubated projects to really be successful in gathering a community, doing the work necessary to figure out how to work their way towards the incubation exit criteria so that they can graduate. And so I think that's really the two pieces that we talked about last week in our conversations. And so I want to kind of continue this conversation, see if anybody has come up with any sort of additional benefits that they might think are useful to offer to our graduated projects versus the incubated projects. And also then maybe take a look at some of the suggestions that David has provided in that wiki page as well, which I copied here to make it easier for us to reference. So let's start with the question of are there any additional benefits that anybody has come up with that we think we should offer to graduate projects. Anything that would incentivize our projects to move towards graduated heart. Thanks Tracy I think David's suggestions are really good here so like workshops, translation stuff. I think there's a lot of marketing stuff that we could probably restrict to graduated projects. Anything else that anybody thinks would be good to add as incentives. I will point out that on the notes that I put on there thank you for copying those over Tracy I did change them yesterday I had an opportunity to talk to somebody at CNCF. So if you read those earlier last week, the documentation and translation ones have been changed somewhat to provide more details about what they do so I'll just cover those really quick just so people know CNCF has a project services doc similar to what we're talking about doing and they do include translation documentation support on that. I'm curious about what that meant it was not they didn't go into a lot of details on the doc itself so I wanted to talk to somebody there they do invest funds there, and they do a range of things. Not so much documentation directly, although it sounds like they do have some staff do that to bootstrap some things a lot of it is more coordination efforts which is similar to what we did last year around the fabric translation work with the documentation kind of coordinating efforts that could be done so for example one thing they said is Google offers a season of code program and so somebody on staff can manage that and apply for that and make sure that they get into that program so that's that coordination effort is something for us to consider something else they did that I also thought was really interesting and I have a link there though they also have. Doc assessment sort of have somebody go in and review the state of a project documentation and analyze that and provide recommendations so some what you know I think giving some sort of roadmap and support and guidance to a project about what documentation. They should focus on what documentation be helpful so I think those give some more details I think my notes that initially said hey we should probably do something around documentation and translation because that's critical which I think it is but at least this is a little bit concrete and specific to see what another elements foundation project is doing so just just a flag of that I added those notes last night and people may not have seen that because. That was just a recent addition but I do think like the assessments and the coordination and organization support could be really really valuable in terms of the documentation and translation. Yeah and I will, because Bobby's not here. I'm pretty sure that the learning materials working group was also looking at trying to help the different projects with their documentation and improving those. So, I mean I definitely think improving documentation is a good thing I will. I will kind of go back to I think it was or no less no maybe it was hard last week I don't know one of the two of you said something about that tension right between helping. Projects that are incubated kind of work their way up, and I will say that this particular one for improving documentation seems like a really strong sort of thing that a lot of incubated projects might need help with right. Improving their documentation so that people can get up to speed quickly bring up their development environments whatever the case may be right. So, just for something to consider right how do we, how do we ensure that as we are trying to help our incubated projects that we're not doing them a disservice I guess in this particular regards with documentation. Sorry go ahead or no. No, I wanted to follow up I mean I sure did talk about this tension and I think this is indeed a bit of a challenge at the same time. You know, so I, as you, as you reminded everybody, I did say that maybe there's also a way which is to remove some of the benefits we already grant to incubation project and we didn't really talk so much about it. Because we then shifted to more like, oh maybe we should, you know, we seen projects to a different level, which is yet another completely different thing to do. But I do think I've looked at the set of criteria or the benefits that we have for each stage. And I do think it's an interesting. There is maybe ways we can reduce a little bit some of the benefits. And I think maybe what should be a driving factor for this is whether he, you know, it's how much it costs the organization to, to, to provide those services. I mean obviously there are things that are, you know, pretty free I mean like, you know, create a Twitter account that's like okay. We have two minutes for staff to do it. And, you know, doesn't cost anything. On the other end, if we look at, you know, training courses, I guess this is pretty expensive thing to do. The audits are also expensive, there is an actual cost. And so I think there are a few things like this we could definitely say well you know what, yeah these things are nice to have but incubation projects are not going to get this, they only get that if you graduate. The documentation improvement. I'm kind of on the edge because I agree with what you said, Tracy, it would definitely help them to have better documentation but you know maybe it's there's only so much you can offer. Yeah, I like, I like the idea of cost being a deciding factor for some of these things. David, I saw you come off me again. And I was going to say it doesn't have to be an either or situation we could provide a lower amount of support at one level and a higher amount of that sort of support at another you know it's not to say hey if this is a documentation and translation support. It's a service we give to graduated projects that doesn't mean we give nothing of that to the incubation maybe just a smaller amount, you know, maybe more of a bootstrap versus a full, you know, service that we would give to a graduated project. Yeah, makes sense. Okay, any other. Sorry, I just asked that question on the chat box as well so I was curious since we are talking about the cost implications for graduated projects and we know we do have mentorship options through Linux Foundation. I was curious if hyperledger would anyway be willing to have additional developers in case a project is willing to go into graduated state. I would say additional developer support it could be for multiple needs right for example some of those projects may want. Maybe they are going silent for a few days or maybe they're looking for additional developers to help them on a short sprint. Is there such a provision I may not be very sure if this is like DS is cool, but just curious to learn more. I know in the past. We hyperledger has been pretty clear about not paying, you know developers to work on projects. This sounds like something slightly different. Daniel. If anybody else has comments before commenting. But I do have something to say, but is anybody else have anything to say that's not on staff. So, I'll just point to a couple of things that I've seen recently in the community that you know I've also seen over the last four and a half years. There are incentives and programs. For example, I saw that the government of British Columbia just awarded a contract to in DCO in our community to do some work specific to hyperledger Indie and dids. So, you know, this is a community member right that the government of British Columbia is actually an associate member of hyperledger. They needed some some work done, you know that is to the benefit of the whole community. And that funding came directly from that government there's also some other ones happening in Europe that we continually see. And I think, you know, we need to find, you know, ways to make these types of grants, and the ways to, to, to figure out ways to fund, you know, some development work, coming out of specifically, you know, to rise point around budget so membership dollars that are brought from from our members. We have not funded any development we do fund resources like rye and Sean and others on staff to help assist. We can, you know, find creative ways to support more mentorships we just increased it by for this year, and making sure that the projects take advantage of that. So there are different ways that we can do but, you know, across the Linux Foundation, it's very limited when we do pay for work for development work. Thanks, I think that I think the mentorship piece is key right. It sounds like that's a really good way for us to, if you will fund certain development, but it does require the input from people in the community to be mentors. And so I think, you know, it wouldn't necessarily sound like we could say hey well graduated projects get priority or something like that, because it's really going to depend on who shows up to be the mentor. And just a reminder the TSC chooses who gets selected for those, you know, for the, you know, the project development projects. Maybe a follow up question or a slightly modified version of my earlier question. So let's keep aside the development aspect for us for a while. And how about the other other benefit other routine tasks that a project needs to go through and it could be along with documentation. Maybe some of the projects they are so occupied that they need somebody's help in in managing their projects in terms of organizing them. Or maybe that's an incentive that a graduated project gets like we could support them in their release management aspects. So that they completely focus on that development or the technical aspects that other aspects should would be taken care as a benefit. Is that something feasible or again that falls under the same category. I think we can take a look at that and see what is required. Yeah, I mean, I guess. Not, not to shut it down a room, but I do want to just provide some some thoughts on that. That will probably seem contrary and they're not necessarily meant to be contrary but more to start discussion. Which is that if you think about one of the things that it takes to move from incubate it to graduate it. It is that the project has figured out how to do releases. We figured out what the release process looks like they figured out how to manage that release process and go through a couple of releases before they're allowed to exit incubation. That's one of the criteria that we have. So I guess, you know, my mind says if now we're offering to graduate projects that once they figured out how to do that they don't have to do that anymore. It seems a bit wrong or contrary to to kind of why we wanted that in the incubation exit criteria in the first place. Sure. I understand your point. But if that is an opportunity I mean option open then we could definitely start looking into aspects that projects struggle with and we can incentivize them. If they graduate. If any such support is extendable apart from documentation. Maybe not. I think you're exactly right. Like, what are the, what are the things that projects are challenged with and taking a look at those might be the sort of thing that will allow us to understand what we should add to the list. I agree. Yeah, that would be great and that sort of feedback is certainly welcome. Yeah, what support is helpful. I have one, one last comment. If we just before we move on I do want to share that I do think the workshops are going to be a very big incentive at the graduated level but I know that might not seem that way because it's a new concept and we haven't really done these before I will just flag that we did the first workshop last week and Sean and I are doing some analysis we're going to do the second workshop next week so probably the week after that Sean and I will come and provide some data points about how those went but the early indications are those are very helpful both in terms of helping a project connect with people who want to use it as well as contribute to it. There's not much promotion the areas, we had to cap the areas one around 400 people expressed interest in going. The end one is just under that I think it's around 360 370 right now and again we haven't really been promoting it that much we just announced a fabric workshop so we're going to have a lot of data points to look at about do these work are they effective but the early indications are good so just to flag that I do think going forward that is going to be something that provides a lot of value. But I realized just looking at that document that might not seem that way because again it's a new concept there's no real track history to look at so to speak but we'll we'll follow up with the TSE with some data points and two weeks. Okay, just a quick those are funded. They're not volunteer because I know we've done a lot of these similar things over the years from a volunteer perspective these are funded projects. I just wanted to add the plus one to that carrot ID for helping with release management for projects as a maintainer of one of the projects who's in incubation. We already have been on the community architects mailing list asking for a bunch of help regarding release management. And I did get a lot of help as well and to me that was very very helpful and moving us towards the graduated state and if that didn't exist. And I think as a carrot, it would be good if there could be even more effect because there's a lot to that there's a lot that goes into release management just by itself. Thanks Peter for the plus one. Other thoughts or comments. So, before we move off this topic. David, any other staff members was this a useful discussion for you do we need to discuss anything further. What are your thoughts as far as next steps for this particular item. It's useful for sure I mean, getting people's feedback about the balance what's the right balance between the you know supporting incubation versus incentivizing the release management idea is something worth looking into appreciate the feedback on the docs. I mean, yeah, this was great I think we will take it and polish it and then share it back. Great. Well if anybody does come up with anything else as they're, you know, in the, in the shower or, you know, not thinking about this at all and it pops into your head. Definitely not David, you know, and I'm sure he would appreciate that input. So, then the next item that we have on our agenda is that Jim, a few weeks back had made a comment that he would make some suggestions on things that we might do to update the template of the quarterly reports. As we, you know, started this discussion, it was really around what do we do when we don't get project reports, and the concern that maybe they were to honor us to complete for some of our projects or the projects didn't see anything useful coming out of the fact that we were doing these project reports. So, you know, a few weeks back we had a couple weeks back I think we put together the list of why this is important. And this was Jim's follow up action for taking a look at the template and seeing that there's things that that might be at it. And I think at that point we were talking about how we might automate some of this stuff. And I did reach out specifically to the insights team about whether or not an API might be available for us to utilize to bring in some of the insights specifically into our project reports. We really have an API, although it is on the roadmap. So maybe, you know, as we have this conversation we can talk about the sorts of things that might be useful in an API as well as the things that people tend to look at to see if they can understand the impact of project health of projects. Jim has provided in he actually updated the last Firefly quarterly report, and he added three links at the top. Focus on these three dimensions around project health, specifically for commit activity PR activity and contributor strength. So the question to the TSC is do we think these are the right dimensions. And then I would just kind of point out that in general, these links are generic links are not related to the specific timeframe. It could also be something that we look at as we go through and try and figure out what is the information that we want to see and how do we automate these links so that people don't have to type them in every time or figure out how to put the right data in. So, yeah, are these dimensions things that people look at when they review the insights that are linked in the project reports or are there other sorts of dimensions that people that people think are more interesting or useful to have a look at. Could somebody summarize what contributor strength is. Sorry. So, that's, if we look here at what they have, it's basically it says it's the growth in the aggregate account of unique contributors during that selected time period so in this case the last three months. Anybody who's added any sort of code activity or helped in resolving bugs. So, looks like for firefly. I think this was fireflies trend for the last three months. They've had 53 as far as contributors go. Unique contributors. Peter. I like person that are interesting to me usually one of them is how the number of open issues have changed how many got closed and how many you got opened. And what is the total as of right now that that always throws an interesting trend on better. It's trending up or down in total but also which work is being done roughly. And then the other one is about timings related to pull requests. So it's not, it's a set of metrics, not just a single metric that I saw on the LFX. And the set of metrics contain how much time does it take to review pull requests. How much time does it take to merge them after they've been reviewed. And how much time did they spend in non reviewed state versus how many back and forth were during the reviews. I think I remember seeing these kind of metrics. I don't know if I'm quoting them exactly right but they don't give you the post rocks. It's basically about PR timings, which means how active to maintain your community is in making sure that if someone comes in their contribution, and they get the attention they need to actually get that through over the finish line. Yep. Yeah, so I was going to say Peter that's exactly I agree with you and it's in the technical metrics. So if you're on the trends page which I rise like moving towards some of the specific technical metrics on the screen but yeah you can see sort of all of these things like you know who's committing and what org are they from who's making PRs, what org are they from, you can sort, you know you can see like are some orgs responding to PRs and things faster than others. All of this stuff and I think it's just really good. I love these tools. I've used them to go to Fujitsu management, many times. And I think like this sort of the technical metrics page of the of the LFX insights is basically, you know, a lot of what you want to know for a quarterly report. And as Peter you're pointing out, you know, from this page we can essentially, you know, it's very easy to see whether a project is healthy or not just from looking at this page. Okay. So issue trends PR timing. You mentioned organizations in the technical metrics as well. I think that lends itself to the diversity question that we have within our current project reports. Other sorts of things that people tend to look at when they click on the insight link to see how the project's doing. If anyone else wants to drive I can stop sharing, you know, instead of my trying to do an interpretive thing if someone else wants to share and show, I'll stop sharing. Actually, I wanted to propose it. I can share some open source tool that actually also capable of analyzing the activity of the depositors in the project and actually it can also provide a very insightful information with respect to the health status of the project. If you don't point I can share the screen just to show an example because I'm recently discovered and I was looking on the fabric project but basically it can provide a lot of information with respect to, you know, the diagrams showing the activity you're going to do today. It also can can can identify the periods of very intensive contribution and the light periods of the project there are very few contribution has been done so if you don't mind I can show it. And it's worth kind of exploring to see whenever you would like to use it because again that's an open source and anyone can do it and so I just tied it to my Github account but you know, so here I took a few repositories for fabric because that's the key project I'm working with. So it has an overall overview of activity with respect to I think it's pretty pretty similar to what we have seen with our fix inside, but what it also does we can we can have an overview of on actual activity with respect to the to the commits and open issues over the period of time. And I have a drill down for example on the commits so we can we can see amount of commits and here we actually have very nice heat map diagram to see then you know what are the most most active hours a day within the project with respect in terms of contribution also analysis of diagram with you know commits by hours of the day commits by weekends. The activity across different repositories and also it has like you know we can we can take a look into the issues and see how how how. What is the period of time it takes for the different contributors spontaneous to respond to the issues. Again, we have here open heat maps for open the issue for the closed issues and the distribution of that across different repositories. Now it can also analyze the reviews, the activity of how quickly it has been done. And I believe that most importantly we can we can see here also analysis of activity with respect to the communities. Like, you know, whenever we have a healthy ground community in the very active contributors going on analysis of the of the performance. Like, I think Peter raised these questions like time to take the to closing on average the issue that was created how they how takes to close the issue with the reviews and cetera, so we can see millions and average and so on. But also it can provide with more, more details because basically the index information into the elastic search, and we can hear he see here a more in detail lies and we can actually customize anything that we would like to so we can also he see here that people evolution with respect of, you know, maintainers, the people who is actually keep keep keep maintaining the project a contributors that is basically intermediate people who is submitting some some my minority changes users observers and so on, a diversity of the community we can also see here and you know, in other things I believe that might be really useful to have this repose and also to include it as a part of the health status of the project. And again, that's an open source and anyone can just use it. I believe we can also think whenever we'd like to adopt it. Yeah, I appreciate you sharing this. I haven't seen this tool before and I have seen a lot of different sorts of tools that try to capture information. I, it seems to me like there are some certain things that people are interested in looking at with regards to project help. And that, you know, one of the things that might be useful is if we had a list of all of the sorts of things that we think would be useful that we could generate a report from either insights, you know, have some sort of you know, we work with the LF team to, to, you know, generate a particular report that we would be interested in looking at to judge the health, or, you know, however that might look, and then, again, I still think in our project reports it's useful to have the words from the actual people instead of just metrics. The metrics can sometimes not show us a full picture, but I think they do give us trends, which are important to see if, you know, the number of commits is trending towards zero that's probably a bad thing for us, right for a project. And so I think there's some, some sorts of things that we could look at there. I guess, you know, maybe, maybe it would be worthwhile to be interested in kicking off a task force related to this to come back with the specifics around the sorts of metrics that we would be interested in taking a look at. Or if, you know, there's an interest in this which there seems to be, I think a lot of people are interested in looking at these metrics to try and figure out what's happening. You know, to me it seems like maybe the best way is to kick off a task force. So a couple of things I wanted to do. First, I mean, I think we could take another look at the report template and maybe simplify it a little bit anyway. I mean, I, you know, just to try to reduce the amount of work people feel they have to do to fill out those reports. I think what I wanted to talk about is, is this, you know, you did touch on this earlier is the links that are provided in the reports. Of course the easy way is to do what Jim did believe is like, you know, you get those undated links right and what you're going to get when you click that is the, you know, the, the status at the moment you click, which, you know, a few months later it does not represent what it was when, when you publish the report. And I honestly don't know about this. I think it's a bit unfortunate if that were the case. I think there is definitely value in, you know, having a link that is specific to the time you make the report. I don't know how much trouble it is for people to change those dates when they go from one report to the other, you know. I agree with you. I think, you know, having a snapshot of what it is at the time that the report was filed. Or if we decide that we have to create some tool that will run these on a frequent basis, right, putting those into some sort of history repo whatever you want to call it that would allow us to take a look back at the different reports that were were provided. I really think that the best way for us to do this is to try and figure out some way to automate that process. Generate the links that I need. And then even if it's just a stupid web app that says generate the web links for Firefly for the last three months from this from the day I click on this right. And then copy those into the report, which I don't want to do, but you know, I just try to make something that is, it's very much like, there's a way to look back and see what's happened as the projects move forward. Hey, thanks Tracy. Yeah, I think that this sort of snapshotting is something that a lot of people might be interested in. So I think if the, if LFX does give us an API, or I mean, not just us, everyone. It would make sense if snapshotting were also included there. So maybe we could, I don't know who's point person for the LFX on all this stuff. But perhaps just reaching out and mentioning that this would be really useful would be a good thing because it's pretty you know they have some way of modifying the date internally. So it's a matter of them exposing this in an API. So I think, you know, maybe if we reach out when they do provide an API so we can actually do this then this might just be a totally new point. I actually have an email sitting in my inbox that I haven't responded to yet from somebody at the Elephant Sites group who would like to get some feedback on my request for an API. So I think maybe I should set up a call with him and have that conversation and make these sorts of suggestions. If there's any other sorts of suggestions that you think I should also include, I'm happy to take those as well and provide that in the conversation. I mean just a thought but I think pretty much I mean this is rest as far as I can tell and so everything is in the URL, you could construct the URL, and we could have, you know, a script. I don't know that you need an API versus what I'm trying to say is maybe documenting the way they build the URL would be good enough. I do. I just want to caution you that these URLs are not only perishable, and the history does change. There is a lot of work going on right now to move from what you see right now in insights to the next version of insights. So I would counsel you to not spend a bunch of time trying to reverse engineer the URLs to generate the exact reports that you want. Good to know. Thanks. Yeah. Are you saying that all the links we had already like in all the past reports are going to get broken. I know that that is not what you want to hear, but probably the, I don't have the URL off the top of my head, Tracy I think it's community dot dev or community at LFX dev or something. If you could post that or I'll look it up after the call and post it for the discourse. I would really like it if everyone on the TSC that has opinions would work directly with the insights development team, and they are paying a lot of attention to that. On our all hands call yesterday for LF. We were, you know, told to get the community involved and send them there. So I'll do that I'll give you the URL and get on discourse and let me know what you want. I, you know, I think the other piece of this obviously is right. You had sent that link into the TSC mailing list and I had responded with the specific item that I had opened there. You know, we can obviously continue the conversation there with the folks at LF insights, so that we capture everything into a single thread about what it is that we're interested in at hyper ledger. I definitely think we should continue to help the LF insights dev team to figure out what it is that will be most beneficial for us at hyper ledger. You can remind them cool URLs don't change. Yes, or they should continue to remain somewhat backward compatible right. I know it's tough. All right, so I see where we've got just a minute left. I don't want to go long like you did last week, but any, any last items anybody would like to bring up before we close the call. Yes, I forgot it during the announcement, but it's a reminder for tomorrow's task force meeting at 8am Pacific. So security task force is meeting tomorrow at 8, 8, what was it 8pm. 8am Pacific time. I'm sorry, 8am Pacific. So, feel free to join that call the link you should be able to find in the TSC calendar. And yeah, I think with that I will close the call and let you get on to your next meeting for the day. Thanks.