 All right, welcome everybody to the February 3rd Hyperledger TSE call. As you are probably all aware, there are two things that you must abide by on this call. The first one is the antitrust policy notice which is currently displayed on the screen. And the second one is our code of conduct, which is linked in the agenda. Just don't be a jerk. And everybody is welcome here and able to participate. So welcome to our guests that I see on the call who are not TSE members. You are also welcome to participate and provide your thoughts and feedback as well. So we have two announcements or two official announcements. Maybe some other announcements will come out of this, but the first one is one that we see every week. The Dev Weekly developer newsletter goes out each Friday. If you have anything related to your project, your SIG, your working group, anything that's going on in the community that you think would be of interest to our Hyperledger developers, please consider clicking on that link there and adding a comment on the Wiki page. To be included in that newsletter. The second one. Last week, Min talked about the 2022 mentorship program. The call for mentors and projects has been initiated as of February 1, I think it was. So if you have a project proposal that you would like to consider having brought to the TSE for consideration, please submit a project proposal. There is timeline information that's available for you to take a look at as well as different guidelines for you, or submitting the proposal. Really great program, obviously been very successful in the past year so please consider doing that I have seen a few chats going on in our chats with different projects, considering already what sort of projects they'd like to bring forth so that's really good news. So those are the official announcements. I'd like to see if there's anybody on the call who has an announcement that they would like to make to the TSE. All right, seeing no hands, seeing nobody coming off mute. I will take that as a no. We do have two quarterly reports that have been submitted. The Explorer report has been submitted from last year. So please have a look at that I saw this morning I think there were only five people who've had a chance to look at that so far. So please go ahead and take a look at that. The soft tooth report came in last week but it came in I think on Wednesday so I left it on the, the list for this week, in case any sort of questions came up. I just have to know whether or not anybody has any questions about Explorer or soft tooth. Any sort of discussion we would like to have related to those reports. All right, again, seeing no hands, seeing nobody come off mute. I'm going to take that as no. I will note, for those of you who have not looked at the Explorer report yet. I did mention that they are struggling with project health and are looking for more people to come in and contribute to that project. And I saw David I think you had commented about ways that they might work with you to get more contributors involved. So much appreciated there for that call out. I just wanted to let everyone know, you know, as this is a project we have reached out to the original contributing company, who has said that they would like to assist as well so we'll be putting a plan together to bring that back to the Explorer project. Okay, thanks Daniela. All right. So in that we have areas in Indy that we're looking to get project reports from. We're also looking next week for the Roja report to come in. I did include borough on the list, even though it's dormant. I think, you know, some of our discussion here today. Around what we will do with dormant projects is maybe a interesting conversation. And, but I do think it's worthwhile to for us to remember that these dormant projects still are on the calendar for providing TSE project updates. All right, so let's get into the meat of the meeting and let's talk about first the project lifecycle discussion. There's two items here that I want to talk about. That I think Rai you brought up to us, which I think are good discussions to have as a TSE. So let's start with the deprecated versus end of life for Avalon. I think if you look at our project lifecycle, you will see that deprecated projects are projects that are expecting to have people maintaining that for at least another six months. And as we all know, Avalon has stopped supporting that. And maybe almost a year ago. So I think that the question here is, should we have sent Avalon directly to end of life, instead of putting it through the deprecated stage first, and then waiting six months before we end up like it. So one of my questions is where we get that was stopped working on over a year ago because the Q2 and Q1 Hyperledger Avalon reports. The first words on project health for Avalon is healthy. I mean, why should we not believe maintainers and they submit a report like that. And the Q2 was submitted in June. So the earliest that things could have not been functional I would say is June because they claim it was healthy. So, you know, to operate is that they've been non functional since March, you know, we don't have eyes in there to say otherwise it's based off of Intel's pulling out that the other non Intel contributors were saying, we're going to make a go for it and then they decided in the end not to I don't know if there's a confusion sort of that. Yeah, it is a good question about the health, I guess, of Avalon, right. If we look at kind of the statistics. I guess they've had three contributors in the past year. They've been on the computer in the last month as of February 1. I'm sorry, the last six months as of February 1. So I think that's maybe where the year is coming from is just a small number of commits that have been happening. But yes, you're exactly right. The project is telling us they're all good. We cannot do anything to help them or to expect that those are different. And I think that's maybe part of our second discussion is to really talk about how do we get analytics and information that will help us understand the state of projects other than the project reports. When I said this earlier, I will admit that I was looking primarily at commit history. And PR comments, stuff like that activity in GitHub. I did not look at the quarterly reports. So my assertion around the end of activity could very well be wrong. Perhaps they were active in some other form. Other thoughts on this particular topic. We okay with having a project that's in deprecated state that is not getting any support whatsoever. I mean Tracy I totally agree with you that by the definition avalanche be end of life and not deprecated. Yeah, I mean I think that's the key here right is just looking at what we've written in the past for a project lifecycle. And I think the other piece of this is that, according to the the graph at the top we can go directly from incubate it to end of life. There's there's nothing that says we have to go through a deprecated phase first. Any other thoughts on this. So anybody who's against moving this to end of life. I don't know I saw you came up with it. Yeah, so I'm not against it I just, you know, to do in some ways I feel like yeah okay. There's not much harm in keeping it where it is now for a bit longer but you know it if anything it, you know it provides an opportunity for anybody else to come back and say hey, no I want to resurrect it. I think the likelihood in practice is very low. So I'm fine. I would just point out that this is a case where it's more important to be patient that it is to be correct. Just like Arnold said, there's no harm in it being where it is now. We feel like we need to move it. I don't think there's any harm in that either. But I also don't think we have to be in a hurry to do it necessarily as long as we don't forget to do it. Yeah, definitely, somebody needs to put a reminder on your calendar for six months from now. I suppose what one reason to move it would be if we were in a situation where there are people actually using it and they have problems they raise issues and nobody is there to respond to any of this right. Then it becomes really a problem and, and you know, we are better off signaling to the community, don't expect any maintenance, and I think you have to go to end of life for that. You know, otherwise, it doesn't seem to be the case right now. So either way. Yeah, I did just open up the GitHub issues. The last issue that was reported was on November 16 2021, the one prior to that July 22 2021. And there's 42 issues total that are open. There are actually 22 pull requests that are also open. The last one being from October 29 of 2021. And a number of pull requests from before them. So, you know, I, I guess there are people still looking at this as at least as of November, if they're opening issues against it. But, you know, I don't know that it's like an issue every day or something like that. Yeah, no, but I think it's, I'm glad you actually thought about looking into it because that actually is, you know, puts us in that situation that I would be worried about where people expect more than they should. Because we actually know nobody's going to deal with those beyond an issue. So then we are better off moving it sooner rather than better, so that the community knows they can't expect anything to happen. Right. So I think you were first as far as raising hand. The skill that exists to kind of release if it's being maintained right now, I mean, maintained by the community implies that if there's a critical bug fix that someone could patch it and push it out if it was critical. Right. So that the what you just touched on was my whole interest, the whole reason that this this, you know, came to me to that we need to deal with this was that there were a bunch of issues that were opened and unaddressed. The details are the previous maintainers were pretty clear that they're not going to do anything about it. They don't have the time or the focus on that project. There were a bunch of PRs that hadn't been, you know, looked at at all. And it feels like a dead end for contributions. So I just the signaling of, you know, hey, here's the thing that you might be able to use when in fact, you know, the, the development effort has moved on to the CCC. I just think it's, it's, it's poor form. But that was, that was my primary interest in it was not having a dead end to contributors. Sure. So I probably wanted to just read, I mean, read through the deprecated states, right. So we are claiming that project, even though it's deprecated, we still have support from the community for at least six months from then. And the support could mean, I guess we haven't defined what the support should be. But if we are not getting that, then I'm in favor of moving away from deprecated. And if I may add to this, I mean, the composer project, right, went through this phase, but we had people still committed to, you know, dealing with this kind of PRs and issues. And they say we're not going to make any further development don't expect any movement but you know we're here still. And so that is a different situation here if we really have people, you know, nobody is going to respond to any of those, then I think we were doing a deserve this service to the community by keeping it in the current stage, the state. So that has now convinced me that the right thing is to actually move it to end of life ASAPs. Yeah, and I think that's what I was calling out specifically thinking when I brought this up, reading through the deprecated it does say a deprecated project will be maintained for a six month period by its community, after which it will be removed from any subsequent formal releases. I think that's the, to me that's the key, right that it will be maintained for six months and I know that it's not going to be maintained for six months at this point, based on the discussions that we've had. Okay. So I'll ask again, now, after this discussion does anybody have a problem if we move this to end of life. He came off. I was just going to make a motion. Okay, yeah. All right, I'm going to second it. Right. You just want to run us through a game. Sure thing. I will. I'll pick by the length of your name in unit now. Troy. Sorry, the motion is to move the Avalon project to end of life, correct. That's correct. Troy, how do you vote. Yes, Tracy. Yes, Peter. Yes, Nathan. Yes, Kamlesh. Yes. Jim is not here heart. Yes. Grace. Yes. David. Yes. Yes. Bobby. Yes. Arun. Yes. Artem is not here are no. Yes. Yes. Yes. Well, the motion passes. Everyone for that. I didn't know we were actually going to have a decision on that, but I'm glad that we did. So. A room question. Right. I still want to keep one question open that we should have identified the project. I would like to move that into. Okay. We are talking about two different projects that we are into down, and probably that's an area to focus on in project reports. I guess there is also a discussion that. That's currently happening by between Daniel and heart on the chat channel as well on the same topic. Okay. I haven't been paying attention to the channel. So. and what do we do with projects who are not reporting is still an open issue in our backlog. I think we hadn't necessarily come to any sort of decision or direction on that other than to maybe take a step back for a moment and think some more about it before we made any radical decisions. Patience I guess as Nathan says is kind of the direction that we were going to take where the time being but I do think it's an important sort of discussion for us to have. As long as you know and I guess the that follows on to this question of the second question that I have related to the project lifecycle that Rye brought to us which is once a project moves to dormant how long should it stay there before we consider moving it to deprecated slash end-of-life type state because I think that the challenge that we have right now and one of the reasons that I did leave borough on the upcoming reports even though it's dormant is that if a project truly is dormant and nobody's looking at it it's hard to know what we should do with it. Do we ever plan on coming out of that dormant state or is it really that the project kind of went to an end-of-life state and is using dormant as a way of getting around the end-of-life state not necessarily on purpose but because it seemed to make sense at the time and then it just never comes back up around to to have a further discussion. So Hart. Yeah thanks Tracy so I think the ideal way to use dormant state is to say something like okay you know we're shutting down this project we know many of you you know we know there are a lot of external dependencies on this project right you know now's the time to switch to find something to switch to right to either like take the parts of the code you need to incorporate them into your project or to move to a different project right so I don't know that we want to define the the amount of time a project should be in the dormant state because in sort of the like right way that this plays out it the the dormant state is is dependent on sort of how long the maintainers of the project in the dormant state are willing to push critical fixes and how long it takes people that are dependent on the dormant project to to move and eliminate dependencies on the dormant project. One of the nice things we have about Avalon is that there don't appear to be a lot of systems at least production systems or high value things that depend on Avalon so it's not a huge deal if production stops but if if sort of sort of if work stopped on you know some of the more popular projects in Hyperledger I think it would be a much more tricky conversation. I hope that made sense. Yeah and just a down before I call on you just to comment on that quickly um one of the one of the projects we have two projects in dormant state right now one is Quilt and one is Burl. If you look at the project reports um not the the TSE quarterly reports but the project reports that Ry has provided for us you can see that there has been zero commits in the last six months and only one in the last year um and so you know at what point do we say like Quilt maintainers even though you went away how do you come back to us and tell us what what's going on right there's there's no way to revisit that I don't think at this point you know. So I've given the difference between um the dormant state and the deprecated state is that dormant is kind of a reversible deprecation and it's you know the the project's saying we may come back and by the way maintainers want it if someone wants to take it over please take it over that would be an option but when I see deprecated you know I see this is a project that will be coming back and it's you know it's not just you know it's suggesting that you find things to get off it's like practically requirement you need to get off because it's it's going to end and so I've viewed you know the deprecated as a one way and dormant is a two way if you know they can fix their governance or if it's um commitment issue if they can get out of the time that they need to to commit to it properly or if someone else wants to come in and um provide assistance so that's when I see these two I that's the two things that run through my mind as far as the way it's set up so that may figure into our decision on when we move it's a deprecated ol for the dormant if like nobody's stepping up um after you know rather than a fixed period if we could you know at some point but they do need to get out of dormant they can't stay there perpetually right Nathan I think it's important for us to emphasize that it's not healthy for them to stay in a perpetually if they insisted that it was the right place for them to be and they're still active active enough to respond to our questions about them still being in dormant in a way that's helpful to them I don't know that we actually have an abuse problem there be so long as they're still active enough that dormant is true um and then it's a review step for us to make sure as the TSC that you know we're helping them either leave dormant or or come to that conclusion that they need to finally let go um a lot of these states are self-fulfilling prophecies in some ways meaning you know if they're dormant people who might contribute or might help come and say oh but this is dormant and I'm not really prepared to take on the whole project I'm going to move on and it creates critical mass elsewhere um and part of what we want to with telling the truth in these states is that the critical mass can stay at hyper ledger in one way or another to help our overall development of our mission so um if being dormant helps them to do that then I think we would rather keep a project dormant than just you know dismiss the maintainers wishes um so I think it we need to be careful we don't make the states so rigid that we we are shoving the maintainers along to say you've got to be here or you've got to be there I think we we always wanted this project status to be a tool to help the maintainers to get the things that they need most and um if borough stays in dormant for much longer what they need most is probably to move on from dormant and that's a conversation we'll want to have with them as we bring up the status and in our regular cadence yeah I I think that we don't necessarily have that regular cadence uh because I don't think we've made it clear for the projects quilts in borough and during the dormant state what the responsibilities actually are um and I think that's my biggest concern at this point Arno so I just wanted to share I mean I actually attended the era uh community call it was part of you know uh fulfilling my duty as a member that I need to check on other projects so I did it before the end of the month yeah you can you can tap me on the back uh no but so the thing is it was actually interesting because they were talking about the fact that they are actually using borough and they were not aware that borough has actually moved out of you know incubation state into dormant so I informed them of that and I said you probably need to figure out what that means for you and I imagine one possibility is for them to say okay we're going to take over the part that we use right and so I don't know what that means exactly in terms of the question at hand but I wanted to share this because this is not something that we have faced before where there's a project that's moving out of you know uh active status so to speak and and there are actually dependencies so it's going to impact other projects in this case you know Iroha uses it and they would be shocked they were like oh thanks for telling us yeah that's um that's interesting right because I think it goes the opposite way too which is did people did other people know that Iroha was using um borough right like Iroha didn't know that borough went to dormant but did people know that Iroha was using borough until you said that I don't know I didn't know that um so I didn't know either I think there's a lot of dependencies maybe out there that we we are not aware of that we probably should be aware of as we as we go through and and think about this so and in passing just to highlight it shows the fact that I didn't know you didn't know you know it shows the value of actually you know having a look at what's going on in these other projects just like we have decided yes gold star for Arno uh I thought it was actually interesting um then oh your hand is still up I don't know if that's because you have something or if it just hasn't gone down yet okay thank you um same for you Arno your hand is still up um so yeah I to me I think the the key here right is how do we how do we involve um with the projects that have gone dormant to ensure that we understand what state actually makes sense for them um and I don't think we've run across this yet uh I think we had this quilt has a project update that was it came due I think we ended up removing it from the agenda because we were like well it's dormant we probably won't expect an update from them so we removed it I guess my question is should we have done that or should we have tried to reach out to the the quilt folks to see kind of what their state is um and obviously this question is going to come up for borough I think borough obviously just let us know about that so maybe it's not as critical with borough at this point to have that follow-up conversation of hey are you still in dormant or does it make sense to think about a different state but I'd like to make sure that we we are having those follow-up conversations with the the maintainers of the projects that are in dormant Peter what if we uh decided on one member of the TSC being a liaison and something like this happens it wouldn't be always the same person but someone could volunteer and then uh when something like this comes up when a project uh starts struggling then we would assign somebody to to have an open communication channel with them so that they are in the know as it happens and then uh you're not just uh sort of trying to piece together the picture based on the quarter reports themselves and then with the last commit that was the last issue because ultimately if sorry I think it makes a huge difference of what they say and what they believe there's a huge difference because maybe there hasn't been a commit for six months but if they say yeah we were out for six months but now we're back full swing that's very different from them saying yeah we were out for six months and honestly uh we feel like this is how it's going to be from now on yeah I like I like the idea peter of uh you know do we want to assign liaison student projects that seem like they're struggling projects that have gone into dormant um which would like the question of should we be assigning a liaison for the explorer group um you know to work with obviously the staff that's doing a lot of work already around that um but also with the the folks who are currently listed as maintainers of the explorer project heart thanks tracy um I also don't know that we need to you know it may not be the case that sort of going to through dormant maybe default my view on this is sort of that dormant is the route for projects that sort of want to have a planned or graceful obsolescence and if you know the maintainers just sort of disappear we can just go ahead and move the project to end of life um because that's more indicative of the fact that the project isn't going to be supported at all yeah I just I decided I maybe when you said that it would be good to read what dormant state was when we decided to introduce the state um so projects in the dormant state are ones in which normal functions are suspended or slowed down for a period of time the tsc will make decision whether a project will move to or from dormant state upon request if dormant projects become reactivated they will reenter incubation even if they enter dormant from the graduated state we don't really say what happens when they're not going to be reactivated right or what that period of time is that we expect them to to be slowed down or suspended and I think you know maybe that's a that was bad on us to not be very clear about that um but I do think now that we have the examples maybe it's it's time for us to revisit kind of what what that period of time is that we expect things to be dormant so that we can then make better decisions about what to do with these projects right um so yeah I I think maybe there's some work that we can do around this particular state as well as uh having discussions with both the the borough and the quilt folks to see kind of what their expectations are for the dormant state so if I may the I don't think we should have a like hard limit saying you know after six months if a project in dormant state we move them uh to deprecated the end of life uh what we could say is as a kind of you know we could have a policy that says you know after six months we will have we will check on the status and that would imply to me that we are somebody at least you know as a communication with the maintainers of the project say hey what's the status should we still keep that in dormant state do you still think you will come back or should we move it and then in the case where nobody answers well that's an answer in and of itself we can make a decision based on that but if you know we I I think there is some there is some value in keeping it flexible because we might have somebody who has a very specific thing where they say hey for the next three months we are busy on something else but we'll be back for sure and we should allow that and and so I think you know I wouldn't favor having a hard limit in built into this I do think we should have a policy that says after some time you know some amount of uh months we we make the point of reaching out to the maintainer and check on the status yeah I agree I know and I think everybody at least from what I've heard is probably in agreement with that as well I didn't hear anybody say like I know we should be shutting these guys down right now right I do think though that as a next step for this discussion it probably is important for us to reach out to the quilts folks and find out kind of where they're at just make sure they're they're still you know good with dormant that they expect to still come back and spend some time on this or or what the right next steps are for them okay any other thoughts on this topic I think you know I can take the action item to reach out to quilt and find out what's going on with their project and hopefully report back all right seeing no hands I will move us on to the next section which are these project reports that I'd like to thank rye for taking the time to provide a github action to run the hyperledger community management tools project reports code so yeah definitely let's take a look at these these project reports rye and I think the the question that I have really is do we find the information in this these sorts of reports useful do we want to run these on a regular basis such that we can have additional information in addition to the quarterly reports that the projects are providing to us or you know are these something that we don't think are really that useful for us still building right yeah I know I'm I have a copy of it on my machine I'm just trying to find where exactly I dropped the thing while you're looking for that June your hand is up yeah thanks Tracy just trying to understand the the reports they are based on the insights dimensions is that correct just making that static uh so not really um so what they are are they use the github apis to provide to pull information specifically from github about the contributions that have been made to a particular project in this case the the one that's being shown is a hyperledger areas report looking at a number of different sorts of things around the project such as the total contributors for the life of the project the contributors that have existed for the past year the number of active contributors which are contributors in them who made at least one contribution in the past six months how many obviously like it's 259 minus 81 I hope is 178 those are the interactive contributors the new contributors are contributors who made their first contribution in the past month so in the case of areas there was one new contributor this past month repeat contributors people have had more than one contribution for the life of the project core contributors are those who have contributed 80 percent of the code um so there's actually 28 core contributors or 10 percent of the total contributors who have contributed the 80 percent of the code uh regular contributors are those who contribute 95 percent of the code obviously those are the core contributors plus some additional folks then you've got the casual contributors um which I don't know what the the footnote says but uh those are people who um number six the regular contributors have contributed 95 I'm sorry casual contributors must be the five percent the other five percent um and then just some some information that takes those numbers and divides them apart to try and figure out you know what the retention rate of contributors is the level of engagements being um you know how many people have done repeat contributions and then just the specific details behind each of those kind of numbers that summary so you know if you look at this for areas areas looks pretty healthy right they've got 81 active contributors in the last six months um they're still getting new contributors they have uh you know not out of all of their contributors only 10 percent of four contributors which seems pretty good because that means um there's like maybe it would be helpful if it was a higher number I don't know but I think you know the question here is how useful do we think this is to help us understand kind of the health of the project versus um if you were to look at say uh the quote one it says the contributors in the past year was three and the um no wait that was the that was the Avalon one um so the quote one says contributors in the past year one active contributors in the last six months zero right that's I think the the sort of thing that we're uh looking at here is just to try and figure out with numbers kind of the health of the project do we think the project reports are leading us astray um that the the maintainers are providing us that sort of thing that helped you yeah that helps a lot thanks Tracy I think this is a very useful dimension in terms of the contributors whether they're growing maintaining or dropping for a project that's sort of has been established so we know you know are they maintaining their their act in this but for new projects that are still trying to grow there are contributors I think this can be quite misleading so I wonder where I'm thinking a new project is very actively in commits but not necessarily in growing the contributors because you know it's it's still the core contributors that can understand the architecture it's hard for for new people to to jump in just yet so I wonder if we can also do PR and commit based that I think can better reflect new projects I have all the projects I have I have all the projects reports now the the current ones which which one do you want me to bring up uh I wonder if we look at for example uh bevel or uh farfly the two newest ones we may see yeah so I think what this says is um new contributors and so I don't know how to interpret this but it doesn't reflect that there there are a hundred commits going on every week you know stuff like that how active the project is even though the number of contributors is not growing necessarily yes I think uh Jim any sort of github APIs that are available could be included in this report as far yeah yeah we commit or prs or issues or things like that right like I think we can definitely include those it's not uh it's not a major issue um this is this code that's generating these reports is open source it's a it's part of the labs um so if we decide that you know there's anything that we want to add we can definitely add to that that'd be great any other thoughts on these project reports do we find them useful are they something that we'd like to you know see scheduled on a monthly basis so we can take a look at them uh offline not necessarily in the tc call but definitely offline just to see what's going on with projects and see if there's anything that uh is stepping out or jumping out at us heart hey tracy so I know the the cncf has like a really nice sort of like update summary template um which has a lot of nice contributor statistics I'm not sure that monthly is the right time period to look at things uh just because um there's so much flux flux just based on the month of the year like I'm sure you know December contributions are going to be much much much lower than other months or things like that so it might be hard to read you know just monthly data if that makes sense yeah yep and we can consider doesn't make sense to run them on a quarterly basis to get um the information or even run them uh right before the project update is due to us um you know these are all sorts of things that we could discuss Angela yep thank you uh tracy I think in the same line of what a heart said would we would be possible to have a plot of the evolution of the projects over time instead of having a snapshot of the a single month because that would tell us about trends so if it's growing overall you know we don't look at the peaks we just look at the trends which what we care about I guess yep uh and I think you know the yeah insights tells us some of that I think um maybe we can pull you know some of this information into uh our project updates as well uh peter I also think it's a good idea as long as it's definitely fully automated so that no one has to prepare this report regularly by hand and then the second part of what I wanted to say is that they could have additional metrics in there not 100% sure yet which ones but they could come with metrics that would serve as early indicators of dormancy and I'm not saying that we should uh put projects in dormancy based on the metrics I'm just saying that this could also feed into that liaison appointment idea that I had if we see that the numbers are going down or have gone down like we could catch that hey on this project has been no commits for the past three months we need to appoint an liaison and send them over to the project and talk to them about what's happening yep definitely on the 100% automated don't want to manual have to do this as well so and I think that's you know some of the challenge that we have with the insights right now is that it is a manual process for somebody to go find the link and you know even if we were to try and copy this stuff from insights it's still manual process to copy so I definitely want to go with the how can we automate what it is and yeah there's specific trends that people know about that will lend itself to hey something is starting to shift with this project and maybe we need to take a closer look I think those are things that you know let's bring up and let's try and get them out here so we can take a look oh no yeah I just wanted to have a word of caution here I mean we don't want to go down the route of reinventing insights either right I mean I'm sure agree the trend would be nice a graphic to show it would be nice but you know it's a slippery slope before you know everybody's going to say oh I would like this dimension you know and what about this and that and then we are basically reinventing insights let's be careful not to go too far yeah yeah definitely agree I know we don't want to recreate the wheel there are so many tools out there right now that provide you with graphs and charts of the wave in which the open source stuff work I think it was Artem who shared even a new tool that I hadn't seen before what was it last week a couple weeks ago so 100 percent agree I don't know Bobby yes thank you Tracy I just wanted to point out that the learning materials working group captures this information for each one of the projects and tools every time the quarterly report comes out I just put a link in the chat for an example for firefly but under resources in the learning materials working group all this information is captured by us so just to let you know it's there I wanted to give everyone that's not aware of the context some some context here this is a tool that you know Tracy wrote like I don't know 10 years ago and we didn't have insights at that time you know this this this predates uh a lot of the tools so you know it's uh pull requests would be great but I also agree we shouldn't try to reinvent insights so yeah yeah definitely not 10 years ago uh but I mean you know I can't tell you how long ago it was um it's been a while it was when I was part of the hyperledger staff trying to figure out kind of understanding our projects and that sort of thing it just never never took off we I think we were trying to create insights at that point I felt like Brian wanted to really understand things so um yeah uh anyway I I think this is something that you know if we find it useful great if we don't find it useful that's fine too you know it's out there we can use it if we if we decide but that's what we want to do uh okay um so I know we only have four minutes left um you know we can continue kind of trying to figure out if there's specific metrics that might make sense to to help us understand projects and where they're at I um I think that I saw yeah it looks like Rahul has dropped in I'm sorry about that Arun for not catching your chat on that sooner um we can definitely have Rahul come maybe at the next TSC call and and have a conversation about kind of the the challenges that he's seeing with uh working with other other projects other communities in my next foundation all right any yeah okay thanks Arun um any any other comments or thoughts before we close out the meeting for today? Hey Tracy this is Grace. Hi Grace uh just a um I wanted to give a quick update on the discord proposal is now a good time? Sure uh yeah cool okay um just for everyone's awareness I'm going to send a note out to the TSC email the task force for the community chat uh a group has put together a proposal for this group's review so just wanted to give everyone a heads up that's going to be sent out um today and then hoping we can have a conversation at next week's TSC meeting so just look look out for it in your email great thanks Grace we'll definitely include that on the agenda for next week uh Jim yeah thanks Tracy just a quick question uh what would be a the best place to like create a issue to track uh to track all the stuff that we've been talking about for the for the data so yeah we can probably add it to the TSC um repo as an issue okay okay thanks start to capture that Jim did you want to um speaking of task forces did you think it was useful to have a task force to try and figure this out as a separate sort of group? Yeah I feel like there there are a few a few clear directions that we we can go into directly uh so maybe we can self organize and see if a task force uh specific task forces is needed maybe we can start with a get up issue and and see if we can organize there I'm happy to to help um help you guys you know talking with um the inside team to see if they can do the enhancement we asked for something that came to mind as well is doing exports to images um through apis so things can more automated so stuff like that I think we can we can put into the issue and then track it there uh at the moment don't know if we need a task force uh right now okay let's start with the issue and um you know we can make sure that people are adding comments to that yeah post the link out to it yeah if it's not working out maybe we can uh we need to have meetings and get people to go attend meetings with as a task force we'll see sounds good sounds good thanks all right so with that I'm gonna close the the meeting for this week thank you all for the discussion I think there's a lot of good things that are coming out and I think we just have to follow up on uh some of these things and take them over the finish line okay thanks all good bye thank you thanks everybody you guys goodbye