 Hello everyone. Welcome to the weekly TSC call. As you know, this is a public call. Everybody's welcome to join, listen in, participate. There are two requirements to doing so. The first one is to be aware and lead by the antitrust policy, the notice of which is currently displayed, and the code of conduct, which is linked from the agenda. So we have a fairly light agenda I believe today, but I wanted to take advantage of the time to try to make progress on some of the pending issues we have anyway, and for which we don't seem to get as much offline discussion as I was hoping for. So it's okay. We can use the online time instead. So, but let's get started with the announcements. I don't know that there is anything new per se. We have the usual reminder, but the newsletter, right? You want to do your spiel? Sure. It's a, it's a great way for projects to celebrate their successes. I know that a capy had a significant release in the previous newsletter, and we can't help you get the word out. If you don't help us, help you get the word out. So help us. All right. All right. Thank you. Is there any other announcements anybody wants to make? Okay. I don't hear anybody. Don't see any hands going up. So I assume there isn't. So in terms of quality reports, so we still have the cactus reports, reports. Sorry. On, on that's from the week before. I don't see any issues from what I could tell. Most of the TSE members have reviewed it. I didn't see any issues that required. Discussion at this point. We also got two new reports, namely from fabric and so tooth. I know they came in just a day or two ago. And so there's more mixed status there. We will just carry those over to next week. I didn't see anything that required discussion at this point either, but we'll give everybody a chance to raise any issues. Until next week. So I'll keep those two for on the next week's agenda. So let's get to this discussion. The main one I want to talk about, and there may be another one we can also tackle. We'll see. But first I wanted to get more into this incubation entry considerations. So. It's a, we had like three of our members. Four that really contributed to the document. And there hasn't been much comments beyond those like. Three or four people. I have personally read it and I have a couple of comments that I kept for this call. But otherwise I thought. You know, we should just take the time to read through this document together and decide whether there are any issues that need to be discussed or we can agree on what. The text says. So. Before I wanted to ask if any of body has anything specific they wanted to raise on this document. Or if not, it's anything her, you know, we can go through it as we go down the document. But I wanted to give a chance if there is anybody who has an urge to discuss a particular point to raise it now. Okay. I don't see a heart. Go ahead. Hey, I think I commented on this on the very end, but I was wondering if people thought we should have a community section as well. Obviously we want to separate this from the community requirements for active status. But it seems like we still probably want some. You know, we want some properties of a community, I guess. So I just, I added some stuff in there in a comment and I just was curious what people thought about that. Okay, so this is, you're saying there's an probably a new section, we have those sections today touching different aspects. And you're saying we probably ought to have another sections around the community. Okay. So let's jump to that maybe, or do we go through this and then get to that? I don't know. Whatever's fine. We don't have to do it right now. Okay. Let's go over what's already in the document and then everybody will be on the same page and we can see, you know, we'll have better context for the section you want to add. So let's get going. So at first, there's the goal that Arun. Has stated. Has anybody had any comment on this? I hope everybody has actually had a look at this document at least once. I'm not going to literally read every sentence of the document. I just want to quickly work through this. And like section by section, ask if there's anything that, you know, needs to be discussed or if we agree, then we just, you know, say, okay, this can stay in the document. And then by the end of this process, we should have a document we'll feel comfortable with. So, yeah. So one of the things about the goal question I have, it states any use, but that's not even a requirement that have used in active unless I'm remembering all the requirements. Okay. Arun, go ahead. Hi team. So I saw a hard question earlier today and I commented on that on this question in the comment section in the wiki. If you can scroll down to this page. So my intent was that we identify that there is high potential for this project to be in hyper ledger space, either it can be a demand from the community that, hey, we don't have a project like this. And so there is a high, high need for this project to be within hyper ledger or other thing could be. Showcase that this project is really in production. So I mean, to grow it further hyper ledger could be a good place to grow. So that's, I don't know about the exact words. I didn't know that these two words could cause confusions. We could probably rephrase them. All right. So by the way, right pointed out, I actually meant to do exactly that, right? So thanks for pointing it out. There is a new chat system that we're supposed to try out. So. Right. Put the link in the chat. Window of the zoom meeting. I invite everybody to click on the link. If it works. And we can use that instead of the TSC. Right. Okay. Okay. We have a new no-profit chat channel we normally use. In the background. Thank you. Okay. With that. Dan. Let's get back to Aaron's point. So. I do agree with a bit with Daniel that, you know, I don't know that we've ever asked. Whether. You know, for project to be in use. And. Even less so like, you know, we ask some evidence of that or is just to claim good enough and does it do us any good if I wanted to, I can always claim that that's the case and I don't know why we would go to proving it anyway. So I'm not completely sure this is actionable per se. Tracy? Yeah, I think the in use phrase in that sentence was also something that caught me. And so I guess I was trying to see if in my mind I could combine conceptually and implement it in use to reflect the fact that, you know, if something is just an idea, it's probably better to start that in a lab space than it is to start it in as a top level project, right? But I do think that the in use phrase is definitely a question about what exactly we mean there and how do we enforce something like that because it could very well be that the developer who is bringing this to the TSC says, well, I'm using it, right? Is that enough? You know, there's no real point at which we would say, oh yes, this is something that is used by five people or 10 people or 15 people, right? What is that magic number that we would say? Yes, so I agreed to this as a project that is in use and makes sense to me. I think it's very subjective. And so I would recommend striking at least the in use portion of that goal. Okay, Daniel? Yeah, I agree with a lot of what Tracy said. I think one of the concerns I have is we don't wanna introduce standards that are probably appropriate for active status. You know, I think that the evidence of community use of actual production use, I think is a good one but I don't know that incubation is the right place to bring that in. And the standards you get are kind of, you know, how do we go about that? And, you know, if we could rephrase it too loosely, it just becomes, you know, the appearance of a standard but really it's the whims of the TSC. If it's the whims of the TSC, let's just leave it at that. But I agree with the premise that proof of concept is a good stage for bringing stuff in incubation. If you just have an idea that you should make sure that it works in at least one iteration, even if it is on your machine. And labs is the right place to pursue ideas. And incubation is the place where you start productizing those ideas into what would be an active project eventually then you have a path to get there that people reasonably believe. And I mean, one other data point, I mean, looking back, it's pretty clear to me that, you know, most of the projects when they started, they didn't have, you know, definitely production use. I mean, way back at the very beginning, obviously, everything was brand new just out of like development, still, you know, I mean, we didn't have enough in a kind of major version. When you think about the first project that came in with this fabric, so to any of those, they were really early on, so to just came out of research at Intel, right? And they didn't have anywhere near, they were nowhere near production use. So I think we need to be reasonable there. And indeed, try to, if I would agree that, you know, if there's no code at all, then I would agree and say, well, go do this in the lab. But if there's already code and you can already play around with it, even if it's not in production yet, I think incubation seems to be the right spot to be in. So does anybody disagree with that? It seems like, you know, those who have spoken basically are saying, let's drop that pot hot. I was just going to comment that if we are going to leave things sort of at the whim of the TSC, and maybe, you know, like is a project relevant, is something that's hard to define, we should write some examples of things that are sort of like clearly relevant and clearly not relevant to sort of give people guidelines. Okay, yeah, we can illustrate a bit by giving some examples. All right, so can we go back to the beginning of the document please, right? And let's see if we can change this then to something we can agree with on. Would you prefer to share your screen so that you can type? No, I mean, I'm not claiming to be the master, the document for that matter. Okay, well, I'll- But I mean, and this is editable by all, right? Yes, yeah, everyone, you know, feel free to jump in and edit So can we agree to just drop any news? We can say the project shall be conceptually implemented, although that alone may be loaded as it was pointed out. Do we have to define what that means? Is your hand up, Hart? Oh, sorry, I meant to lower it after the last comment. Okay, so I'm proposing to just drop any news. Anybody disagree with this? Can we leave with this sentence? And I for one don't really understand what conceptually implemented means. Okay, so Arun, you wrote this. Can you explain what you were thinking about? Right, so when I wrote this, the thought was very simple. When a new project is proposed, it should not be just a thought that, hey, I can do a project with an idea like this, right? And for example, let's say somebody comes and says, yeah, I have a cool new project proposal which is like a multiparty system which would do something else. Now that Hyperledger is allowing multiparty systems, I would be doing these XYZ things. So I need a place, and I think this is the name of my project. So I'm coming to Hyperledger. So that's what I meant with conceptually implemented. It is to say that, hey, it's fine, you have an idea. The project is well-documented or well-approached towards it. However, for you to come and collaborate here, there should be something that you showcase and it should be in reality, right? And it should, when you say you are coming and proposing that project, it should be, it should have those things that you claim in the charter, projects charter. So we already have that next section on the code base. I mean, that does imply there is some code. Do we need to say more or isn't that enough? It says the code should exist as open source software in some form. And to me, maybe that's good enough. The rest becomes very subjective as to how much code there is, how much does it cover from the goal of the project? And then we, I don't know that it adds much to have that sentence. Maybe we drove the whole sentence. We need to have code to start a project. That's what we're saying, yes. I think for incubation, yes. If it's just an idea and code is being generated, I think labs or governance outside of Hyperledger might be a better place to do it. I personally would expect something to get booted up and run and say, oh, gee, that's neat if it's gonna come in incubation. Mark, do you think that's too much asking? You would think starting on an idea alone is good enough? I'm just wondering about efforts, I guess efforts that aren't code tend to be working groups or six. So maybe, you know, maybe this will help with the distinction between them to say projects need code. Let's see. Have we had a lab or a project that's come out of a working group or a task force yet? If there is, that would be an excellent example to put into this documentation. There have been labs from SEG, yes. They haven't, yeah. Tracy. Yeah, so I did make a edit so that people can see it on the screen with a suggestion of what we could change it to. So don't know if this is where we wanna go to move us forward or if we still wanna keep discussing the same thing. No, I'm happy to be with that. Thank you for taking the lead on editing the document. Bobby. Hi, just speaking from the Learning Materials Working Group, we had two projects, the university course and the starter lab go into hyperledger labs. And we're also working on a third one, which is the giving chain. So in my interpretation, we're going to go through the lab process first, copy code from one of the blockchains and tweak it for our project. And then we're going to test it on a project day. And if that works, that's when we'd probably do the steps for incubation. So that it's been kind of proof of concept once. And if it works, we would move it out of the labs. If it doesn't, we would still continue in the labs until it does. All right, thank you. Yeah, that seems too much other people's expectation. So now I'm wondering whether we should still have something about the code, given what we just said with Mark and all. I mean, I mean, it is a way to have a distinction. This is the expectation of a project is that it will have code, a project in incubation. Maybe we just put something about code for the project already exists. And that's it. We don't get into, you know, how much code. We just say there's got to be some code that exists. And then of course, if somebody comes with two line pieces of code, we're going to laugh and say, sorry, that's not good enough. It does seem like a strong pushback on the last proposal for entry into project incubation was based on code being available, but not having been publicly open source for a while. It wasn't even available at first. We had a push to get an open source. Right. Yeah, no, so let's be clear. I'm not saying to drop that thing, that sentence about the code base being open. I'm still talking about the goal, just adding something about the fact that the code exists, which now we have lost entirely. We went from the project shall be conceptually implemented and in use to nothing at all, which I'm worried that we're missing the distinction we've been stressing, which is that and for labs, it might be okay to just start with an idea, but for project, there should already be code that you can use. So I would like that to be present in that sentence if that's the main statement we people will look at. We've never incubated a project without code, right? That's the point. So I think that has to be in there in that first sentence. Tracy, is your hand up? Yes, my hand is up. Okay. I think we're confusing goal with the criteria or the considerations. I think the goal of, I think as I read a goal, it's the goal for incubation. What is incubation? It's not the considerations. And to me, the considering that the very first thing is talking about the code base and code should exist as a consideration. That seems to, I don't know, just seems duplicative. And that's a good point. Not goal-like. I think that's a valid point. So with that, I'm happy to leave it as is then. Okay, I'm really happy with the goal. Can we move on? So let's get to the code base. I mean, hot, I suppose that do you have, we have to, sorry, yeah. Can we get rid of your comment there? That's exactly what I meant to say. Yeah, go ahead and delete it. Okay. So the code base then added a bunch of points about the code being actually to exist as open source. There's a piece on Apache software license. I mean, is there any of this that anybody wants to discuss? Or are we happy with what's there? Or is there anything people want to add? So hot raise the question. Yeah. Can we just move the Apache 2 stuff under legal? It's probably a better fit there. And we can talk about other stuff as well, like dependent licenses, which are always a thorny issue. That sounds fine. While that's being moved, I don't think we should have CICD requirements in there because they won't have access to Hyperledger CICD and that's really what matters. And I'll add to Dana's point that actually obtaining the CICD is like a big incentive for people to apply for incubation. You mean, yeah, that's not something that's available to the labs. And so a project moving to incubation will get this as a benefit. So yeah, it's a bit unfair to request people to have that if we're not giving them the way to do it. The means to do it. Do we need to let people coming in know that that's expectation that they will have resources to handle CICD and things like that? I'm assuming Rai doesn't do it for every project, right? Yeah, that's old Rai. So you've touched on a really thorny issue that I am holding my tongue on because I don't want to divert this meeting. So let's just say that CICD is difficult and not drill into it very deeply in this meeting, please. Okay, sorry, sorry. This is the fact that it's not part of the labs, right? My goal would be that everyone migrates to get of actions and then labs get to do it for free because everyone gets to do it for free. So yes and no. The part that isn't is publishing to Docker Hub except we do allow labs to publish Docker Hub so there's not much incentive. There was a bunch of incentive when we were spending a lot of money on CICD, now we aren't, so. Okay, thanks. I think of a higher level goal of mine which is to never have a resource limit or a budget limit be a reason why we have to say no to taking on a new project. That's a goal and it's an ideal. Maybe ideal is a better way of phrasing it than a goal but I wouldn't want that to be a reason why somebody said we can't take a project on. All right, Chrissy. Yeah, so I assume we're talking about Arun's comment here in the code base. I'm wondering if, I mean, we don't have this checklist today. I'm wondering if we can take these individual ideas that Arun has put out here for the checklist and put them in the correct spots, right? So like DCO requirements would fall under the code base, the file structure repo requirement would fall under code base. Licensed copyright is probably illegal. I'm not sure where the release process goes but maybe that's under the community section that part one's to add. I agree with you, Chrissy. I think that's a very good point. I had the same thoughts when I read it yesterday. I mean, Arun, there are a couple of places where you refer to something that's yet to be defined and as if it's gonna be defined elsewhere. And I think we should instead define it right here so that we don't have this kind of interaction like this in this case, the checklist. Like, well, no, just put right here what you would have in that checklist. Yeah, no hard comments. The only reason why I put this over here is because this was related to code base and we had to make sure that these are met as part of the code base that is being brought in. Sure, I guess it makes sense. We can move them to appropriate sections and at the end, we could probably have a checklist for somebody and ask them few questions. Hey, have you done this as a reminder? Yeah, great. So for DCO, are we expecting that they're actually gonna have to have done the squash recommit if they don't have it in their full history before they sign off or are they supposed to do DCO the exceptions with lists and hashes that don't have it? I mean, are we expecting to do that before they propose? We're expecting that to happen pretty quick when they come into incubation. Good question. Tracy, you have an answer to propose. Your hand is up. No, I was going to make a comment and something else, I was gonna bring up something else. So I'll let other people comment on that and I'll leave my hand up until this is finished. We may need to actually have a conversation with LF Legal on that particular point with the DCO. Yeah, but Daniel's point, I think is valid, is that if people just want to make a proposal and imagine we say no, maybe they don't care to go through the old DCO stuff. So should the DCO be a requirement to be able to get into incubation as opposed to something they have to do as part of like importing their code and the, you know, once they have been approved? In the task for projects before DCO never existed before the project came in, but you needed to be able to pass the DCO requirements as part of bringing your code in. Right, and that historically that meant a squash commit. If you look at the Hyperledger archives org in GitHub, that's where all of the pre-squash fabric repos live so that we didn't lose that history. So I think it's reasonable to say you can get into incubation without actually doing the squash or doing the DCO piece, but when the code comes in, it needs to be compliant. I see Grace and Tracy still have their hands up. So Tracy, I suppose is still for something else. So I was keeping Grace maybe wants to react to what's being talked about here. Yeah, no, I just want to echo, right. I think it's fine to or my proposal would be what Ry just said, which was, you know, it can be as a, it doesn't have to be done before they are approved as an incubation project. I think that's reasonable and has worked all right in the past. Okay, so Tracy added, or is it Daniel wrote a sentence? I wrote it. To clarify, giving a bit of leeway as to, you know, whether the DCO sign off exists or not. I think that's reasonable. It sets the expectation and it doesn't make it a hard requirement to have the DCO sign off already in. It just is important information. I've seen other projects start doing DCO that don't have Linux foundation connection. So I think there's a chance we could see projects come in that are DCO ready. No, my question is going to be, does that really belongs to the code base or does it belong to the legal part? I think that's the challenge of these different sections is some things kind of overlap. Practically everything code bases is what it seems like. I'm assuming anything coming in from a lab would already have DCO. Yes, they should. I mean, we do request, we enforce that very requirement when they bring a new repository and they're instructed to keep the DCO sign off as they progress. I don't know, you know, so yeah, they should be in position to do that. Yes. Of course, we know the police, we don't go after them and check that they actually do it. So there may be cases where they say, oops, sorry, we forgot to do that, but at least the expectation is there. So repository comply with the common repository structure, I think is an interesting one. I also wonder whether this is something that couldn't be led to the incubation phase. Yeah, so no, this is where my hand was up. When I typed that, I was like, I don't think this is actually incubation criteria, even though it was included in Arun's comment here. I think that it's very possible that somebody comes in without having compliance to the common repository structure and then upon entry, they would add the required files. So I feel like this one, as well as the copyright one that I added under legal is really more upon entry, right? It's not something that we would consider and reject the project because it doesn't have the common repository structure. That's also my feeling. I think there may be things for which it's a must, like the copyright and the license, that you would expect the project to have that made. Could I propose that the TSC use the same requirements for the CRF as they do for existing projects? I think projects had two quarters to get into compliance or two quarterly reports to get into compliance with that. I mean, wouldn't that be a reasonable thing if you're bringing in the code base to say you have six months to get this stuff in shape or like your second quarterly report? All right, that's an interesting idea. So it's somewhere in between. We don't ask them to have it done to enter incubation, but we don't want to wait until they graduate for that either. So we kind of force them to do it in a, you know, shortly after they start the enter incubation. I like that proposal. Tracy, your hand is up. Sorry, I think I didn't order it. All right. Although I don't, I don't know that we need to put anything in this document. So Rune, I don't know that we actually need to put any statement in this. I think we could add it to the project checklist if it's not already there that already exists. Right? So yeah, I agree. I don't think it has to be here, but we somehow have to make sure it's captured somewhere. So I don't know where that is. We would, we should check. So I know it's a little off topic, but it ties in. I think all these things we're discussing would be requirements to get to graduating state. And so I think if we have a clear list of, you know, I mean, for existing projects out there coming in, you know, this could be why they're an incubation is to get all these things done. Does that sound reasonable? That's what's happened in the past. So I think you're questioning reality. Yeah, no, indeed. Okay, is there anything else we want to take from that point from Rune? Yeah, I would just say that all of these items are probably items that should be part of entering active state, right? Because I think the release process is even one of those things that, you know, in the past, we've had projects that have come in who haven't necessarily done releases in the open, if you will, and have had to figure out as a community how to really work through the process of doing releases. And so I would say like that's probably, if you're not doing releases by the time you become active, that's probably a reason not to become active. Yeah, I agree. So Rune, may I suggest you move that point to maybe the comments or at the bottom as a note or something we need to check that these things are covered as part of, you know, maybe the executive criteria for incubation, maybe something else if the case might be, but we don't have to have it there. I don't want to lose it because I think you're making, you know, these are important aspect, but I think they are not part of this entry considerations. So let's move on to the maintainers section. So there, I don't know that everybody is in agreement on the points that have been put forward. So anybody wants to speak up? Dhanu, go ahead. So I think whatever we do in the maintainer section should reflect what has actually happened in previous proposals. I know we have rejected a project for having only a single maintainer, but I don't know that we rejected a project because the proposed initial maintainers were all from one company. If there is, then I think, you know, we can go with that and should document examples of where that happened. So I have to admit not to know the answer which way it is regarding the history. I know that we, and this somewhat relates to, you know, there's been this question about sponsors and, you know, people committed to the project and there was a bit of confusion, I think rightly so, because it's not defined currently. Like what's the meaning of those things? What I think has been the case for the most part at least the main projects where they were at least two companies saying, yes, I think we should do this and I'm committing resources to this. And, you know, you can then debate whether they, you know, they live up to that commitment or not, at least to the extent that someone might have expected, but at least on paper at the time, they made the proposal, there was this expectation, this commitment. I think it's, I feel like this might be more important than specifically the maintainers aspect. So maintainers, let's be clear. I mean, what does it, you know, what does it translate to if there are, if there's more than one maintainer? What does that, you know, represent? Practically speaking, that we should care about. Grace. I think there are two questions you're asking. So I think it's one, maintainers should be, there should be multiple maintainers, potentially from one organization. I think the other question you're asking just to be really clear is sponsors and maybe we add a bullet in or declare what a sponsor is there means? Cause I think that's like an important distinction there. So maintainers could be, you know, the people that are actually working on the code-based sponsors or people who are excited. I think we should define what a sponsor is to make that more clear. Cause I think sponsors historically have been used as advocates for the project, but not necessarily contributors to the project. Does that mean? Yeah, I think you're right. Thank you for bringing that up. Arun. Hey, so I guess this question came up about maintainers in the last conversation because there was few open, I mean, open questions around the governance aspect for any project that is beginning to, beginning to get into open source. The item that was, I guess it was Daniel who brought out this, the governance part is more important or if they are more familiar with the way of working in silos in within the organization. And when they come to open source, that they should have a mechanism of getting others in as well. So if we can try to answer that part through this maintainer section, probably that might help. And my comment over there is actually to address that part, that in terms of governance, hey, what if you have somebody, I mean, demonstrate that you are collaborating with somebody else before you came in for this project. Yeah, that's my comment on that topic. All right, thank you. Mark. So I remember discussions in the past where I think we delayed projects because they did not have a diverse maintainers list. And the concern was always, well, if it's all from one company, what happens if that company tires of hyperledger? You know, what happens to that project, to that investment that hyperledger's made? When you have maintainers from multiple companies, then, you know, you have a better chance that that project's gonna live on if one company leaves. So I think that's where the distinction comes in between people, I mean, what has happened and before the proposal and what's expected. And that's where it brings me back to the point I was talking on earlier, which is in the past, you know, you had company that just opened source that code and then said, hey, we would like to bring this and another company had not necessarily been involved to that point, but we'd say, yes, and I'm interested and I, you know, I commit, I will commit resources towards it. So from that point of view, you know, they wouldn't have the maintainers yet. We wouldn't have the diversity of maintainers on the existing code, but the expectations we would get it and it's very much into your point mark where, you know, there's the survival of the project longterm, right, is at stake on that front. Tracy. Yeah, I just add that obviously that's part of why we have the requirement to leave incubation and to become graduated is kind of a multiple maintainers piece. I think we're requiring multiple maintainers from multiple companies coming in to incubation is somewhat adding a new rule that none of the other projects had to comply with per se. And I think that could be a challenge for bringing projects in that could very well make it to a graduated state at some point in the future after they, after people see and start to realize that there's something good happening with this project and they want to get involved. So how about, you know, I understand, I mean, Daniel started from what he thought was the kind of the status quo and how things have played out and around this notion of maintainers. Personally, I don't feel that, you know, focusing on the maintainers aspect is necessarily the right consideration. I would be happier to say that we have to have, you know, like committed companies more than one company committed to the project. And that falls under the sponsors, does it? Oh, no. So maybe, but as Grace was pointing out, I think historically sponsors have not always, we have this distinction where there are people who say, yeah, they want to be sponsored to say, I support this idea without necessarily committing to contributing themselves, right? I mean, whether it's a person or a company for that matter. So there may be a worthwhile distinction there between something that's like supporters and sponsors or I don't know how we call those things, but one where we say, you know, and I think that the heap template does have that. There is a section on sponsors and a section on resources. Yeah, so just FYI, I did go through all of the existing kind of proposals that we had out there for projects, at least the projects that we have today. And there's a lot of wiggle words being used when it comes into that efforts and resources section. And I think it would be very easy to have a lot of wiggle room and for it to be set in a way that implies that there's more support than there actually is. So we just need to be careful, right? That we're not restricting and adding kind of new rules to this efforts and resources section. Yeah, I recommend if you want to go read through some of the proposals and see exactly what I'm talking about because it was interesting. And then, you know, so open and honest here like the reason I went through and looked is because we're interested in bringing the blockchain automation framework as a top level project. And we do have people who have committed from multiple organizations based on the metrics but I can't guarantee you that they're going to actually commit to continuing that. But yeah, I could say, hey, we've got six different organizations that have committed to this lab. So, you know, I just, I'm a little worried, right? That we're trying to add something that can't necessarily be met and that could be easily wiggled around. So just some quick thoughts about that. No, but I totally understand what you're coming from. That's why, you know, I did say, you know, I think in the past we had companies that committed to certain project that didn't necessarily live up to that commitment. I think that's a fact. And that will always be the case. That's why also, I think there's a general agreement among the TSC members that, you know, we want these things to be as objective as possible. And yet we understand that there's always ways to, you know, gain these things either intentionally or not for that matter because a company might very well intend to commit resources and then things change for whatever reason, six months later they're caught. And what are you going to do? Sue them? So I think we have to accept that. But yet I think there is some value in asking, you know, if there are companies committed to this. But so I wanted to go back to the maintainers this moment there because my problem with what's the way it is now is that, well, we say a project should have multiple maintainers and yeah, they could be from the same company. And then I'm like, what is that achieving? Because, you know, very much in line with what you're saying, Tracy, if I want to submit a proposal, I guarantee my project is going to have more than one maintainer, that's easy to get. I can get any of my buddies to sign up even if it's just on paper, right? So we can always gain these things. So I don't know that we are achieving. I don't know. I would say don't try to solve every problem up front. I don't think that we've had anything. I don't think that we've had anyone acting in bad faith when they brought a project in. And, you know, things may have changed and their focus may have shifted but I don't think any company brought in a project and tried to like submarine it and get it in there and make it look like there was a whole bunch of interest in it when there wasn't. So I just leave room. I don't think that's the right point. You're probably right there. Yeah, just assume good intent and, you know. It's like when we discuss the eligibility list for the election, it always remind us that it's easy to fake it and have a whole bunch of email registered. I was having a good day. You had to bring up the election. Yeah, it's coming up, isn't it? Yes. Anyway, we have five more minutes. Let's take the topic at hand for now. So, Dan, no, I mean, I know you put that in because you thought this reflects what has been done in the past but how do you actually feel about this? Do you think this has value? I do because if there's only one person maintaining code and they tire the project and leave, you're completely high and dry. Whereas if there's multiple maintainers, if one person goes on vacation for too long, the other people can step in. And, you know, as far as open source projects, I think the magic number is three people. If one person, two people have a disagreement of code, the third person can break the tie. But I think the only thing that historically has been done so late was rejected because there was really only one person arriving the code and maintaining it. And I think that example is something that's been done and it's a precedent and I think we should go forward with it or we should explicitly repeal it. And I think the better project health perspective, it's a really bad sign if you only have one maintainer when you bring it to incubation. It's a great place for labs and you can grow it up to two or three maintainers there and then bring it in. But, you know, you need more than one person looking at the code. No, you convinced me. I think that's good. Let's keep it, it kind of is a very clear criteria that, you know, should even, I mean, people who are genuinely, you know, wondering, oh, could I become a project with an hyperledger? They'll look at it and they've been working this project on their own for a while and then they'll say, oh, I guess not. And that's probably a good thing. Yeah, going from one maintainer to two is a lot harder than going from three to four. So that's the hardest problem. Yeah, okay. So then we have a couple of points from Maroon. Tracy, is there a hand up? Yeah, so for the first one, they plan to promote contributors and to maintainers. Again, I think this is a, definitely something that we would want for active but I don't know that it's something that is required for incubation. I don't know that I've ever looked for this when I've been looking at a project that's going to come into incubation. So I would suggest that we move this to the active criteria if you will. I'm sorry, I graduated criteria. Yep, I would agree as well. Haroon, is that okay with you? Oh, I had his hand raised before me. Oh, but yeah, I mean, going by the recent conversation that happened with one of the project that came up for the proposal, we did bring this up during that time. And we said, hey, do you have a plan for bringing in additional contributors? If you don't, I mean, this was brought up in that discussion. Yeah, but so do you think this is required for a project being proposed for incubation? That they already have that plan? Yes, so all that we are asking for is a plan. Hey, do you have a plan to increase maintainers or do you have you documented a weight so that if somebody is interested in this project, they can see this as an incentive that they become maintainers and steer the direction of the project along with you in open governance. Probably I still feel it is good to have a document. All right, so Haroon seems to believe that this is a requirement to enter incubation. Tracy said she thinks it's to exit incubation. So how do other people feel? We are gonna have to cut it one way or the other. I'm also with Tracy. I think this is something that can be left to the incubation phase. Hart has a hand up. Yep. Do even look, do most of our projects have this documented? So I'm just wondering whether most of our actual projects in incubation have this documented. So I, okay. So maybe it depends how you read this, I suppose. I mean, from my point of view, there's whether we have requested the policy on how to become a contributor to be posted, right? And I hope projects have that documented. I would say Bezu has the best documentation of process on transition of all the projects. So I would just use Bezu as a model. Yeah. I mean, I think most projects have like how to contribute posted, but I don't know that a lot of them have like, how do you become a maintainer? What's the process? Fabric does. I understand fabric does, but I'm guessing it's probably the exception rather than the rule. I think we need to know the six month mandate because I think how to become a maintainer should be established a priority, but maybe I'm in the minority. Well, I was, this is how to become a maintainer. That was the document I was specifically referring to, Bezu being a good model. So I agree by the way, Bezu has done that very well. I looked at it and I was like, well, yeah, that's cool. Okay, we're out of time, but Tracy, let's go back to Tracy. Do you have something else you wanted to bring up? Yeah, I think we're talking about two different things here. I think we're talking about how do we get more contributors to a project, which we seem to have a lot of projects want to enter incubation for that purpose, right? And then this statement as it's written is more talking about how do you promote contributors into maintainers, which was definitely not something that we have talked about in the past. So let's just be clear on what we're trying to accomplish with this particular rule. And I do not think that having a plan to promote contributors into maintainers is something that we should require. All right, thank you, Tracy. So let's keep hammering that one. I would be happy if people could continue the discussion offline so we can make progress. It's obviously a bit difficult to do that with everybody on. I mean, but we will keep doing it until we get that done. I think it's an important piece of work. With that being said, I will let you all go. Thank you all for joining. We'll talk again next week.