 Alright, welcome everybody to the February 23rd hyperledger technical oversight committee call. As you are all aware you've seen this before the antitrust policy notice is something that we must abide by, as well as our code of conduct, which is linked in the agenda. So for announcements today we have. I think it was three announcements. Somebody would mind moving the screen, but the first one is the standard dev weekly developer newsletter goes out each Friday. If you do have something that you would like to include in that, please leave a comment on the wiki page. The second one is as you are all aware last week we have men come in and talk to us about the hyperledger mentorship program. There is the project proposals that are being requested by the community to be submitted by March 15. We have anything that you'd like to have a mentor for please leave a project proposal there at the link. The third update here is last week we had talked about the project updates governance when we would merge PPRs that came in for the project updates. I did submit a PR for that last week. It did get merged in. I wanted to make sure that everybody was aware of that because I think there was only a couple of reviews before it did get merged in but that change has gone into the TOC site so that you should be able to see that. Any other announcements that anybody would like to make. Okay, so then for quarterly reports we did get one quarterly report that came in the hyperledger bevel one first came in on the wiki but then has been sent in through GitHub as a PR. There have been I think five or six of us who have had a chance to look at that as of this morning. Good morning my time. So if you haven't had a chance please do have a look at that I did not see any comments in the PR yet any questions, but does anybody have any questions or comments on the hyperledger bevel report at this point. I have a comment. Okay. We aren't using date ranges on their thingy like you like. And I looked back at their previous reports and they haven't done it either. So I didn't say anything. I didn't change anything. But probably worth a comment then. Okay. We can do that. I think it's I think the interesting thing about the insights reports are that if you don't have a date range it basically will be whenever the person clicks on it. So, for example, if somebody had submitted something last year that just said the next, the past 90 days if I went and clicked on it today I wouldn't see last year's 90 days I would see this year's from the time that I clicked on it so that's I think what is referring to here. Stephen, you have a question coming. I think in, in this for in this version of insights or this screen there is no way to do a fixed range. Or is it are you just saying to the last three months as the range. No, what I'm saying is so a lot of the other projects will do something like here. So they will do so. Yeah, and you can do a range there. Right. Right. They're linking to you can't do a range. So correct. That's right on this page you can't do a range. Right. And given that all the development effort has moved on to version two. It took some. I'm posting on my part to get a non creds and so laying added to this list. Because they don't want to do anything on the old version. But yeah, that's, I don't think I can get that feature in. Can you get our twisting to get them to do date ranges on version to. I have already twisted those arms. I assume you would have right. Any other comments. On the project reports. Oh, I was just going to comment on the issues with requesting LFX features. You can write does. A great job and puts in a great effort on that and. You know, unfortunately, we may not see that as soon as we want. Thanks for that heart. Okay, so there's no other comments. We are expecting actually three. Different reports to come in. Hopefully today. They're due today. The grid transact and so laying reports are due today. And then cello is due next week. So we will be on the lookout for those to come in as pull request. So for discussion items, I didn't have any specific to see. Discussion items. Okay. So, you have on the list here to talk about the project past best practices. Task force. But does anybody have any discussion items that they would like to talk about? You'll see related before we get to the task force discussion. Such a quiet group this morning. Okay. So that's a no. So Dave, I guess we are handing the floor to you. I know you've done some work already on project best practices, but I don't know what you're talking about. Okay. I will share my screen. Do you see it? We, we do see it. Yes. Okay. So this was an initial brainstorm. For what we want to do around the project best practices. I've tried to define a short objective and expected output. And then I took my first stab at. What I would, what I had in my mind at least for what this. Project best practices would be. You know, I would like to see it as. All encompassing. But, but rather shallow. And my target was really, I kind of had in mind a new project or a new maintainer. That's coming on board and they don't know what to do. So I know when I became a maintainer. I really didn't know what I was doing. And I took me several years to even realize how much I didn't know that I didn't know what I was doing. And so I think that the, at least the universe of expectations. Guidelines and best practices would have really helped me. And so let's, let's walk through the objective and the expected output first, and then we can go through. We won't get through the full list today. I'm sure, but we'll, we'll step through some of these. Not sentenced by sentence, but maybe section by section. And that's kind of as a working session. We have not had a meeting within the task force yet. I thought we'd do an initial one here to kind of. Get the ball rolling, make sure we're all on the same page in terms of objectives, expected output and so on. And then maybe we can have some smaller group meetings to make some more progress. But let's see how far we get today. Okay. So for the objective, let's read this. It's pretty short. The project best practices task force and tends to gather existing project guidelines and best practices in one central place and identify gaps that may be addressed in parallel or future task forces. And then the output I'll also read, and then we'll pause for some feedback. The expected output is a centrally located concise reference document to make project maintainers and contributors aware of the universe of project related guidelines and best practices. Along with links to the various resources available to them for further learning and adoption. Follow on targeted task forces may be proposed. So does that make sense at a high level to everybody. So Dave, just a question from myself. The. The intention is that we will publish this. To the TSE hyperledger.org is that the intention? I guess that's the next sentence that I didn't read. Yes. So this wiki page is for initial brainstorming and collaboration amongst us. Eventually I think we'll publish a document kind of like this. Over to the TSE hyperledger.org. Yeah. Okay. Part. And so Dave, thanks for putting this together. Just to clarify. So what you want this to be is you want this to be like a document for maintainers. To learn about best practices. Rather than a task force that is going to, you know. Suggest new best practices for a hyperledger. Is that correct? Well, I think it's both. I think, yeah, the outcome should be something for maintainers to be able to see the best practices. But I think to get there, we have to go through amongst ourselves and figure out what those best practices should be that we propose to maintainers. So we have, we have a lot of things already. And so the first thing I wanted to do with this is just gather up those existing things. Oftentimes there's something like, you know, the common repository structure where I say, Oh, I know we've talked about that in the TSE, but I can't remember where it is. So one thing I want to do is make this kind of an outline or index of some of the existing content that we already have. I don't want to repeat anything. I want to mostly provide links to those things, but just have a all encompassing list where people can see that like the universe of things that we've decided on. And some of these will be TBD. And maybe even when we publish this, maybe some of them will be TBD. I think that's fine. Yeah, that's great. I just, I think it's best if the, you know, if the task force scopes are kept in sort of bite size amounts. Right. Yeah. Yeah. So that's the part about follow on task forces member proposed. So I thought we would do like a one quick, one quick pass through kind of an overall scope. And then where we want to have deeper discussions or where there's not consensus yet spawn off task forces for those. And some of a lot of those exist already to be honest. I don't think we need a lot of new ones. For example, I'll call out. A disclosure task force. We have a security artifact signing task force. We have documentation and onboarding task forces. So a lot of these task forces already in place or have been proposed at least. We might need one or two more follow on task forces. But yeah, the intent is not to do, not to define every single best practice in the world in this task force, but to just kind of do a quick overview of what we have, what the gaps are and what follow on task forces might be as well. Great. Yeah. Thanks for clarifying that. You know, that's great. It's. Relatively, you know, small in scope. It has a useful output. And, you know, you can take the deeper dives in future task forces. Right. Awesome. Right. One of the things that I was thinking of for, for this would be. To try to use the, the breadth of the community to find the best. Example of each thing. So where one project has focused and done a really good job on documentation. Highlight there as an example and, and get them to write out how they did it. Here's one that has a really good. I mean, I don't know. I don't know. I don't know. The ICP pipeline that produces, you know, multi-architecture container images. Here are the GitHub actions and things that they did. And try to. Truly find that best practices. Across the projects and just see if we can. Get the projects. To. To share how they did. I don't know if that's captured in this, but it would seem better than us trying to declare what the best practices are is to use the community to. Sort of crowdsource the best practices. Yes, that makes a lot of sense. So I didn't make that explicit, but you know, there's some things here like the RFCs where I highlight a few examples or the contributing docs where I highlight a few examples. I think it would be good to, like you said, makes figure out. Yeah. So I'm going to first take an inventory of what we have and then figure out which of these do we want to highlight as a reference best practice. You know, I don't really know how to do that with. Kind of the community crowdsourcing way. We can put it out there and see what's the suggestions there are. Or we can. In this task force, we can kind of look at these things. Maybe we review each of the contributing docs that I have here. And then we can sort of look at what we want to do. And then we can sort of read two or three that we want to highlight instead of the six or seven that we've got. One of the, one of the things I was thinking was sort of a survey across maintainers. Sort of says, do you do this? Or how well do you, does your project do this? And, and list all the things and. You know, range from, I've never heard of this too. We're brilliant. I think that's a good idea. Yeah, maybe we could. Put out a note saying, if you want to be considered as kind of a reference model. Let us know and, and, and show us where you, where you're keeping your, your content. I think that's a good idea. So any other comments on kind of the overall objective and output. So. Operating models also. Right. Is it not like how. Maintenance should be how frequently maintenance should be meeting. To connect in triage. How they should be managing, let's say a certain explosion of contributions. And these are all things which people may not, may or may not be prepared for, depending on how much experience they have with the, like collage. Yeah, I'm open for anything that being said, a lot of things we kind of deferred to the individual projects, but if there's things that we think would be helpful as guide, either guidance or a best practice, we can surely keep that in here. I think like if some of the lessons. Let's say you've gained as fabric is one of the most mature hyperlinks. I think that's a good idea. Yeah. I think that's a good idea. Let's say you've gained as fabric is one of the most mature hyperlager projects. That would be quite useful, like what lessons you learned along the way. And I imagine fabric. Operations have reached somewhat queers in state, right? I mean, you have particular operation operating model, which works for you. Given the kind of maintenance you have the ones that are at least regular. So I think that might give other projects a lesson. Yeah, we do. That being said, I'm not sure everything we do is the best practice to be honest. But yeah, I can certainly share. Okay, if there's no other comments on objective and output, I think we'll start going through some of these sections. The first few I think are pretty easy because they're just pointers to existing guidelines. Like I said, I wanted this kind of be an outline and index, even to existing content. So we have maintainers guidelines. We have a common repository structure and we have inclusive naming guidelines, which I think are pretty, pretty clear if you read each of those documents. I've at least highlighted what's in those. So people see at a glance what they can get if they, if they drill into those documents. So I don't think we need to spend much time on this unless everybody has a comment here. So Dave, I think on the first one, the maintainers guidelines, I like the maintainer responsibilities. I think that's a good question. I mean, Stephen, you had just asked about that, right? Is there any place that documents could maintain our responsibilities? I think in that document, we were pretty light on what that means, right? Like you should include something in your documentation about this, like how that, how they deal with maintainer calls and quarterly reports and things like that, right? But we're not very specific in there. It's a very short paragraph, maybe one sentence. Is there. And maybe this is a, you know, out to a separate task force, but is there something that we should be doing to expand what is in here? That's a good point. I think some of the best content is actually in the actual example projects. Some of them do a better job of defining the roles and responsibility of a maintainer. And we could grok those and, you know, do that and bubble up some of the most important line, most important guidelines and best practices and put them in this section, for example. So if somebody wants to volunteer to do that, we could take names even at this point. If somebody wants to, I don't know if that's necessarily it. We need a full task force for something like that, but we could. Definitely not a task force. That's a pull request. Stephen, did you just volunteer? I'll see if I can get somebody. We were planning on doing that on our team because. Somebody was. Looking for that in one of our projects. So. I love volunteering. I do it a little bit. Yes, I, I don't mean to volunteer either. But I had a question and I'll need to, you know, if it's too much into the details of the weeds here, feel free to stop me and not ignore me. But, you know, I always wonder. I mean, one of the things that I think it, you know, I always consider, yes, you become a maintainer. It becomes a high priority for you to. Review full requests that are being submitted to the repo. And I even have claimed before that it becomes a higher priority than. Submitting new pull requests. Because my basis for this is well. Nobody else can. Other maintainers, of course, but that's it. So you become bottleneck and if you don't make it a priority to review and. And merge other people's pulls request, then. You kind of become the blocker. And so. I know this, you know, I've said this before publicly and I have had some pushbacks. And, and I was wondering if, you know, what people thought about this. I absolutely agree to be honest. I put that here as a comment. 100% agree. All right. I'm glad. Thanks. Okay. Yeah. So if we agree just to finish, I, you know, I think it's important to spell it out because I think people should understand that when the, when they apply or they, you know, want to become a maintainer that it's well understood that this should be an expectation. Thanks. Makes sense. Yeah. I think we could defer that to. Yeah. Yeah. Thanks. Thanks to Steven's pull requests and we'll. Further discuss that when the pull request comes in, but hopefully that'll be highlighted there. Could someone pass a link to the page where that. To the repo. Where in the repo that. Documents found. I don't even know where it is. I'll put it in the chat. Steven. Appreciate it. Okay. Let's keep moving. So like I said, I wanted to kind of do a high, low pass. And then we could. For like, for like, like the one we just did, we could figure out a next action in terms of whether there's a pull request needed or maybe that's large enough, a task force. So the common repository structure, I think this is, this one's in pretty decent shape. So I think just a link to it is good enough. Same bear have any comments on this one. Do you want to meet well? Or we leave that to me. We have attempted to enforce this through. I forgot what it was called, but it's some tool. And we decided not to. Enforce a tool at that point. Rather just leave it as guidance. Okay. The inclusive naming one. So this isn't a. This isn't in our GitHub. It's actually. In our old wiki as a decision, sort of set of decisions and recommendations. And this has been in our reports for a while now as, as questions to make sure each project has filled this one. So maybe I'll see anything needed for this one. Okay. Hold on. Peter. Yeah. It was a last minute realization that. Not to bug what I created, but we could also at the. Decisive and kind of action there. Now that's a certain recommendation. For. The rule, but there's a. An optional advice on how to easily. You know, make sure that you have compliance with the inclusion. The guidelines. Oh, it's sorry. Could you hear anything that I just said? I heard it, but I didn't quite capture the beginning. So was there a, what's the, what's the net. The net of that please. I think I was speaking the wrong microphone. There's two of them here. So I'm saying that as an optional recommendation, you could put down that if somebody wants to make it easier and they can use the DCI lent GitHub action. Which they can just configure for a project out of the box. And then it checks on every pull request letter. The source code is still up to you. The guidelines. So there's an existing GitHub action out there you're saying. Yes. And what's it called. DCI dash lent. I can add the link to it with the documentation on how to set it up. Optionally use GitHub action DCI lent. Does that make sense? Yeah. Yeah, that's all I had. Yeah. This is not a best practices comment as such. It's a comment about what we found when we were merging. We were into cacti. We have some code samples. Or other some dependencies with Corda, which is outside the hyperlager ecosystem. And. Corda has a lot of these words that we are trying to. Transition to new words and. We have no option but to retain them. So just a comment that at least until. As long as those dependencies lie cross. And then we'll have to sort of create exception. I've talked to Peter about this by the way, he had the, the DCI lent action was already configured in cacti. And we are going to kind of carve out some exceptions. Very narrowly targeted exceptions for those. Those paths. Just a comment. Other projects might be the same situation. Okay. Thank you. All right. Let's go to the next one. This one is a little bit different category because. This is the project incubation extra criteria, but there are a few things that are in this one that I thought would be good for new maintainers, especially if they're trying to exit incubation. To be aware of. And then the other note I wanted to mention was as we finished up this task force that does the first pass of all these things, we might want to take another look at the extra criteria and figure out, is that still the best list? Or are some of these new best practices. I don't want to recommend for the project incubation extra criteria, but that can wait. And so maybe we'll circle back to this one. More towards the end of this task force, you know, in a couple months. All right. So that's the end of the existing content. From this one down there, everything is new content. Some of them we have task forces that we're going to be spinning up like the security task forces and the documentation task forces. But each of the remaining ones here knew that I thought we'd spend a few minutes discussing to see if there's agreement on what I've written here as in terms of the best practice, or if there's other insights or bullets. The team wants to contribute here. So for project governance, we really don't haven't said much. I don't think at the TOC level or hyper ledger level in terms of what we recommend projects do. So I think that's one of the projects that I've implemented RFC processes, which I think have, have been very valuable. If I'm, if my, my history is correct. I think sawtooth was the first one. And Ursa and grid adopted the sawtooth RFC process. Which is, which event, which, which initially began from the rest RFC process. I think that's where sawtooth got it. Then fabric latched onto that. We liked the sawtooth model. We've evolved and extended it a little bit. So I think these are all good examples of RFC processes to help with decision making among project maintainers around major decisions, features, design, and so on. And I think it really helps to have something in writing, kind of helping to move that process along rather than just conversations. So open up the floor for other comments about project governance, best practices. Mama. Yeah, I just wanted to ask, are we supposed to spin off the RFCs into a separate repository? Yes, I think that's worked well for sawtooth and for us in fabric. Okay. You've done that. Thanks. David. Should we be including in this community license specification. Sorry, community specification license. For those not aware, that is the specification version of an open source license. And so maybe part of the best practices is these RFC repo shouldn't should be operated under the community license. So that's one. And a second comment is, I don't know if these are being published anywhere, but it would be. It's really hard for a newcomer to come in and find relevant information. And so we've long had a desire to publish the information using a, you know, make docs or something to make it. Much friendlier for onboarding people. So anyway, I don't know if anyone has done any publishing of the RFCs and provided a way to. To navigate them in a useful way. So just throw those two things out there as things that we've found would be helpful. For the second one and fabric, we have enabled GitHub pages for the RFCs repository, which is a little bit more navigable than just the GitHub repo itself. I don't know if that's what you meant or if that would help. I mean, yeah, exactly. It'd be good to see that because we're not doing it yet in areas RFC, but man, I would love to. And I'm just trying to figure out what's the fastest way to do it. What's the easiest way to do it. And I didn't capture all of the first points. So open community specification license is a. Open source license. So a vented license. For. For undertaking specification work and basically all of these RFCs are essentially specification work. And so just like there's a, you know, an Apache 2.0 open source code license, this is for, this is a license for. Developing specifications and we, we came across this and doing it on credits. I don't know if we're entirely using it correctly, but I think it would be a good. I think it would help to put these under a, under that kind of license. And again, it's, it's for IP protection basically. And so that would be a license that we put into the, each of the RFC repositories. Yeah, it's, it's, it's the license under which you're operating. So that your, your specification is using. Yeah. So, you know, I don't know, I don't know, I don't know if you're using any specification license version 1.0 and any open source code that happens to be in the repo is, you know, Apache 2 or whatever, whatever you're using. I can, I'll find a link to that. To the repository. Yeah, we can put the link in here, then we can look at that. All right. So I guess I'm next. In the queue. So I think as far as project governance, this is good. I'm wondering if there's other sorts of governance that we should make sure way less standard project governance. I think there's a couple that we've already talked about in the, like meet in the guidelines that are provided. So I'm thinking about like, how, how do you become a maintainer? What's the, what's the decision making for becoming a maintainer versus becoming an emeritus maintainer. There's probably things that are around what do you do when there's inactivity in either repository or that sort of thing. And so I'm just trying to think about, you know, what other sort of project governance might exist that we should be ensuring that we're including in the, in the list here. Tracy, do you mind if I jump in here? Yeah, go for it. So I'll just say on the last point. On Steven's point, the LF now does recommend that you use the, well, the legal team does recommend that you use the separate community specification license for standards and specification work. So I actually had a question, I asked them about this because it wasn't clear to me. You know, obviously there's some differences between standards and specifications, but I was told that for everything in that area, that's the proper license. So I just want to, you know, reiterate Steven's point and say that, you know, if you are putting out a specification, this is what you should be using. Tracy, I want to pull up on that. Yeah, go ahead. Can I jump in? So I think, I think this is, you know, what Steven said is a bit different from what you're saying Halt. And I actually, it never occurred to me, but I think Steven's point is a very good one. And just so people understand that, you know, big disclaimer, as you know, I'm not a lawyer. I don't even play one on TV, but there with me, you know, with that in mind, the big difference, right, is an open source license is basically it covers copyrights, especially the Apache to license, right? It covers the copyrights and intellectual property somebody might have in the code that contribute to the project so that they cannot come later on and say, hey, you're infringing on my patent that you have to pay some license fees to use it. And the difference when you work on the specification is you're just describing what the code essentially would do. And so there's a different, because there may be different ways of implementing it and so on. So the commitment is with regard to, you know, the requirements basically specified in the specification as opposed to a specific piece of code. That's why we need in general for specification and standards, a different type of license. So that's the background. So now what I never occur to me is what Steven is, I think has touched on is, in fact, when you think about it, RFCs in a way describe what the code is going to do. And it's similar to what a specification does. And it makes sense in that regard to say, well, given that it's similar to specification work, we should have a similar legal framework to kind of cover this work so that when people contribute to the RFC saying, oh, we should have a feature that does this and that do this and it can go into fairly pretty detailed stuff. Any kind of IP related issue has been covered already. So there is no issue down the line when it gets implemented. So is this something we need to just mention once in there in the repository or mention for RFC? So it's at the repository level, but it wouldn't require a change for the repository if it's not using it now. And so the people who have contributed to it should agree to this. It's not so easy to do afterwards, but you can do it from the get go and say, from now on, that's what we are using. But it's at the repository level. Okay. Does anybody want to volunteer to provide the exact recommendation to the projects around this? Can I jump in and say that if we want an exact recommendation, we can definitely ask the LF legal. Yeah, I was going to suggest something like this. So I'm glad to volunteer. So I can ask LF legal about this if you all want. Because I don't want us to like, this is definitely something you want to ask the lawyer about, right? We can conjecture all we want, but if the lawyer says something else, then that's the way it goes, right? Okay. I've captured that. Thanks. Absolutely. So maybe an additional add to the project governance is to document roles and responsibilities of. The people that are involved in the project. I think that we don't necessarily do a good job of understanding who's playing what role and what sort of responsibilities they have. You know, things that we might think about obviously maintainers, but release managers, but I think there's probably some other roles that might exist within the project itself. I think there's probably some other things that are based on just like, how does the project run? You know, and maybe that falls into the, the contributing part of the documentation or. You know, somewhere else, but I just, you know, I don't think there's enough that is potentially. Interesting to newcomers to the project to understand like how you would participate in this community that, that probably needs to be documented as well. And Tracy, is this something you're saying? We should leave up to the projects or is there some kind of template you think that we should provide as a starting point? I think in a lot of cases, the projects are already doing it, right? It's just not documented. And I'm, you know, perfectly fine to say that the, it's probably in the hands of the projects to decide, like when they meet and what they, how they run their project. We may want to provide some guidelines around that for new projects, right? People who, like you said, right? When you started, you didn't necessarily have these thoughts in mind to, to maybe give them some, some good starting point and then they can evolve as the project grows. Okay. Makes sense. Yeah. Hart. Yeah. Thanks. So I think this is really good. I would say for some extra roles, I would say there's responsibilities. I would say road mapping is a big thing here. Sorry. Can you all hear me? Yes. Awesome. Yeah. No, I had messed up my microphone. Yeah. So I would say road mapping is really important here. One thing we get a lot of questions about is how do I, how do I affect the roadmap? Like if I want to see in something done in some project, what's the, what's the way to do that, right? And, you know, as to Dave's suggestion, you know, I think like a template is good. I generally like the approach of providing projects a template and saying like, this is sort of a default thing to do. You know, if you're an expert and you have a good reason not to do it, then, then great. But otherwise, you know, this is, this is a good way to start. Yeah. And I'll just add to that. I think, you know, our inactivity or maintain or inactivity policy at the top says like, if the project has one documented already and it's working well, like this is, you can continue to use that. But if not, this is the one that we use by default for the, all of the hyperledger projects that don't have one. And then I think, you know, as far as other, there was one other thing that popped into my mind around what happens when people go away, right? Should there be some sort of process for like announcing that you're stepping away and, and that sort of thing because I think in general, for some of the projects that have gone dormant and then end of life, it's been because the maintainers have stepped away and maybe people didn't realize that that was happening. And so I feel like there's some sort of best practice around just being open with, you know, the amount of time that people are willing or able to spend on a project and if that time is going away, then letting people know that, you know, they need to step away for whatever reason it might be, right? And they don't have to tell us the reason, right? But just that, you know, I need to step away for, for the time being and either I plan on coming back or I don't plan on coming back and then people can make some decisions around, okay, how do we get a replacement for this person or what's the kind of next steps that need to happen? Okay, so each of those are kind of larger things. If we wanted to produce some kind of template or starting point for projects to utilize or a fallback, if they don't provide one, maybe, maybe that is a task force in itself. What do you think? It probably is, Dave. I mean, I don't know if it'll take a long time to do those things, but yeah, very well, maybe a new task force. Does any project already have this sort of information? Anybody aware of this that we could like take a look at and maybe use as a default template that maybe then it wouldn't require a task force? The best thing I've seen is this one around sawtooth governance. It actually went into like team structure, decision-making procedures and things like that. So it was kind of an addendum to their RFC. So that would be at least a starting point, I think. We have something similar. Sorry about that. I'm making coffee. We have something similar in the non-creds as well. The non-creds stack was based under community license and has a governance document about what the editors are allowed to do and so on. So I'll take a look as well at the sawtooth. I don't want to volunteer for everything. Well, at least put the volunteer to put the link to that in here. These are the things that I have been working on. So, you know, I do have a fair amount of experience. So I shouldn't be stepping up on these ones. So all good. Okay. With 13 minutes left, do we want to start the community section? This one might take a little longer. I guess we'll start and see how far we get. Okay. I thought we'd open with kind of, it's obvious to all of us, but maybe not to everybody else. But first and foremost, foster a welcoming positive and public environment where contributions are encouraged. Is that a good opening line? Yeah, I think it is. Okay. So, wasn't there a recording that was done by somebody in. Is it Sam? That they're recording. That was. Basically how you, how do you do some of this? Why do you remember? I was going to ask Daniela, but it looks like she dropped. So. I don't remember. I'm. I'm sure. I can search through YouTube and see. So there's a presentation kind of about this topic. Tracy, that's what you're saying. Yeah. Yeah. That's what I'm saying. So we'll see if we can find it. Okay. And then for kind of the specific aspects, I called each one out and I thought we'd put a bullet around each one with a short, some short guidance. So for mailing lists, one thing that I was thinking about, we have one mailing list for fabric and there's, it's a combination of, it's mostly targeted for users or most mostly used by users. And I think one of the reasons why there's not much contributor and maintainer discussion in there is because it is kind of, you get kind of overwhelmed with the user discussions. So what I thought we might want to do for fabric itself and maybe as a recommendation is to have one mailing list for users and another mailing list for contributor slash maintainer discussion. Does that make sense? Do you need a mailing list for contributors and maintainers? Can, if people have any issues or they want to propose something, can they not open GitHub issues and can I have conversation there? They can. I guess that's the broader topic is where should, where should primarily these discussions take place? Mailing lists or discord. There's also GitHub discussions. And like you said, GitHub issues. I think each project kind of gravitates to one place. Right. I mean, it just seems to me if you have a meeting list for all contributor maintainer discussions that amalgamates a lot of different issues into one meeting list and people can switch off. All right. Yeah. So I would say, I think ultimately the communication tool is up to the project. You know, whatever people want to use as fine, as long as it's widely communicated. And I would say, you know, on the issue of mailing lists, I don't know. Is there a compelling reason why you'd want to separate like a maintainer contributor mailing list from everyone? You know, I would assume you'd want to have as few mailing lists as possible unless you, you know, absolutely needed more. Well, yeah. So when the fabric mailing list was really chatty with all the users, it would have been nice to have a separate one. But now the mailing list isn't used as much. And so I think we can get by on one for now. I mean, could you categorize it maybe as, as more like, I guess it's like a technical or a non-technical list. Or like an application or a code list. Yeah. I mean, I, this, I didn't have a whole lot of conviction around this one. So I'm fine to drop this idea and just say a single mailing list is a good starting point. I totally get it if you're like overwhelmed with, with mail. But I think that's a like cross the bridge when you get to it. I think hard one of the reasons to have separate user list is users can have, can face problems that other users have encountered and solved. So users can fix other users problems and meetings don't have to be involved. But if it's a maintainer issue that's being trashed out, then maintenance have to focus their attention on that. So separation might be a good thing. I think it would be good if there's a lot of traffic, but I just, I just don't know that we have any lists where there is enough traffic. And as an aside point, that's one of the actually really good reasons why we find people using discord is that it's much easier to like look back in chat and see if people have had the same question as you rather than having to like search through the mailing list. Okay, so you, that's a good segue into the chat. So I mentioned here, it's, we need to, you need to strike a balance between too few and too many chat channels. That kind of is what you're talking about, Hart. Do we want to further tune this? So I will comment that when we did the chat task force a couple of years back, there was a lot of recommendations on the sorts of channels that you should have inside of discord by default, or at the start of a project. And then I think people have added to that as they've seen fit based on their project. So maybe we can point to that particular task force. Any other comments on mailing lists, discord. Okay, public meetings. The only thing I highlighted was should occur on a regular cadence. There's probably some other suggestions here though. Yeah, can I jump in here again, Dave? So one of the things that's would be would be nice as if projects had meetings that at least some, you know, that, that rotated time a little bit so that people around the world could join. We get a lot of, you know, there's some projects where, you know, they have a fixed meeting time and never changes. And we have people in certain regions of the world and are, you know, at least when I talk to people, if, if, you know, they want to get more involved in the community, I frequently tell them that it's good idea to join, you know, join the discord, join the chat, and join the project meetings. And this is sort of a hard sell if the project meeting is at like 2am their time. And this, this is the case for, you know, a number of different projects, right. So I like to incur, you know, obviously for small projects, this, this may not be necessary. But for, for big projects, I like to encourage them to have multiple meeting times so that people can attend no matter where they are in the world. And I think this, you know, for some projects, you don't, you don't know what you're missing until you try this. And I have seen some projects do like a western hemisphere and eastern hemisphere meeting. Do you think that works or would you think the rotating meeting times would be better? Up to the projects. You know, I think it all, it all depends on the maintainer structure. Okay, so we'll leave it like this, consider two meetings to cover different regions or rotating meeting times. Like, if you have a heavy US based maintainership, right, you might want to do two meetings where the you all that your US maintainers can attend both of them. But if you have like a truly global maintainership, then you might want to rotate between like, you know, US Europe, Europe, Asia and Asia US or something like that. We see both work. In a previous life, we rotated our meetings by eight hours a week. And that meant that the people in the US had one meeting that was in the middle of the morning. But certainly, if you rotate it by eight hours or 12 hours, you could cover most of the world fairly easily. Yeah, and I'll say that the eight hour rotation ones, the general expectation was that you make two out of the three meetings. You weren't expected to make all three. Okay, make sense. Yeah. Okay. Go on to meetups and workshops. So Jim reminded me that to put these in here. Sorry, Dave, I would like to just go back one. One step just to say something that just occurred to me is I think maybe a best practice should be for projects to at least provide a way for people who are, you know, who cannot join cause they would be interested in to express that desire. Because, you know, I think the problem is we kind of assume well, you know, they don't participate. They don't care when in fact, they may not participate because there is, they have no way to because of the time. And if at least we provided people a way to express that, I think would be a step forward. And it doesn't take much, right? It would be like, you know, on the, on the information that gets published with the project. When they say, hey, we are meeting, you know, regularly at this time and I have some notes saying, by the way, if this time is not convenient for you and you would really like to participate, please let us know, you know, whichever way. At least people would look into it and feel like, oh, okay, maybe I can try. That doesn't make sense. The project wouldn't necessarily have to go out of their way, not knowing whether anybody will care. If they change the time. Okay. So I wrote survey community about mess, you know, what is the meaning time consider two meetings or rotating meetings? Does that sound good? No. No, that's not what exactly what I mean, because I'm not saying, you know, a survey implies like at one point in time, you do a survey and say, hey, anybody interested. What I'm saying is just, you know, generally speaking, along with the information about when the meetings are held, people should have some kind of information on how to express that information. I think that's the reason convenient for them. And I, you know, maybe it's the group says, sorry, that's just the way it is. But I think it would be, you know, kind of giving an old branch of this big to people saying, okay, we have not considered the other times, but if you do, then maybe you have a survey. If there are enough people who express interest to have a touch different time. Is that what I mean? Okay, I see what you mean. I don't know how to best say that. I don't know if you're going to get it at any time, but if you've got a better wording here, you know, or feel free to edit the wiki afterwards. I think that's what I'll try to do. See if I can formulate what I mean. Okay. All right. We are out of time. So that's about as far as I thought we would get. I think we'll need another one or two of these. Probably two of these at least to get through the rest of the list as the first pass. Do we want to do this next week or do you want to just keep rotating between the different task forces? So I think we'll rotate to the different task forces. I think security is up next on less for some reason. The other task forces aren't ready to provide updates or have discussions. In which case we'll come back to you quicker. Okay. And we can also have the separate off channel meeting. Let's talk about this as well. Yeah. Okay. All right. Well, thanks Dave for taking us through that. I think it's looking good so far. And we will talk to everybody again next week. Okay. Thank you.