So the session is being recorded, and the first thing I'd like to do is make sure that I've captured the quorum of TSC members. So I've noted that Hartman, Gunnery, McBowman, and Morley, Krishna have winned. Let me go through the rest of the list, is Arneau on the line? Okay. How about Ben Nguyen? Chris Ferris, Dan Middleton, how about Greg Haskins? Richard Brown, how about Sheehan Anderson, okay, how about Tomas Blumer, okay, so it looks like we've just got three of the 11, so that's not quorum. Brian, are you on the line? Yes, I am. Okay, great. Well, I guess we can get started. I think there's very little that actually required, but there are a couple things that would require a vote that we'll just try to have instead on the TSC mailing list, perhaps the conversation there and other due next week or otherwise. So, yeah, is Chris Ferris on the line? Yeah, I know what's happening this week, it's hard to tell, but all right, let's dive into it. So, we have been continuing to ask folks for a minute from the requirements working group. I don't know if Oleg, if you're on the line. Yes, I'm here, hello. Great. Do we think we'd be able to get a charter from the requirements working group sometime soon? Yes, our next meeting is going to be on February 20th. Let me prepare a document that we'll discuss with the group on the 20th. Brian, if you have a template or I don't know, maybe if you receive the charter from other groups, let me see what the scope of this document, how it should be. Okay, the identity working group, I got a good one, so it's in the notes from prior, prior event, prior meeting, so I would solve that. Okay, I'll take it as an example then. Okay. Thank you. And then the Fabric SDK, I think something was sent along, oh no, okay, so we do have actually one that was sent to Minu and Greg and I, I'll link to the charter and see if we can drop that link into chat. Sorry, I'm saying to everyone. Okay. So I'll drop a link in the chat for the charter for the Fabric SDK working group. Hey Brian, this is Morali from DTCC, the charter was not able to attend and we do have the charter that we looked at, charter for the Fabric SDK, is there something that we want to do? So this is an interesting, yeah, yeah, yeah, okay, so we have it here, we're looking at it. So this is something that I'd love to get from folks on the call from, so this is a working group, you know, different from the others in that it's particular to the Fabric project, although it's a useful way to try to tie together, you know, the other SDK projects and other efforts and can be, could be cross-cutting in a way, but is there, is there a lot of distinction between this and what, say, the architecture working group could be working on and is this something that, you know, is properly done as a working group or properly done as, say, a part of the development team on the Fabric project or, I don't know, I'm just wondering if the working group is the right place for this and if there are similar working groups that thus would spawn for particular interfaces between projects. What do people think? And I think we have an opportunity to revisit, revisit the structure, but if it's working, then maybe we just keep going with it. And Brian, you know, before we hear comments from the other, this is Morali from DTCC. I think the initial parts was that we'll do the SDK for Fabric specifically, but later on, you know, once we, once we're concrete on that, you know, look at a possibility of making it generic enough. So that was the third process, I just want to put that out there. Okay. And I was saying, which is on, sorry, I'm late. No worries. Can everyone see that document, by the way? And I posted a link, it looks like Morali posted another link. And the heart says the document might have permissions that's a private. Okay, let me, let me try to give, let me give permission, sorry about that. I think the one I'm looking, the one that I posted is public, because I'm able to get to it from an ordinary browser that I'm not logged into anything special from. By the way, did anyone else from the TSC join since we took a roll call? You sound like Richard from R3. Yeah, Brian. Yeah, I'm Richard. I'm mobile. Great, but I'm on. Sorry, who was that? Was that Richard or was that somebody else? I think that was Richard. So we still aren't at Quorum, so we're not at the point of accepting, voting on the charters, like formally and accepting them. But any other thoughts up there regarding fabric SDK as a working group versus as a, as a project kind of sitting next to, you know, fabric, sawtooth, the Roja, et cetera, chain, chain tool. Yeah, I think, you know, I think it worked well. It really is sort of a, you know, at this point, a sub-project of fabric, if you will, but, you know, the reason that we formed the work group was, you know, to sort of unite on a specification for what the API would look like, how would behave so it would be consistent from one language to the next. And as a means of unifying, you know, what if the time it's in sort of a disparate, you know, collection of members contributing to the respective repose. It could be, though, a sub-project or a project of its own, I guess. I think that's really going to be up to Morali and Jim and the guys. And they'll, uh, so if it's, you know, I think if it, if we want it to be sub-project, I don't see a problem with that, but I think like I was saying, we, down the road, we would want to make a work group, hopefully have an SDK which spans across the, across, across the different engagement page. This is back, just, I guess, my thought is kind of consistent with that. If it's, if it is just a, you know, sometimes focus on fabric, then it seems like that's kind of missing the point, at least in my understanding of the working groups, where we expect them to be cross projects and contributing across all of them. So the distinction between, back to your comment earlier, Brian, the distinction between the architecture working group and fabric SDK group is architecture is really trying to contribute across multiple projects and drive unification of it actively as part of our, as part of our objective. So in the worst case, would it make sense to start, to rename that to some API or interface or maybe merge it with a protocol group? Do we still have a separate protocol working group? Is that still operating or is there interest in rebooting it? I don't believe we have a protocol working group, right? Yeah. So here's, here's what I think. I think every project has the potential to expose APIs to other projects, right? And it's kind of the responsibility of each project to, if it wishes for those APIs to be consumed by other projects, to document those, right? And to encourage conversations around those APIs with the other projects. It feels to me like likely that an architecture working group or some cross-cutting working group is an appropriate place to have conversations about, hey, you know, how might we, you know, formalize these APIs to be something cross-cutting and that we, it might be best to preserve the working group as just, you know, the working group structure, the point of the working group to be cross-cutting, but that each project is responsible for documenting those APIs. And so, you know, like we would have a Python SDK project, you know, a Node SDK project, even if that project was specific to fabric, that's okay, but I wouldn't have a working group for the interface between them. I'm just trying to be clean here so that when, you know, new folks join the community, they can try to understand the kind of power structure. This is Morali from DTC. I agree, Brian. You don't have any problems making this from the project. And I don't want to overload one project fabric with what is really a lot of different activities. I think there might be some thoughts out there about, it would be logical to kind of move fabric into a couple of, you know, parallel projects as well, one focused on, and we have chain tool as a separate project. Maybe we could even consider, you know, other parts of fabric as separate projects as a way to help modularize the community as much as modularize the code. And that might help with some of the overloading on one community, one team concerns that may arise from having this activity be project level rather than working group level. Well, just in the interest of time, why don't we move on from this issue. And Chris, now that you're on the phone, I wonder if you wanted to drive the agenda from here, or if you want me to continue. If you wouldn't mind, I'm in the process of collecting the valet and seeing my stuff in the process, that would be awkward. Okay. So, all right, so on the fabric SDK working group, why don't we continue this conversation on the mailing list and just to make sure we have thoughtful voices represented. There was a vote if we had enough TSC members. I know we've had a few that have joined. So, we have Richard from R3, Chris, obviously, you've joined. I still don't think we're at quorum, unless others who've joined. Anyone else can speak up. Hi there, you've got this, you've got Leiflin Thomas from FunServe. Great, welcome. Thank you. Anyone else join since the, anyone else join since the local from the TSC? Okay. So, just to throw this out there, there was a conversation about putting the archive of the Slack channels, which we now can get access to ironically, now that we no longer need to support 6,000 users on Slack. When you archive a channel, you actually do get access, as I understand it from live, to the archive older than those 10,000 messages, right? It's like on the way out, we're able to do what we wanted to do all along. So, we could put those up in some place, make them searchable, make them browsable, or if people presumed that those conversations were ephemeral anyways, we can simply maybe check it in into a place that might be harder to search, but at least keeps it as an archive, or presume that people have those conversations on the presumption of ephemerality, and don't actually want to continue, or don't want to have those available. What are people's thoughts about that? Should we put them somewhere else? So, Brian, this is Chris. I think maybe, well, I know why I put them someplace temporarily, and I'm wondering if we would just sort of agree or we keep it around for a couple of months, and if nobody's looked at them, we can just start them. Or we could go the other way, check them. So, Rye has them in a private GitHub repo, just a raw archive, well, in an HTML format, because that's how you're able to extract them. We could put them somewhere, we could check them into a hyperlinked repo, and then if somebody wanted it to be somehow more searchable, then they could take the task of implementing that, they don't have to necessarily jump to that. I'm trying to see if it's one big file, or if it's a file. Well, I mean, we could think about putting them in nexus when we get that set up, and then it probably could be searchable in Detective Rye, if that would be useful. I don't know how much space it's going to be, but you're going to recall it wasn't that much. Not huge. Yeah, huge. OK. If anyone wants to, I mean, I'm looking at it now on GitHub in Rye's message, it is pretty much raw HTML checked in as files in the GitHub, but a little bit of processing in the end, if it's something that could be fairly readable. OK. Well, we don't have to burn more time here on it. But if anyone has time, we can put it in. Moving along, I'm just checking the chat if anyone had any other thoughts. Oh, by the way, as a side note, now that we've moved to Rocket Chat, there was the proposal to have a Rocket Chat channel for TSC calls instead of using the chat in good to meeting, since that disappears at the end of every meeting. And I don't think we did an archive of that. I'm sorry, here's that. It doesn't disappear. Actually, that chat is part of the archive of the meeting. Oh, OK. I mean, it can be archived in the sense that I have archives of all chats, of all TSCs. Right. If you're running the go to meeting client, it makes a copy of the chat local, so. Yeah. Still might be nice to see where other chats are. It's convenient it's nice to have it right there. So I thought that having the chat on the Rocket Chat TSC channel actually would also enable people to come in after the fact and contribute to the discussion, as opposed to just reading it. Yeah. The advantage of doing that. Once you're dealing with just an archived copy of the chat transfer, it's static. OK. But let's iterate this then on the TSC list.  OK, so then we also asked for project updates. And first off, is there any other comments on that? I don't want to shut down the conversation. So we asked for project updates. And it's not clear to me if this is going to be a weekly thing, if we wanted this to be a weekly thing. I tend to find that delivering updates in a phone call. First off, thank you to everybody who did fill this up. I think it is important that we do this on a regular basis as a way to maintain kind of an ambient awareness of the other projects going on. Some projects I know, like Pachi, require their different communities to report in once every three months-ish. I'd certainly love to have a more frequent check-in than that. Of course, they have 300 projects to deal with on their calls. But I don't know what kind of frequency we'd like, but I don't necessarily want to walk through this at every TSC meeting. I do think, however, that it is useful for the TSC to be reviewing these as its responsibility to have kind of a response if either there's no update or the update indicates that there are challenges in the community. So I'd love to have a conversation. I think back to the specific updates, maybe something that we could do here if anyone felt that there was something that popped up in these that is worth talking about at a TSC level. But I'd also like to talk about what kind of frequency that we should ask projects to report to the TSC. Should it be a quick summary of this to the TSC mailing list once a month, once every two weeks? I'd ambitiously 1.1 today this week in a blah project. And that might not be too much to ask for. But what's the right frequency and format for that? I wonder if folks have any opinions on that. Mr. Bippin, initially it was once a month, as suggested by Chris. Yeah, I think monthly is good. And then the nice thing, Brian, is that it also coincides with the newsletter, and so we can incorporate the same content there. So they thought, is there somebody? Nope, we're all here. Sounds like there's convergence on once a month. And hopefully that's free enough. I think that is at least the bare minimum, which is for the sake of creating the newsletter and getting the word out more broadly. And some projects won't be as active as some of the others we have now. So once a month might be right. And then is the TSC the right meeting to, say, go through these line-by-line? And is it better to try to drive the conversation of the mailing list of that and bring things here that we should go to? So for me, I think my take is that it's not necessarily something that we would need to go through line-by-line or whatever. I mean, it's there. It's informative. And it's a way of keeping touch with what's going on in the next steps that's going to come in. So from that perspective, it's very useful, and certainly useful for women. I would think that from a TSC perspective, the focus on projects on the TSC would more along the lines of what are the guidelines for incubation. And if we run into projects that bubble or whatever that the TSC would be where we would iron those things out and where we would look to drive the consolidation, integration, interoperability aspects of the cross-project of land-based incubation, as opposed to having to report. I mean, again, I think it's useful to report what's going on in the various projects but not clear to me that you necessarily wanted the TSC to be driving the project, if you will. But I agree the line-by-line is too much. But it's still nice to have a fixed point of communication. And even if you just say, here's the highlight for the month, the one highlight for a month in the TSC, that's likely to spurn conversation and communication that goes broader than the individual project working group things. So I would not want to dedicate a whole meeting to that communication. But something that allows us to sort of see a picture of what's going on across the groups would be helpful. So what Apache requires, and I'm trying to look this up in the background, what Apache requires each of the projects to cover in their reports to their board, which, again, happened only once every three months. But they actually make a report in the report actually give us a voting on and accepted by the board. So the board is basically acknowledging we have read this and probably no issues. Probably it's just a real quick scan. And in fact, they even do some of their voting ahead of time in the version control system so that when they get to the actual board meeting, if there's already a quorum of yes votes to accept, then they don't even spend a second on it during the board meeting. And so in the ideal case, during their board, months of board meetings, they are only talking about the edge cases or the things that, you know, if the report was incomplete or there was a concern about what they read. They require the projects to report on the kind of the status and the health of the project. Are there any issues specifically for the board to act on? Did the project make a release? Grab the overall activity? So it's, you know, are there new developers coming in, that sort of thing? I can send actually the link around. It's probably a bit much to ask every project to do every month. But it does kind of show the board kind of performing a level of due diligence on the projects, right? Making sure, and again, this is important when you have 300 projects and not six. But it is partly as well about making sure that as we grow, we're able to maintain this oversight and this ambient awareness and this governance, even on projects that folks are not following, you know, at all, right? So, that would be sort of like looking at the aspects of projects with the way I'm looking for the mentality that's right. So you're also talking about having things like, you know, number of contributors, contributor diversity, number of commits, releases and so forth. Is that what I'm hearing you say? Am I still on here? Oh, I'm sorry, I was on mute. Yeah, no, basically it's a way to just make sure that you're monitoring the health of the project from a community, from an activity, from a, you know, at least for Apache, what's important to Apache, the Apache board doesn't care necessarily about the technical details of your project. And I think we care a little bit more because we do want these projects to be integrating with each other and looking for opportunities to work together. But things like legal issues, right? Is there a flame war that's broken out and gotten vicious between your developers? Are there signs that, you know, the project is more abundant, you know? And this is the basis in some cases for saying, okay, maybe this project hasn't seen any activity, no bug reports, no, you know, and it's time to kind of roll it up and put it in the attic, which is, you know, kind of a preserved and amber kind of thing, you know, the lists are kind of closed up and the archive closed. Oh, and archived, right? And, but long before then, it's also an opportunity to try to find out are there projects that merits, you know, in Apache's case, the board's attention, in our case, the TFC's attention. And it's kind of an essential way, I think, to grow, to respond if we do grow beyond six, beyond 10 different projects within a hyperlegic. I did send the URL around, sorry to those who are only on the phone call and maybe this is something we can continue on list afterwards. Yes, hi, this is Leonard. I did receive my copy, it's good. I think overall, everything's been said is very important. We need to have that transparency so that we can be seen as doing good work and coming to like conclusions with like results and that there's value and merit in what we do. So that's what's important in communications all about. So most certainly Apache does have a format that we could develop. The right template for our report starts at the monthly level. See how that works for us. See if we need to increase the frequency. I think different indicators could be quarterly but we could start monthly if we have the right template together. So we'll try and make it as easy and as simple for the different projects to fill in the relevant documentation as we see fit and it will be a template. And I think it's all very important. I didn't get the name of the caller. Everything we said is very important that we have that level of support and communication and transparency to the board. So no, it would be a good thing to have a standard template that we could use monthly to start. Actually what I had suggested, was that we continue the monthly updates but if more detail is needed then do it either quarterly or half yearly so that there can be more depth to the reports. So I mean, we have the monthly, it goes into the newsletter, it also informs the TSC update to the governance board that Brian and I give that report out on. I think adding the other aspects that we're just discussing in terms of vitality and so forth would be a good addition. But I think, and Brian, you know, quick me if I'm wrong but I think that actually the revenue board does want to have sort of that monthly update so I don't know if we can make it quarterly or anything, I don't think that's a good idea. Maybe what we do is have this kind of level of activity or the kind of reporting that we see here on the agenda, you know, a monthly thing just that we know about features and functionality and major releases and that sort of thing and then a quarterly update which is more about the health of the project, you know, more about these issues like committer, diversity, committer, you know, issues being responded to. Are there any issues for the TSC to pay attention to that sort of thing, you know, just to try to say that's more of a project health check-in, you know, a check-up and that those would be reports that the board acknowledges by a vote having accepted, right, I think there's an important kind of thing there to say that's actually a, you know, that the board was active in reviewing that, you know, even if offline, even if outside the context of a call, but at least reflecting that kind of chain of governance between the two. So monthly just the raw technical kind of update and then quarterly health update. Yeah, and I like that because quality health guess what can always at some point in time transition to a dashboard and that dashboard is always available so that anyone at any time can review health status on any of the projects or if any relative, relevant issues that a critical, well, knowledge that everyone needs to know can be part of that dashboard. So it's something we can all move towards in time using the idea of a dashboard and to provide health ongoing. So I like that idea. Okay, any other thoughts? I don't know that there's enough of a proposal here yet to vote on something. Maybe I'll come back and put something on paper, give us a chance to review it and we can vote next week if we have for them. How does that sound? Oh, good work. Good work takes time. So yeah, I think that certainly is a good approach. Okay, I'd iterate this over the next week then. That's where I'm sure everyone else has had a chance to speak. Okay, so we're expecting a conversation next week about the GlobalSaintVlog Tamash schedule to present. So if folks wanna review the documents that Tamash sent around a couple of weeks ago, perhaps even a few months ago at this time would be cool. And we're also, I think, eager to hear about plans to potentially bring that to Hyperledger. I wanted to also send a reminder to folks that we have kind of a last call for mentors and project suggestions for our internship program. We've had a couple of ideas and I think what we'll do is we'll come back to the TSC with kind of a recommended set of those ideas and for acceptance sometime in the next few weeks. For the deadline to be tomorrow to fill that form out and there's a link in the agenda to that form. But we're excited about the suggestions that come in and looking forward to kicking this off as a way to expand the community. Any other, let's see, oh, Hackfest. So there's a hackathon taking place in China, March 10th and 11th in Beijing. I'll be there for it. It's not clear to me who else from this call will be there but I think our members of our China technical working group will be there. But I think the call was made not to have a Hackfest at the same time. Just the logistics of getting that done seemed to have presented challenges and I think it's kind of late as well for many of you to be able to attend that just with travel commitments and that sort of thing and getting invite letters done and visas and that. We do want to eventually have a Hackfest in China. I think it might be something we do in parallel to a Hackfest somewhere else just because for logistics and such but that does open the product of finding another location for a Hackfest either end of March, beginning of April, that sort of thing because I think keeping the drum beat going and keeping the face-to-face engagement. We could do it in New York, we could do it in Europe but if folks have a preference for this, well let's give it a few moments here just to talk amongst the TSC. Do we want to aim to have another Hackfest? Do we prefer to have it in the US or Europe or somewhere else in Asia at a stretch at the end of March, beginning of April? And then we should be also, we're trying to get back in the saddle of planning these further out. But where would people like to have it next and where do people think it's reasonable to have it next? And does anyone find up to help us find a location for the next one? So I don't know if you can hear me, I only have one thought all through a while. March is gonna be three and a half, I'll be in March. Yeah, if we kept to our regular schedule it'd be end of March, beginning of September, I'm sorry, end of March, beginning of April and yeah, I'm sure people are starting to get booked out there, starting to put their travel and make a move into that timeframe as well but I'd hate to go too long without a face to face. I think we should have it in Boston so that Greg can come. I'm the slacker. If Greg had a location, then that'd make it real easy. That would be very easy, yes, I would have no excuse. We have a, IBM is a lab, I'm not sure what kind of space we have, I know that there's like an auditorium area that can be repurposed and probably do is to see if we can leverage something in the system. So that wouldn't be in downtown Boston but it would be out by 495. Okay, well let's continue this conversation on the TSC then because we obviously wanna get this set so people can make travel plans if we're gonna do it recently soon. Just wanted to, and if anyone can make it to Beijing, March 10th and 11th, we would welcome you. It'll be a lot of fun and get in touch with me and or Todd about getting connected to that because having some expertise there would just be really helpful. Chris, I don't know, are you planning to be there? I am. Okay, well we're at the end of the formal agenda. Are there any agenda items anyone wanted to add? Okay then, folks under 17 minutes back to their day. Thank you all very much and we'll talk again next week. Let's have the lunch, have a great day. Bye bye. Thanks Brian. Sure, take care, bye.