 Good night, wherever you are. We have a fairly light agenda this morning. The hackfest planning obviously for the February hackfest continues. If you haven't registered, please do so. The draft agenda is linked in there and please do start fleshing that out. And again, I think the admonition should be more hacking less yacking because we're going to have a day zero that will be all of the presentation material for where things are and catching the new people up with the projects. So on that topic, two quick things. The sooner you can get agenda items in for the two full days of the hackfest, we'll get that mapped out into a bit more structured of a format. In terms of day one, or the day zero, the training day, Tracy, do you want to just talk through your thought process on that quickly and just see if folks have feedback and then to Hart's question of who should show up, I think we can tackle that as well. Yeah, sounds good. So as I mentioned last week, I took a stab at defining what the schedule should be for that day zero and you can find that in the link there. But really, I start with a half an hour of welcome and introduction. So this would be just the general thing that we normally do at Hackfest, which is kind of go around the room and, you know, introduce people and kind of talk about kind of where they're at and just kind of get a feel for who the audience is. Then 45 minutes to just introduce what is Hyperledger to talk about the different projects and, you know, how we kind of function. 15 minute break and then the next section before lunch is really just getting up and running with Hyperledger Composer and Fabric and then setting up your development environment for Hyperledger Composer and Fabric. So this would get people up and running and setting up their dev environment so that they are ready to make a first commit at some point, be it, you know, that afternoon or on day one or day two. So after lunch, we then do the same thing for Sawtooth followed by a break and then the same thing for Indy. So I chose just a small number of projects because when I started putting all the projects in here, it just got a bit overwhelming, I thought, for people who hadn't actually been involved with the different Hyperledger projects before. And then in the afternoon of 45 minutes, kind of landing your first commit. So kind of what I was thinking is if we could make sure that Indira or, yeah, I guess all of these projects are Indira, if Indira we could set up kind of the, you know, good help wanted bugs or the good first bugs that people would be maybe able to actually get a commit in to actually feel like they're participating and contributing, that would be great if we could kind of create that initial list for people. So that's kind of the agenda that I put together. You know, I need to obviously reach out to people from these different projects to see if we can get somebody to lead each of these different sections and really focus in and get people, you know, started. So open for feedback and open for your comments. So I think, Tracy, the one feedback that I would have is it's not clear to me that we need two 45 minute sessions for each project to both get started and get the development environment up and running. In some cases, it's going to be the same thing. But I also tend to think that, you know, it would be better if we could actually get all of the project covered, including borough and so forth. And then maybe have a parallel track where if you've chosen to engage in one of them, you can get your environment set up. You know, from a development perspective, because I don't know that everybody is necessarily also going to want to be a contributing developer on sawtooth or fabric or what have you. In many cases, they're there to learn and then they want to consume the project but not necessarily contribute to it. So I would maybe think of parallel track for if you'd like to get your development environment set up, we can have mentors who can, you know, be going through the step-by-step in different tracks. To the point where they can get on a command line and be productive. And also then finding enough experts in all the projects to be able to come early, you know, it's a bit more challenging than finding it for three. And now those three were arbitrarily chosen. They don't have to be the three, we could choose other three. But I, yeah, those are the two questions I think for this group. I like the direction that Chris was taking it, that let's have a short intro session for each project who's able to send somebody. So that the community that shows up there gets to see the menu, so to speak. And then, you know, they can dig in on whichever course interests them in some parallel breakout sessions. And maybe that is setting up a dev environment, but it might not be like a core development dev environment. It might be an application dev environment. Right, which, and again, that's where I think getting up and running is sort of the equivalent to that. Yeah, I think Arno and I are converging in chat. But what if we do something like we have introduction talks for the projects in the morning, and then in the afternoon, we let people do everything from like set up environments to discuss applications, just in kind of a very new person-friendly environment. OK, so if I'm hearing correctly, and I just want to make sure I am, introduction with slides for each of the different projects in the morning and then later in the afternoon, we may have to go to a somewhat after lunch for those introduction slides as well. Have a, just a, hey, go find the right table and have the conversation for whatever it is that you want to do, be it getting set up to write applications or being, getting set up to actually contribute code. Is that what I'm hearing? Yeah, I mean, that's at least what I had in mind. My thought is that it will be good for people to kind of understand the big picture, and that's what we can kind of tell them in the morning. And then the afternoon, or I'm not sure anyone, particularly people who's new, will want to set up kind of three different dev environments for three different projects, right? So what I would, what I would be afraid would happen is if we did that, is that people would just kind of do the first one, and then like the second and third people would just peel off and get bored. And if we do some kind of parallel track, then people can kind of pick what they wanted to think of from there. That's what I was thinking, too. So we have first, and I don't know, I mean, morning, afternoon, whether that's the right split or not. But first series of presentations that basically introduce the different projects so people get a flavor of what these are, and then they can choose which one they want to follow up on and get more hands on experience by setting up the development environment. So not hearing anything else. I, yeah, go ahead. Yeah, I was just doing what you were going to do. Sounds like we've reached the end of this version of it, but we can keep iterating. Yeah, so I'll take another stab at it. And maybe I'll just send off to the TSE mailing list, kind of what the, that it's been updated so that people can have a look and provide additional comments or thoughts that we can do that. Over email instead of kind of coming to the thing. I think that the huge thing with this, obviously, is if we're doing nine projects, right, that's at least nine people, if not more from each of the different projects, but maybe hopefully more than one, because you'll probably want at least two from each of the projects if you're going to do this split of setting up your development environment and then setting up your application development environment. So that is obviously a call out to the community and the different projects to start thinking about who it is that's going to be joining us. And maybe if that's you, please let me know so I can include your name directly on the agenda. OK, thanks, Tracy. And yeah, I definitely think that if we're going to try to have, you know, show the flag for each of the projects, it definitely makes sense for, you know, at least one or more of the maintainers from those various projects be present. Just again, because I think, you know, part of this is for, you know, those who are sort of in leadership roles in the various projects be present for the new attendees. Make them feel loved, right? OK, thanks, Tracy. OK, so. Moving on, I don't know, Todd, did you want to say anything about April or June? So we're chatting with the Dubai folks right after this call. So that should be locked down soon, but we're tentatively April 29th to May 1st. And then Amsterdam is fully confirmed June 27th to 29th, and we'll have the registration page up hopefully by next week. But those dates are locked in. OK, thank you. All right, in terms of project reporting, there will be none this week. And we will defer sawtooth to next week, and we'll have both sawtooth and in a row, sorry, a part that's cut off for me. Um, read out next week, so hopefully those will be fleshed out. The last topic of discussion was something that Dan brought up in chat with me on the board call yesterday, suggesting, you know, we've, you know, gone full circle with the reviews of quarterly reviews for the projects and and we're starting, you know, around two. These have been fairly useful. I think they've both, I think, helped the various projects reflect on where they are and get a sense of what it is and so forth. And and then they've also been great at sort of engaging across projects, right, which I think is also a very positive thing. We used to have, you know, sort of weekly readouts from the working groups, and then I think it went to bi-weekly. And then we said, oh, just send an email and, well, you know, I think the reality is that we really haven't had many updates except when somebody has a deliverable like the requirements. I'm sorry, like the the white paper working group and so forth. So. So Dan was actually suggesting maybe we want to think about doing quarterly updates for the working groups as well and, you know, for them to sort of periodically. And I think it's it's it's a little bit different than the project updates. But again, for them to reflect on where they are, do they have diversity of participation? Do they have, you know, dwindling participation? Is there, you know, are there deliverables being worked on and so forth? And so I'd like to briefly just sort of raise that with other members of the TSC and see if they agree that this would be a worthwhile thing to pursue and and what shape that might take. So, Dan, maybe you want to weigh in because you're the one that brought it up. Yeah. And I think you you covered the gist of it. It I can't, you know, from my perspective, I couldn't say necessarily what's going on in a lot of the working groups. And in some cases, you know, I could probably solve that myself by following some of the links that do get circulated. And in other cases, it's it's not clear if if a group is still active. So on one side of the spectrum, I'd say, you know, Vipin does a great job advertising what's going on with the identity working group, and that seems to be a pretty active set of discussions there. And then, you know, pick on the use case working group. I don't know if that's still active. I don't know if those discussions are still going on. So if we've got a group that's, you know, maybe it's that group, maybe it's other groups that are really no longer active, we probably should go ahead and just formally close those off. Or if in the process to close those off, that re-sparks some new interest, then we can actually get some forward momentum again. Yeah, no, I think this is good. Other thoughts to make the process of I mean, I anticipate that will mean even more kind of reporting and discussion kind of processes at the TSE, which I think we do have the ability to handle. But I might suggest, especially since I anticipate us at Hyperledger staff making a case to launch a few more sector specific working groups like the health care working group that we have. If we implement that, we may want to encourage a move to kind of written reports ahead of time and optimizing the time on the calls for questions and conversation about the written rather than, you know, kind of a 10 minute monologue from, you know, from the working group itself. Yeah, just another note on that. I'm assuming most of the working groups, well, at least the architecture and white paper, you know, we're pretty good about keeping kind of detailed notes about the conversations. Are you suggesting that kind of a one paragraph upleveling of that or maybe just making those notes more available? I think I'm kind of saying walking into a call presuming that people have read the written summary and, you know, with maybe a minute, you know, for those who haven't, but that, you know, the detail, the proper detail and the expectation is that it's in the written summary and that's optimizing the time on the call for a question and answer. Yeah, so, I mean, we actually do have written updates for each of the project reports, and then we usually, you know, allow the person who's presenting to sort of do a voiceover, not read it, you know, per se, but to provide a little bit of context between the lines. You know, again, if we get too many of these, then we may have to find a way of shortening it by getting people to actually read, do us a little bit of homework beforehand, I agree. But I think, you know, in terms of, you know, what is reported, Mick, to your point, I wouldn't expect that it would be the detailed minutes or whatever of the meetings so much as, you know, like we have with the projects, you know, more sort of meta things about participation, diversity, you know, frequency of meetings, progress on any deliverables, and that sort of thing. And so maybe suggest that, you know, maybe Tracy could sort of put together a suggestion for you know, what that report might reflect just as she did with the projects. So similar to how the project reporting then goes back to the kind of original proposal and progress against that, I'm assuming that this would go back against the charter. Right. Yep. In terms of participation, I have a couple of comments to make. In the identity working group, you know, a lot of people show up on the calls. And also on the architecture and other working groups that I have been part of, people do show up on the calls, but the amount of contribution, even from volunteers who had previously volunteered, and to get work output from the volunteers is, let me put it this way, difficult. And I think that I see the same suspects, you know, I mean, which is normal, I would assume like 80% of the work or 90% of the work is contributed by 10 or 15% of the people. But how can we broaden this? This is something that we have to really think about just having reports, just having these things is a good thing. But at the same time, we have to foster engagement, especially in things that are not directly related to coding. You know, this is a problem. And also the projects when, for example, in architecture or in identity, we do ask for reps from projects to show up and talk about their solutions or their viewpoint on things like identity or architecture or specific things in architecture. So we need to really, as we are entering like our third year, we really have to think about how to foster that engagement a little better. Yep. So I think that's a really good point, Dipin. And I think actually that if we were to go to some sort of a working group read out that, you know, part of that could also be, you know, the sort of discussions that I think we were thinking about for the project reporting, which is, well, if you're having problems getting new committers or growing the diversity and so forth, that part of that conversation can be sort of peer mentoring, if you will, from members of the TSC and the broader community, sharing their own experiences and their own approaches. And so I think the important thing is recognizing to your point, Dipin, where maybe there is some challenges in growing engagement and so forth and then using this as at least as a springboard for having a sidebar conversation with some other working group chair or what have you with potential suggestions for how that could be improved. Is it fair to say then that there's general positive vibe around this sort of thing and that maybe we should ask Tracy to try and pull something together for the others? As long as it's not just a box ticking exercise, I mean, you know, we just watched some of these devolve into the reports, language, you know, somewhere. Oh, did the identity working group submit its report? Yes, tick, you know, so anyway. Yeah, I hope these reports can also be used as a way for the working groups to try to get more interest and participation from the community. Yep. Yeah, I agree hard. So Tracy, can we ask you to take that on? Sure, you can ask that. Sure. You can ask whatever you want. Nice. You can ask getting ignored. Okay. All right, Chris, I will work. Chris, I will work on that. Not sure if it'll be for next week. A call or not given that I'm in China, but I will definitely work on that. Yeah, I fully appreciate your travel schedule. Yeah. No worries. Okay, thanks. And unless there's anything else for the agenda, then I can give people half an hour back. That's good. Yeah. Thanks all. Thank you all. You're still not.