 Yep. Thank you for doing that. There it is. Not about it. Taking note of who is attending. I saw Tracy around. She's in fact sharing your screen. Thank you. There you go. Perfect. All right. Welcome everyone. Let's get started. This is the. Weekly TSE call. As you all know, we are governed by the antitrust policy. The notice of which is currently displayed. Thank you. So after several calls being hijacked by the urgency we had in front of us of dealing with the. Firefly project proposal. I am happy to now resume a more normal kind of agenda. And try to tackle some of the issues that we have. On the backlog. So first let's start with the announcements. So of course we have the weekly. Developer newsletter. I hope everybody remembers. Please do try to consider this and see if there are. Any questions. Any comments. Any comments, any comments? Any comments for you to contribute content. Try. David, I think you added the maintainer orientation call. Yeah. So just as a note next week after this call, we will be having a call where maintainers are welcome to come and ask any questions. We'll also be sharing some resources. Sorry about my dog. I'm not sure if you're familiar with this. I'm just going to connect with new contributors. We did this a few months ago where we talked about metrics. And it sounded like there was interest in doing this again on a semi regular basis. So maybe once in order, we'll do a. Orientation call for maintainers. So if that's of interest, please feel free to join us next week. All right. Thank you. Is there any other announcements anyone wants to make? All right. If not. Let's carry on. I'm sorry. Hi, everybody. I'm just going to go through some reports. Hyperledger Explorer came in last week. And it is. There were some. So the main question that was. That came up was the fact that they asked, you know, what would it take for us to get out of incubation. Into active slash graduated. Status. So Tracy responded kindly. She did raise the question as to whether they should reuse the previous. Request. And she favored the creating a new page, which I agreed to. So this is all kind of. Background process happening. I remember the other challenge with the. Executory, especially with regard to diversity. I don't know if it's any better now, but I'm happy for them to take a crack at it. I don't know how they feel like. They could qualify. Is there any questions? Other ways or comments. Nope. All right. And then we're waiting for the Avalon report. And I saw. Kind of snuck in the report for Ursa. At the late hour. Hi. So I don't know how many people actually had a chance to go through this yet. But it's okay. If you have any questions now, please. Welcome to raise them. Heart is here. So is the author of the report. We can definitely pound them with questions. But otherwise. I will. Yeah. So there's only a few people with a chance to look at it. So I will. I will put that back on the agenda for next week so that people have a chance to look at it. So if there's any questions. Is there anything you wanted to bring up? Hot or is it the usual? Hey, we're happy to work with other people. I don't think there's anything too exciting. That we mentioned in the quarterly report. So if people have questions, I'd obviously be happy to answer them, but otherwise I don't think there's a lot to discuss. All right. Thanks. So that then brings us to the discussion part of the agenda. So first, I wanted us to talk about the project quilt because. So they reported they would go dormant. And as in reaction, we created the dormant state that we added to the project life cycle, but we haven't officially moved quilt to dormant. So I think we need to make a decision quickly to just say, yes, okay, we're moving quilt to dormant state. All right. Thank you. I think we can go quick on that one. So I'm happy to do. Yeah. I do have a question now. Sorry. Having problems with sharing and. Doing everything else. So my question is. Have we contacted quilt because I know they asked for this. We added the state after they asked, but I don't think we ever necessarily got back to them. But this was now going to be a state that was available. So I just want to make sure that they aren't surprised. Like, oh, I didn't know this all happened and. You know, have some sort of comment about it. But that's my only question. So I guess the answer is no, I don't think we have. And I think it is an interesting point. I did cross my mind. So I'm glad you, you remember it. I had forgotten about that step, but I don't know. I guess there is two ways we can just check with them or go ahead, do it. We can make the decision and then just say. I don't know. I don't know. I don't know. I think since the woman state, right, allows them to resume activity any point. There is no damage done. So I think we can inform them that in reaction to their request, we responded by adding a dormant state and move quilt to that state. And if the situation changes, just let us know. That would be my, my take on this. Yeah. I guess there are a few more questions that at least I'm not very can, I mean, well, there are about, for example, one thing that comes up is let's say when we move this project to dormant state, one of the discussion point that we probably missed last time is how do we bring it back into incubation, right? And when we bring it back into incubation, is it going to be the same maintainers or if what if somebody else planned to adopt this project? And how do we provision that? Because this is now coming back from dormant state. And if we mandate that it's the same set of maintenance, they have to come back after some time. Then we need a way to, I mean, keep them updated or keep track of them. So these are some of the questions that comes associated with it. All right. Sounds like a bunch of good questions. Oh wait, Daniel, you had your hand up. My question was the exact same one. Now that we have a real use case, I read the dormant page, the TSA decides to move it out. But what are our expectations? Can it be the same maintainers? Can it be new maintainers? What if new maintainers want to come in and the old maintainers don't? What if they're the power struggle? How do we handle that? What's our plan ahead of time? Or do we just want to figure it out when someone wants to do it and make the call at the moment based on the fact to hand? Nathan. I would propose that we can figure that out after we move to resolve this. It feels like moving it to the dormant state is in the spirit of what the maintainers have requested themselves. And we should follow up with them on what we decided and invite them to the discussion on what would happen if they proposed it to back as a project, which I would expect it would follow just the same process that any new project proposal would follow. And if the maintainer said it's different, he would expect them to call out on their proposal. All right. Thank you. Any other opinions? Halt. I agree with Nathan. I think the only question though is, what do we do if we get like a, maybe we don't even have to worry about this, but if we get a hostile resurrection. Basically where somebody attempts to resurrect the project and the original maintainers aren't okay with that. I think that's probably not a super likely thing. And I think we should probably go ahead and move the project to dormant state because it's what the maintainers wanted. But it just might be something to consider. No, go ahead. I think if the maintainers wanted dead, they should have proposed it to go to deprecated. And I'm also comfortable with making the call when it happens. I don't think we can predict everything that will go right or everything that will go wrong. So I'm comfortable saying let's figure it out when someone wants to come out. Okay. So at one point, I do think that. Although we haven't defined the process per se to, to move out of dormant. It's clear to me and maybe it should be documented, but you know, that is going to take a decision from the TSE. And so I agree with what was said that I would expect us to, you know, look at the situation there. At that moment. Yeah. So thanks for pointing to the documentation we have. So I think, I think it's, yeah, we'll move to or from the dormant state. So it's clearly marked that it written that TSE will make the decision. So I think, you know, it would be surprising, but if somebody else came up and say, Hey, I want to, you know, get that project of dormant state, I would imagine we would say, wait, who are you? And we would check with the previous maintainers to see if they're okay with this and all that, right? And we do, do, do, do. Oh, sorry. You diligence at that moment. I don't think we would accidentally give away the project to somebody else if that were ever to happen. So I don't think we have to be too worried about these cases. I think we, we are the gatekeeper and we can, you know, ensure that nothing bad happens. At that, at that time. So, so I'll, I'll reiterate my emotion then that we are moving quill to dormant and we'll inform the, the, the. The maintainer and let them know that, you know, when they want to move out of dormant, they should come back to the TSE to make the request. And that's it. And, you know, the likelihood is they would just come back say, Hey, just like I told you, you know, I was out for a while, but now I'm back, you know, please get reactivated. And we would just move back to incubation in not much of a process. And that would be it. Are we okay with that? I second. Thank you. So let's do a quick vote. We're not going to do a roll call for that, but we can do a. Okay. Everybody in favor says hi. Hi. Hi. Anybody wants to abstain. Anybody wants to object. All right. So this passes unanimously. Thank you. Okay. Next one is a bit more open and dead. So. As part of the hyperledger, I mean the firefly proposal. They were a point of discussion about connectors and plugins. That seems to come up quite frequently in different projects. And like in the. In the interop world. We have the cactus project for one, you know, that uses this kind of connector to blockchain frameworks. And so Tracy raised the question saying, Hey, isn't that something that we should consider maybe tackling. More broadly, you know, say, Hey, should we have this kind of like components that could be defined, maybe at a higher level that could be shared across projects that need to connect to blockchain frameworks. So Tracy, you tell me if I didn't capture the question, right? But that's my recollection. Yeah, I was going to go see if I could see the question that I asked, but I'm pretty sure that's pretty much it, right? Yeah. Yeah. I mean, you know, there's a number of projects that have been talking about plugins or connectors and it just felt like, you know, maybe there's some sort of. Way we could work together on some project that would allow for standardization across the. The different frameworks across the different projects that need connectors. Right. So that's kind of something that just hit me as I was reading through the Firefly proposal. Right, which unfortunately we lost the comments and now we don't have a link to them anymore. Cool URLs don't change. So I try that. All right, so any reactions? I mean, you know, as I said, it's a bit open ended. The question is, is that something we want to look at more in the future? Yeah. So let's actually investigate. See if there is any chance something like this could be done. Does it make sense to do people, you know, are people interested in working or something like this? Or we just leave it as it is today and. You know, pretty much. It means, you know, you're just hoping that people somehow can. Yeah, I think that's just sort of the same thing. And in this project and Steve, there is code that could be used, but it's more random and. Organic than. You know, kind of trying to force the issue ensuring that there is some shared the code where it could be. I see we have Jim on the call. Welcome Jim. What's your opinion on this? Do you think the kind of plugins you guys have. In Firefly. you know, generalized to be useful outside even a firefly, or is it very application or, you know, layer-specific, I should say, because you're not really an application either, but... Yeah, hi, Arnold. Hi, everybody. Yeah, so I replied on the thread in the original proposal. I can provide a link, it's still available if it's helpful. And Peter also from CACTUS also gave input. My opinion at the moment is, in order to keep the firefly API abstract enough across the different protocols, we keep it pretty slim. And it's mainly for serving the purpose of cross-membership data broadcast or private message pinning and event listening. So we keep it pretty lightweight. I don't know everything about CACTUS for sure, but I suspect CACTUS will need different kinds of APIs with the blockchain. Maybe getting a calling for a particular state commitment for more called proof purposes. So it's gonna be pretty different how we use blockchains between these two projects. On the other hand, I think both can benefit from a well-defined RESTful API that is then adapted to the individual blockchain through the more low-level SDKs. So on that level, it's gonna be common. So maybe we can at least look at architectural best practices of how to do that, what SDKs to use and how to deploy those things to make it work the best. So even if the API design is not exactly the same, there may still be both implementation and architectural best practices that could be common between the two. Don't know if that makes sense to Tracy or Peter. Well, we have hot, so that's good. Thanks, Jim. Hot, the next. Hey, Jim, I don't think Peter's on the call today, so you're stuck with me, unfortunately. Okay. But yeah, I think it's really interesting and I was gonna ask if you'd be interested in potentially coming to a CACTUS meeting to discuss this further. Yeah, love to. Mondays at CACTUS, Mondays at 7 p.m. Pacific. If next Monday works, I'll send out an email and we can try to put you on the calendar. Next Monday, what time you said again? 7 p.m. Pacific. Okay. Nope, sorry, that's not right. It's not that time next week. We've moved to rotating meetings. So it's early morning. It's 8 a.m. Pacific. It's all right, guys. You can take that off. We'll figure it out, but sorry for the TSC for putting you through this. No, no, but it's okay. I'm glad that there's some connection being made and there is gonna be some follow-up. I think that's great. Thank you, guys, for doing that. I'll send out an email to the CACTUS list this morning sometime. Yeah, just very quickly, Hart, I'd love to join the Monday meeting. Time works perfectly. Awesome, okay, great. Angelo. Yeah, just a comment on this interface. I like this thing. I see definitely there's a structure that it's interesting. There's an interface that might be interesting is that of a trust adorable. Suppose that I want to learn, that Alice wants to learn something about a blockchain. And so what can Alice do? So she should have a way to retrieve a piece of information, possibly a proof, sorry, a piece of information coming from this blockchain attached with a proof that has certain guarantees is such a way that Alice can check that the piece of information that she's receiving from that blockchain is meaningful enough, which means also that it can be trusted. So that's definitely a general interface that can be very useful in the context of interoperability. And it's very blockchain dependent because what it means that a piece of data is meaningful for a certain network might vary, right? So for fabric it might be, this proof might be an endorsement for Ethereum can be something else, can be other sorts of signatures for other, for Corda can be the signature of a notary that say, say this state exists and this is the state that we are aware of. This, I think there is something like this in Weaver already. I don't know if you can talk to us as well, but Hart, if you want me, I will also, if you can invite me as well, I will be very interested. Yeah, absolutely. Should I? Okay, yeah, I'll definitely invite you. Thank you. All right, great. So I think this is great. We don't need to make it more formal than that. I mean, there are people interested in digging a bit more into this topic. I think, you know, that's great. And if something comes out of it, so much better. If not, if you guys in the end say, well, okay, these things are similar, but different enough is nothing here to do. It's okay also, but at least it won't be because we haven't thought about it. Anything else anybody wants to add on that topic? Otherwise, I'm happy to just leave it at that. All right, hands me hands coming up. So thanks again for connecting, guys. All right, so the next one is a long standing one. So we have this decision reported on the common repository structure where we said the resolution, you know, says that each repo must add basically the repo lint JSON file. And we've talked about this before. It creates a bit of a maintenance nightmare because everybody's copying it and now we have many, many, many copies of the same file. Although, and because there are copies, they are very unlikely to stay the same. And I know that there's been some challenges in implementing it in the sense that, you know, some project that felt like the config file was not, you know, tuned to their project. So depending on the language you use, the programming language and so on. And so some of us have made some changes to the common file that's in the repository, but I'm not sure that has happened everywhere. And yet in the meantime, you know, we said we should investigate further how to handle variations if there's a need for it. Although, of course, it kind of defeats the purpose because the idea was well, we want to enforce some kind of, you know, similarity across the different projects in terms of, you know, what file to find and so on. But I felt like, okay, we should at least modify the current decision, which I think in any case is wrong to tell people just copy the file. So Tracy. Yeah, so when we initially started this common repo structure, it was about making sure that each of the repos had a maintainer's file, a contributing file, you know, license file, those sorts of things, right? And there was a number of things that were, these must exist versus these should exist. And I think what ended up happening was Chris created this repo.json file as a mechanism to programmatically check these things. But I think the spirit of what this proposal originally was was what must the repo have, what should a repo have? And I'd like to see, since repo lint.json has been such a painful process for us, if we could go back to the kind of spirit of what this was and actually define what it is that a repo must have, what a repo should have. So, you know, maybe it's more about repo lint.json is the direction that we should have headed, we should have headed towards a very specific kind of definition of what repo structure should look like. All right, thank you. I think if you click on the link there, common repository that links to the decision, right? So that was, there is actually the list, right? But you're right, it was based on repo lint.json and the time we say, okay, this is great. We even have a tool that people can run to enforce the structure so much better. And we said, okay, everybody should just copy that over and every now and then run it so that they can figure out whether they are compliant or not. I'd actually not sure that if we stick to the original list it's such a, you know, it is a problem. Maybe it's because we have extended beyond that, you know, such as checking like if you have headers and so on, like copyright and whatnot, which we narrated actually from repo lint or repo lint rather than, you know, our own doing. Can you scroll down a bit? How far does that list go? Yeah, see license detectable by license, see blah, blah. Yeah, there are things like binary is not present. It's obviously a good thing, but it was clearly not in our list. It wasn't something we said, oh, you must not have binaries, right? So one way to achieve what you, I think getting close to what you're saying, Tracy, is to actually scale back the config file to the minimum that matches what we said we really ought to have in every repo. And that would, I think, probably, you know, work for every project because you avoid these issues of language dependencies and, you know, and so on. Or are you just against repo lint at this point because you just don't think it's the right term? No, I think if we can make it work with a limited set of what we wanted, right, which is this list of files, which I agree with this is probably a should, right? Notices is probably a should. But I think all of the other ones are must. Then I think that repo linter would work across all of our repos, or they should work across all of our repos, right? And if we want to do something that's, you know, in addition to that, I think the projects can choose to add their own repo lint.json that's a, you know, project specific repo lint.json, you know, a fabric repo lint or a sauteed repo lint or whatever the case may be, right? Then they can add additional things that they want their repo to do. But I think for hyperledger, these are the things that are must in this notices is probably a should. Can I thank you? Yeah, so this was proposed about a year and a half ago. And when we went through this, I said is focusing on a tool the right thing to do and the discussion suddenly went through to let's just vote this through. So my response to that was to go to the community management tools in the hyperledger labs and specify out in a readme.md, which I posted into the TSC that this is what a more non prescriptive, a more like what Tracy was describing, a more standardized approach. Here's what the standard rather than having the tool drive it. So a lot of this work's been done, it's just been forgotten about in the hyperledger community management tools repository. And that's where we've had the canonical repo lint.json live for a while and where edits have been put into them. But I outlined, you know, and people iterated on this. So we do have some of those higher level standards of this is what it would expect it to be. But what do you think about, what do you think about this idea of reducing to a real minimum set of rules that would work across the board that we want to really insist on? Yeah. Some of the problem is some of the, some of the requirements aren't well formed, like you use, well, not well formed, not easily mechanically verifiable, such as you need to have a build system. Well, if you have a .json file, do you really need a package .json? And that's what repo linter does if it sees any .js file, it just assumes you need a package .json no matter where that .js is and it starts spitting out the warnings for it because it saw a JavaScript file versus what the requirement is, is that you have CICD configurations, whatever those look like. Yeah. Okay. Any other opinions or ideas? Right. Sure. How about doing it much like we do with the other badge and make it a declaration base and you can check up the veracity of the declaration later. Much like our project status badge, where it's all declaration based or the one on GitHub whose name I'm forgetting right now that every project has and forego all of that. All right. Any opinions? I mean, Troy, I know you investigated and spent a bit of time trying to make this work and it didn't work very well for you. What do you think of all of that? Sorry, I know, did you say Troy? Yeah, I was asking for your opinion because I know you spent a bit of time on trying to do this work. Yeah, we made it work. So we copied the file into Aries Framework Go and contributed back the changes that we made. One of the issues, of course, is warnings aren't very visible and some of these basically rules are hard to have across projects. So they only end up being warnings unless you copy the file and kind of modify it a bit to make the mirrors more tailored for the repo. So how you handle license headers and things like that might be a little bit different to cross repos, which files are involved, right? So sometimes maybe it's language dependent. So there's some challenge in having like a completely common file, of course. But anyways, we just made it work. But so there is a, I mean, the tool itself I have to say I have to agree that the output is not the most user friendly. So you really have to squeeze your eyes to try and see what it's written. But so I hear there's a couple of, at least a couple of directions. It seems like nobody's really happy with the status quo. So we need to make a change. And it seems like we can either go, like what Tracy was saying is like, let's go back to the original goal of getting a minimal set of files that make sure they are present and forget repo linter or change repo linter to this config file that just changed those days. Sorry, check those things and nothing else. Or we can do like what Ray was suggesting. We forget repo linter all together and do this kind of self declaration. We still need to have a documentation clearly at some point saying, this is the least of files you must have. These are the files we should have. And maybe in recognition of what Dana was pointing out, we have a file there that might help and needs to be reviewed and maybe updated with that in mind, I don't know. But so what do people think? I mean, which way would you rather go? I prefer a narrative standard. It makes it more flexible when technology changes. Wait, so that again, you prefer what standard? A narrative standard. So you're saying not to have the tool and not enforcing a use of a specific tool? Yeah, the tool can be advisory, the tool can be recommended, but at the end of the day, it's the narrative standard that rules. Yeah. Tracy, what do you think? This does fit your, that matches what you're pushing for? I think that, yeah, I think that works. And I think we could definitely start with Dan O's link that he gave us to the GitHub repo where he's obviously put some thought into this. I think there's probably some things in here that weren't, or there's some things that were in the original that aren't listed here, like the security one I noticed off the top. Maybe the code owners is probably a second one, but I think we could start with this list and merge it with the other and come up with the right set of must required files versus the recommended files. Scroll up, security is in a mandated content. There we go. Okay. How are these must versus required? And I'll with specified content. Okay, gotcha. Okay. So here's what I would suggest then. Let's make a proposal to, so we discontinue the requirement to use repo linter and therefore to copy this repo lint JSON file into every repo. That's step one. And that's step two. We have to start an activity on reviewing this readme and deciding whether this is the golden rule or not if there's any amendment that need to be changed. But I think can be done in parallel or with a bit more time obviously we can just do it now. But I don't like the situation we are on where we actually, I think in the report, right? We're asking people, have you copied the repo linter JSON file or are you using repo linter? We should stop trying to enforce this as soon as possible. That's my primary goal because I think we're pushing people to do the wrong thing. So I have two, yeah. So it's two-fold the proposal. The first one is, and the requirement to use repo linter. Step one and step two. I second that proposal, I don't know. Thank you. So that's good, let's go through this. Maybe we can do it like we did before. Everybody who is agreeing to end the requirement to use repo linter says aye. Aye. Aye. Aye. Aye. Aye. Aye. Aye. This is the mute delay, you know. And anybody wants to abstain? Anybody wants to object? All right, so this passes unanimously. Thank you. And then I think, so we don't have to make a decision on this. I would just say, hey, everybody have a look at this file that Tracy is looking at right now, which is in the community management tools. And, you know, let's have a look at this, review this. And then people can raise issues. We can use even the GitHub issues for that matter. And then we can have a look. And if there's like issues that get raised, we can then look at them and make a decision. Once we have done a few duration, we can decide on, okay, this is capturing indeed the resolution that we really want people to follow, you know, in terms of what the common repository structure ought to be. And then I think we'll have really closed this issue all together, make sense? So it's a bit of an open invitation for everybody to look at this, there's a danger that if nobody does anything, then, but I guess we'll have to, we will have to make another decision to point to this and this is indeed the golden rule for the common repository structure, which we still have, that still stands, right? We have decided we would have a common repository structure that everybody would comply with. It's just not completely defined because we haven't pointed to a place yet where it defines it, but that would be the place. All right, I'm happy with that for now. Any other comments on this? Otherwise, we can move on. All right, let's move on. Rai, I think you brought that one up. There's a proposal to create a contributor experience working group. I saw Rai snuck into the call earlier. I did, I apologize for being late. Sorry. So actually, I think I created this at the behest of, I don't remember, and then, okay, so that's... So you don't know what this was about? No, I'm, so this point that Tracy is pointing to is actually the source of my confusion because that meeting was earlier this week. David, if David is on the call, Boswell? Yes. Yeah, I'm on the call. So is the question, what is the idea behind this proposal? Right, and the discussion that was yesterday or Monday. Oh, yeah, okay, yeah. So I can address both of those. So, I mean, as far as this proposal goes, and I think it's similar to things we've talked about in the past, anything that we can do as a group to invest more in thinking through, how do we remove barriers to entry? How do we encourage more people to get involved? How do we support, as the name of the group, as the name of the proposed group implies, how do we improve the contributor experience? So I think that's the intent behind that working group. I think we've been doing things on an ad hoc basis. For example, Arun's been working on an aggregator that, the Start Here aggregator that helps pull all the development activity in one place. And I think that does improve the contributor experience, for example, but that's an individual thing. We want to do more of a concerted effort to look more holistically across all the projects, all the community and see what other projects we could do. So I think that's the idea behind the contributor work group experience. As far as the question goes about that blog post, I mean, I think that's a similar effort that's come up organically from the community. So just to give a little background on that, that blog post is from a number of different people from different special interest groups that have decided that they've identified they've somewhat been in silos and that after having recent conversations, they realize there's a lot more overlap across groups. So for example, we have a climate action group and we have a trade finance group and we have a supply chain group and they're all working on different things. Although there are use cases that span all three of those groups, right? I think for example, they've identified that a green finance project or a project that looks at the carbon emissions across the supply chain of a product, like the product carbon emission that these span different groups. So there's a lot of interest coming from special interest groups to work more together. So that's the genesis of that post. They did reference the idea of a new working group. I mean, I don't know. I wouldn't sit, I think that's similar to the idea of a contributor experience working group. How do we help more groups within the community collaborate together? So maybe we could fold those two ideas together, but that's the genesis. That blog post came up somewhat separately and organically from the community and the special interest groups. But again, I think they're pointing to a similar thing. There are places in the community where the contribution experience could be improved and I think it's great. They raised their hand and flagged, hey, we wanna do more to get people across these groups collaborating, not just within these groups. So I don't know if that answers the question about where that blog post came from. But again, I think it's a good sign that people are stepping up and saying, hey, we care about the contributor experience and this is one thing that we wanna do to help improve it. So yeah, maybe we can view them as similar in complimentary. All right, so I think we now have two questions at hand because there's the question of this group, does it exist? And if we haven't heard from it, I mean, about it officially until now and is it even real since we're supposed to approve them as Tracy points out? Sorry, as far as that goes, yeah, I think that was just some unfortunate wording. And I've talked to the people behind the post. They actually had a call earlier this week after the blog post went out. This is very much a proposal. They're throwing it out for feedback and comment. I think the way the blog post was wording worded and made it sound like it had been done, but I think that's just the main author is not a native English speaker. I think it was never intended to say, hey, we've created this thing. It was more, hey, this is a thing we want to talk about. What's your thought? Okay, so to be clear, I mean, I'm not offended because people are eager to do something like this. I think we shouldn't discourage them just because they didn't follow the right process. But then there's the question of indeed whether we want to create separate working groups here. It seems to me that the working groups we have already often struggle due to lack of activities and participation. I don't think it's very smart of us to spread too thin. And I would be in favor of trying to hijack the energy that seems to be behind this proposal on collaboration and suggest that they also tackle this question of contributor. So I went back and looked at the April 29th TSC meeting and I think that this comes out of this page that Arun put together, which is starthere.highcollege.org. And I just posted a link in the chat. And I think it was to put more content there. It was basically to increase the quality and depth of a page like this. Yeah, agreed. And I do think there are, I mean, to Arun's point, I mean, I think there was a number of different things that we could pull together so that we're not spreading things too thin. There is starthere, there's the interest from the SIGs. I think what we just talked about earlier in the call about us wanting to do more to make sure the maintainers have the resources that they need and having these orientation calls. I think there's a few different threads that maybe could be pulled together here into one more of a concerted effort. All right. So what steps can we take now to try and, you know, make sure we're making progress on this? David, are you in touch with all these people and can you engage with them and try to figure out what could be done so that maybe we have a better defined proposal? Sure, I have been in touch with them. I mean, you know, as you know, staff are a point of contact for the special interest group. So a number of the special interest groups that I support have been behind that proposal. So yeah, I mean, I can. So it sounds like the request is to maybe fold these two ideas together. Is that correct? That's the recommendation. At least they should consider doing that since, you know, as we all said them in now, it would seem wiser not to create too many working groups. Agreed. And as far as maybe something that's missing from this proposal, I guess we need some chairs. Perhaps we could find one of them to step up as a chair. Maybe it makes sense to have, since there's two parts of the community, maybe we want to, you know, a chair from maybe the use side of the community, the SIGs, and maybe it would be good to maybe have a co-chair from the more technical side, from the project side. I mean, that's just kind of brainstorming a little bit, but, you know. Yeah, the question of the chair was on my mind too. So I'm happy you brought it up. I think what you're talking about is reasonable to me. So I don't know if anybody from the technical side is interested in this and maybe I can connect you to the people. We can start a thread together with the people from the special interest group side and talk about, you know, combining the two. Yeah, and I actually wanted to know, I mean, do we have people here who are interested in joining such a working group? Because see, I mean, if we don't have too many people or if we have none, we'll have to see Bobby. I'd be interested in working on this from either a leadership position or just a member to try to get this done. All right, thank you. Arun? Probably it's a comment or probably a different way of thinking my thought process on this is. So since we are considering this to be a collaboration platform where everybody can come together and put their ideas forward and move with whatever proposal they have. Do we, I mean, can we think of an alternate? And instead of saying, hey, this is a way in which this collaboration platform runs and this is just like any other working group there is there are weekly or bi-weekly meetings which you need to attend. And that's how we proceed instead of making that kind of thing. Can we have more of a consultation based leadership positions established for this special working group where if let's say two of the special interest group, they think their projects are overlapping with each other. They come together, they propose this idea to do this working group and then they have their own stream established over there. Similarly, somebody else wanting to collaborate through this working group. They have their own independence to work on what they come up with. Okay, I have to admit I'm not completely sure what they're trying to achieve here. Giving more independence to the innovation aspect or whatever they want to execute through this working group. I see. Well, but I think it's still, I mean, we still need to have some kind of a charter or definition of what this group is about. And so for now, that's the first item, right? It's, you know, are people interested in defining and it sounds like you have some ideas. So maybe you should participate in discussion even if you don't participate in the eventual working group. If I can volunteer you. It's cool. I keep discussing things with David. I think, yeah. And I'll put together those thoughts too. David and C. Wade, where it comes from. Okay. All right. So what I learned is the rune and Bobby are both interested. I can start threads. I can reach out. Yeah. So it sounds like identity, thinking through chairs, thinking through scope are good ideas to do next. Exactly. So thank you. So, and David, you'll facilitate the discussion. Tracy has a hand up. Yeah. I just wanted to note guys, there is a process that we have for creating a new working group as well as a working group proposal that kind of, well, those are the proposals, I guess we have a template for this, maybe. That kind of provides you with introduction, scope, work products, collaborators, interested parties, proposed chair, right? So I think there's stuff here that already exists that we could be using. Rye, just a note, this template needs to be updated to reflect the newest TSC numbers. But there is some process that already exists for working groups that we could follow. Yep. That's a good reminder. Thank you, Tracy. Yeah, thank you for that. All right. So I think we have a plan. That's good. Thank you. So this is kind of the end of the agenda for today. I did want you to point out that in addition, I created a new entry in the decision log for the backlog on the criteria for entering incubation. I thought given what happened with the, I mean, it was pretty clear through the Firefly Propolo process, this is not something that is well documented today, if at all. So we should try to define one. And I figured well, to acknowledge that this is something we want to do and we don't forget it, although I don't really expect us to. I created this entry. I think if there is somebody who is volunteering to lead like a task force kind of thing, that would be appropriate and to basically start drafting what this criteria would be. I think that would be very helpful. I see if people have commented quite a bit already. So that's cool. We could, I mean, I'm not sure the Wiki page is the most convenient way to do this, but I would imagine that, the better way to actually develop the proposal is to do a pull request against the TSC repo to add the page that defines the criteria for entering incubation. And we can use the GitHub repo to discuss this. And once there is some draft that can be put for the TSC for consideration, we can all look at it and then hopefully approve it or make some amendment as necessary before we approve it. That would be my proposal for, but it's good that the discussion started. All right, we're out of time. So thank you all for joining. We'll leave it at this for now. Talk to you next week. Goodbye.