 Okay, now I'm recording. All right, can you share the screen again? Yeah, I'm getting over there just a second. Can you see the screen? Yes, I can. So I think we're good. We can get going. Everything seems to be in order. So let's start. Hello, everyone. This is Arnold speaking. This is the weekly TSE call. Before we get started, please be aware of the antitrust policy notice, which is displayed at the beginning of the agenda. And on the screen, if you're online, there is another piece of information you need to be aware of, which is the IPRE ledger code of conduct. If you haven't looked at it before, please make yourself aware. Other than that, these are the two conditions to fulfill to be able to participate. This is a public call open to anyone interested. You're welcome to listen in or even contribute if you feel so. So with that being done, let's get started with the announcements, a couple of announcements. The first one is related to the coronavirus and the IPRE ledger global forum. Several people have actually raised the question. So, Silona. Yes. So I've gone and popped up the page for you. This is also the Linux foundation's official word in regards to the coronavirus and how they're handling all of their other events as well. So they talked care about it for precautions, going to be having extra sanitation stations on site, asking people to do respiratory hygiene, which means either sneeze or cough into a tissue or your elbow, not your hands. Social distancing, basically like a no handshake policy. And just stand three feet away from people as what is polite. And then they will be having people, the venues are going to be doing some extra sanitation. And then also sanitizing microphones and things of that nature. So basically, you know, because of it's being still person to person, these protocols should be appropriate for preventing this spread of things that like the coronavirus of a person to person. Are there any questions that I can send back to the Linux foundation if I don't know the answer? I mean, I read through it and I thought there was pretty sensible policy. And I think the, the no shaking hands is a pretty basic one, but I think could help and is very easy to implement. So just don't get offended if people don't shake your hands. When you introduce yourself as well. And that's it. That's a small price to pay to keep us all safe. We can pioneer the coronavirus wave. You just walk up a wave. Will we get proximity devices we can wear? So if someone gets like within two and a half feet, it goes off. Don't get me tempted. You know, that's exactly the weird kind of stuff I build all the time, dude. One of my friends did make it. We can all just wear a buoy of some kind around ourselves, you know, and we can wear it. There you go. All right. Let's go back to the agenda. Discussion tables. All right. So the kiosks are almost are getting, we've got a lot of people signed up for the kiosk. And the main days are, you know, Tuesday and Wednesday for the kiosk because that's when the general public is there while Thursday and Friday are more workshops. The videos are looking good. So we've got a lot of people signed up for those as well for getting the intro videos done for all the projects, work groups and SIGs. And so those are getting recorded on Thursday and Friday. But the only thing that I don't have a lot of signups for yet is doing the birds of a feather tables at lunch for each of those days. And those are, I'd like to think of those as my little, our little bit of unconferencing that we get to do there. So I will have stuff available so that people can create their own little meat impromptu meetings during lunch, if they so desire. But if you want the nicely printed ones, let me know this week. Otherwise you're going to be, you know, writing it with markers and paper. So, you know, try to think of a birds of a feather table to create for the global forum. And they can be a different thing. Like we've got one group who wants to do one on Lawson. We've got, you know, some other groups who want to do it on just security. There's a lot of different interesting topics that people are wanting to do that go a little bit different than just the projects or the work groups or the SIGs themselves, but instead special topics that they can use to hopefully bring in new members or new participants in regards to their groups. So try to think of them that way as a way to like get people's attention and get them to come over and talk to you some more. Any questions? All right. Thank you. I'll add one more announcement, which is pretty minor, but I will not be attending the TSC call next week, but we have a vice chair, Tan Middleton, and I already checked with him is available. So Dan will actually be chair the call next week. So just a little piece of information. It's going to be a totally awesome fall. I'm sure. So Dan actually gets to exercise his role as vice chair. Okay. Is there any other announcements from anyone else? This is your chance. Okay. Hearing none. Let's keep moving. We had one quarterly report submitted from the borough team. I noticed earlier, I checked just before the call. It seems like everybody has had the chance pretty much to look at it. So at least most of us have. I haven't seen any questions raised. There was one point raised by the team reporting. I think it was Gregory who actually filled out the report. And, um, which has to do with, you know, advertisement and trying to get more, get more contribution. Um, unfortunately that seems to be a repeating story, right? Week after week, we have different projects reporting and basically asking for help. I don't know that there is any magic, uh, wisdom there that we can share. Can we get data on which projects. Are actually having success in recruiting people. Um, you know, I think vipin's done good with the identity working group, but I'm not sure on projects themselves, which ones are actually growing, but. You know, maybe there's something we can learn or. Um, you know, because it's a very common problem across many projects and, uh, other groups. So it seems like if there's something we could do in conjunction with the hyper ledger staff, maybe, um, you know, is it just a general trend in any ways or what, you know. So one of the things that we've been doing and I've been posting it to all of the chat channels and also to the contributor channel is, um, and the contributor mailing list is the fact that we are doing monthly developer marketing calls. So the marketing team and myself have been doing these calls once a month where we basically find out about if people want to do blog posts, if they want to do announcements, if they want to do any of those different things to come and attend our marketing calls. So that's the appropriate time to come and do that. If you need marketing help, please come to the marketing developer calls. And have we seen any of the projects that have been, um, needing more growth show up to those? Um, not always necessarily. Different projects seem to be more dedicated to showing up to these than others do. Um, but we would obviously like our attendance to be a lot more than it's been. Um, I'd say on average, you know, four to five attend and, um, you know, and I keep posting them and I keep, you know, nagging individuals occasionally. Um, but, uh, I also try to reflect all of this in regards to talking to the projects regularly, finding out who's got a, who wants to do a blog post, who wants to do announcement, you know, who wants to do any of those different pieces so that I can get that to marketing and we can promote y'all. Um, but I think for anyone who wants to do recruiting, I think doing a blog post and getting that all out on social media is a good way of recruiting. And then of course, all the different things that we're trying to do at the hyperledger global forum is also another good way of doing recruiting as well internally. Um, but I'm assuming most people would like to go externally outside of hyperledger because most have already been recruiting internally. Yes. Anything else? Okay. Unless there's any questions, otherwise we can just keep moving. Okay. Hearing none. Let's keep moving. I did notice that, uh, so the, the updates, the upcoming reports, right? We said we needed to update the TSC working group because we have already decided that those who do not produce indelible do not have to do the reports, but the page, the calendar doesn't reflect that yet. But otherwise you have the link there. You can follow what is next to be expected. All right. So we can move on to the issues. There is one that I'm hoping we can close today, which has to do with the, um, the voters selection for the TSC election. Um, so we discussed it. I updated the page based on the discussion we had. And, um, what is left is, I believe to make a decision, there was one comment that I think we ought to discuss from VIPIN who, so today the text, if you look at the formal proposal, it talks, it talks about working group and, uh, task force chairs. And, um, VIPIN suggested that we should add a SIG chairs. So the SIG basically could also be involved. And every participant in the SIG could be part of the voting process. And, um, Chris earlier responded with saying, well, the prime with the SIGs are not under the governance of the TSC. They are directly reporting into the governing board. So there's a bit of a mismatch there. VIPIN responded, well, I don't know that this is relevant. The charter says technical contribution and SIGs do technical contribution. So I think we did, we do need to decide which way we want to go on this before we can have a vote. But, um, I'm happy to hear from everybody here. Uh, and, um, if there's any other comments or any changes that people want to see, um, related to the proposal, please speak up. So I'm, I'm with Chris. Um, I think any sort of technical contributions that the SIGs are making, I've noticed have been through labs or, uh, something that's in GitHub that we would actually end up getting those technical contributions out of. Um, so I'm, I'm with Chris to leave SIGs out of this. This is Dan, I agree with that. This is like that agree with Tracy, Dan and Chris too. Okay. So, so far we have several members who spoke in favor of not adding SIGs to the list. So we would not modify the proposal based on, you know, according to VIPIN's suggestion. So anybody wants to do what VIPIN is suggesting. She's to expand the list today. It talks about the working groups and task force chairs. And he says you should add SIGs. Because unless somebody wants to defend that position, then I think we can consider that done. Do we, do we feel that SIGs do not make technical contributions? We feel that the technical contributions are going to show up in ways that they'll be counted. If technical contributions are being made. So if a SIG puts out a white paper, we'll automatically pick it up or do they have to put it and get. If they put it on the wiki, it'll be counted, right? I think there's still an exception policy that they can go through if somebody feels like they have made a technical contribution, they can send something. This sort of just opens the door though to, you know, to the people who show up to listen to a meeting. And we felt before the like that was below the bar that the original intent of this was you're making commits to one of the repositories. Well, it's like when we did the white paper for performance and scale, we didn't count people who just showed up to the meetings, right? We counted people who actively contributed. And so that sort of, you know, part of that falls on the chair. Yeah, that's why at least the chairs, the chairs are given that role of doing a selection of people they feel have made technical contribution that shouldn't be taken into account for this. There is this fallback mechanism that Dan points out, right? This form you can always petition to be added. So there's, there's still a way in anyway, whichever way we, it's more matter of whether we make that part of the normal process or, you know, to make it easier or we say no, we don't need to do that. So Mark seems to be leaning towards saying, no, we should include them. Is that am I reading that right? Mark. Sorry yelling Lotto while I'm trying to find the unmute button doesn't do anything for anybody. No, I just want to make sure that we don't exclude technical contributions. If there's a process for them. To get counted. Then I'm fine with it. Yeah. If there's a group of them that make a technical contribution, we could. We could batch accept them. So. Okay. So I still haven't heard anybody saying, yeah, we really need to add things to that list. So. Is there an, oh, so let's, let's take it at this for now. And then let's move on. There is another comment. I just remembered. Tracy, you made a comment. Actually. Regarding this petition process. You want to speak to this. Do you remember what this comment was? Or no, and I can definitely speak to it. Yeah. You, you, I can read it for you. It implies that there is some sort of review process in place. What is it? And how do we check to see if the person should be included? Originally this form as for a PR that someone had committed. Is this still the same? Yeah, exactly. So when we, when we originally had this put together. You know, we had a, you know, you know, you know, you know, when Todd had, when Todd was sending out the emails and whatnot, it included information about, you know, point us to your PRs, send an email to. Todd and Tracy, right? And then we'll take a look at the PR. I just don't know if that's still the same process. I assume it is. But, you know, there are some things that could occur that we, we actually understand when we would accept something. Right? I think PRs are obvious. Right? I'm not sure that some of these other things that we've been talking about are necessarily obvious. I think you're right. So I, you know, to me, I would, I would open up the form and not just limit it to a PR, which would be, you know, we are supposed to catch those. But, you know, I think it would be the case where there is really a, the process somehow fail to catch somebody's contribution. And you can, you can say, Hey, this is actually the proof. This is my PR. But I would be happy to, to broaden this and say, you know, you believe you, you should be included and tell us, you know, what your contribution is. So, I mean, I'm not looking at it as an additional case of it, but I'm also linking to a PR. But there's not to be limited. There's enough to be limited to. So for the last election, we did have that kind of form put up. And it was on the wiki. And so, and Dave Hughes be created it so that anyone could go in and fill out the form. And we basically just said, attach a link to your contributions. And it was pretty open. but hardly anyone used it. I think we only had like three submittals total. Not to throw another wrench into this, but if I remember correctly, that form was a Google form, which not everybody in the world has access to. So we should make sure that we're not using Google and that we are truly using Confluence because that's where we've moved everything to. So that's obviously for the next go-around. That sounds like an important point. Thank you, Tracy. In response to Tracy's previous point about, which I think was perhaps on what basis would you, if someone petitions for the contribution to accept it, I think it touches on whether or not to accept Vifin's proposal. And I'm inclined to agree with other people on this that insofar as the SIGs are outside of the technical governance of the TSC, the idea of the contributions is not just brownie points contributing at all. That can be recognized in other ways. It's about giving franchise to people who are producing things under the technical governance of the TSC. So if those are inherently captured, if you happen to do technical things, I think equally that should probably be the test that you should be eligible to get a vote in the TSC elections if you're contributing stuff that is under the governance of the TSC. I propose that that would be the principle. That works for me. Sorry, is somebody else trying to speak? I said, this is Chris, I joined, that works for me. All right, welcome Chris. Okay, are we ready to take a vote to this then? Because I think we have what we need in the text then. And there's- Someone needs to propose, someone needs to second, then we do a vote. So we are striking the SIG comment from it? Well, it's not in, so this is a comment and we are basically saying no to the comment. So it doesn't change the text. I thought he had changed the text. Yeah, I thought so too, but no, he just added a comment, one of those inline comments that you have to click on task four chairs and he says, and SIG chairs, but I could answer to it as well. Oh, okay, I see. Okay, so we're good as is with the text. Yeah, we can just mark it resolved and it's not there anymore or. Swarming this way. Oh yeah. Okay, so can we end the vote then? That's a big tractor. Dan, making a motion. Sorry, I'm not muted, am I? No, that's fine. I keep trying. But we want pictures of the tractor. I'm taking the kids to school and we're behind this giant tractor. Anyway, all right, back to this. I move for a vote. This is Dan. Second. Thank you. We just seconded it, I'm sorry. All right, second. Okay, thanks. Okay, so Angelo. Fine with it. I know. Yes. Chris. Chris. Chris. Is he there? Yes, no, maybe so. He's on mute, I don't know if he knows. I'm on mute, that's weird, I wasn't on mute before. Okay, yes. Again, I'll say yes. All right, thank you. Dan. Yes. Gary is not present. Hart. Yes. Mark. Yes. Nathan is not on. Swetha. Yes. Chris. Tracy. Yes. And Troy. Yes. All righty. All right, thank you all. This is therefore approved. Which get us that much closer to being done with this old TSC election stuff. There is one more issue which has to do with the observers. And I actually didn't have a chance to, I wanted to go back. Does anybody remember from last week, I believe, Rai was going to update the text. Am I misremembering this? Nothing has changed on the page, but I don't know if something was supposed to happen or not. I wanted to check the recall to remember, refresh my memory, but there's a chance to do that. I don't recall. Anybody remembers? Yeah, I believe you're correct, I don't know. Rai was supposed to put together something around what the process is and what the observers would be responsible for and that sort of thing. Exactly. Okay. All right, so this didn't happen. So let's leave it at this for now. We'll postpone until Rai gets a chance to do that. That, again, it is the last election related issue. So I'm kind of eager to fix it and get it done. There is another issue that we talked about and there was quite a bit of discussion offline and I thought it'd be good to take a chance to see if we can make progress on where we might go with this. It's the DCU and pseudonym issue. And again, this has to do with, you know, how much is required of the maintainers with regard to knowing the true identity of the contributors. And so I believe all the projects have a DCO check on PR so that you cannot actually merge any PR that doesn't have a sign-off. But as we all know, I believe, those sign-offs often are somewhat misleading because for various reasons, people do not always put an email address that actually points to anything real, reusable to get back to them. And there are actually valid reasons why people may not want to give up their identity, their true identity at the same time. So we have to manage this like, you know, the need for some people to hide their true identity and the fundamental need that we have to make sure that they, from an IP point of view, right, and take to a property point of view, the contribution is clean and they are committed to the rules at the play so that, you know, there's no encumbrance put into the code through merging some PR from some unknown or unidentified person. And so there's been different ideas floating and I feel that the one that seems to be the most promising but I was, you know, I'd like to know if how much would it take to do that if it's feasible at all, seems to be to depend on Linux Foundation ID. We would require all contributors to have that and use that as the sign-off. And then associated with the ID, we could have the true identity of the actual person which does not have to be disclosed to the public but that the Linux Foundation would have in some kind of like, you know, registry related to the ID, so that if there is any questions at any point in time, we can go back and find the true identity and we, it doesn't have to be we everybody, right? Whoever needs to really know. As we know, I mean, it's fairly common to have email also go stale or, you know, there was this notion, well, maybe if the maintainer actually knows who the real person is behind the ID, maybe that's good enough, but that does not, you know, last in time is like, well, once the maintainer moves, we don't know who they are, where they're doing. It might be very difficult to actually find that person back if there is any question related to their contribution. So I wanted to hear if, you know, this idea of depending on the Linux Foundation ID was at all feasible and what it would take to investigate further and get the sense of whether this is implementable, what it would take. So maybe that's a question for the staff and Brian is not here. I don't know if there's anybody else can I thought, okay, go ahead. Go ahead, Chris. I was going to say you were, you should ask Brian. Yeah, and yeah, I'm trying to do the context switch back into this issue. I don't have any update on it for sure. And I think where we ended up was seeing whether we could find somebody easily, check whether a given GitHub identities had associated LFIDs. And if so, then that's green light to be able to merge. If not, then we have to get the submitters of the full request to go create those LFIDs or something like that. So I don't have any update from the other side as to how practical or easy that is, how to make that kind of a zero friction, you know, kind of process. I can, yeah, I'll re-escalate that. But that seems to be where we ended up if I'm trying to look especially at the last bits of comments here. All right, thanks, Brian. Any comments from anyone else? So I mean, if these were possible, would people be satisfied with such a solution? So my concern with Linux ID Foundation integration is it creates more friction for people coming in for their first contribution. And basically we've already had a couple of instances where people were contributing documentation. And when the DCO check came up and failed, they abandoned documentation. So any more friction that we add to the process is gonna reduce the number of people contributing. And already on this call today, we've had, you know, mention of two projects that are specifically asking for ways to get more contributors and putting more obstacles in the way of contributors is not gonna help that. The more obstacles we put in the way, the less contributors we're gonna get from the community onboarding to contributing to the blockchain. Right, but again, this is, the whole point of the DCO is to ensure that we have essentially practice good hygiene on the intellectual property in the projects that we're building here. If you allow somebody to come in and make a contribution and you have no idea who they are, how to contact them, then there's no way that if we had to go through and do a license change, and that would include even just going from Apache 2 to Apache 3, if there's a, you know, if a three ever came along, we have to be able to ensure that, you know, we can do that by, and we'll have to contact all the people that make contributions and, you know, get them back or have some ability to understand, you know, that the IP maybe belongs to their company or whatever, but can't just be letting people drop in and make a contribution. You don't know where they've been, right? And you don't know what, you know, potential obligations they're putting on us. By signing the DCO, they're saying they have the right to contribute it and they're, you know, they're aren't gonna be, and they understand the obligations of the license. If somebody just makes a contribution and they have a patent on the code that they contributed, they can, you know, and they didn't sign a DCO, well, then they can assert that claim against people that are using the project. And the DCO was designed to be as low friction as possible to trade off on that, because all the DCO, or correct me if I'm wrong, is adding that signed off by line at the bottom. That's it. And that signed off by doesn't even have to point to, you know, a working email address or name. Obviously that, you know, that is a hole in the process. And so far as somebody, you know, with no intent can, you know, you know, just hide their name. So no process is gonna be perfect. I think if anything- Right, but the patches all come through email. So, you know- We kind of aimed for low friction, you know, at the cost somewhat of integrity check. That's where we are now. And I think if we were to ratchet up anything, which all these proposals, you know, would basically do, we do have to figure out how to keep the friction as low as possible. And that's why the lowest friction thing is probably to just have some way to flag, you know, to not block contributions that are coming in from GitHub IDs that aren't associated with an LFID, but to make that a flag and so that there's some sort of process that says, okay, if it's a one-off contribution to a documentation, that's probably a low risk. If it's, you know, regular series of contributions, it's probably time to ask the person, hey, take the five minutes, create an LFID. So at least we're, you know, we know who you are. Again, I need to just work on that with both LF legal and then figure out, is there a low friction way to add that to the GitHub PR approval workflow? Because we don't have a lot of flexibility on that, right? That's, yeah. Okay, I think it's important to have the right guidelines because again, and, you know, Daniel raised this issue initially saying, okay, what is expected of the maintainers, which I think was a very fair question to ask. So if that's, you know, the kind of process you're describing Brian seems reasonable to me, but it would have to be documented so that we establish that as the norm. Yeah, it'd be adding a little bit of a burden on the maintainers. So one of my, I listed several options. The one that I think might be the most reasonable is in a case where the identity may not be known but the contributor wants to merge it, they need to add a signed off line of their own. So if you get a contribution from Captain Crunch, you know who Captain Crunch is, you can sign off and say, hey, I sign off on this. But if you get a contribution from Satoshi Nakamoto, no one really knows who that is. So you shouldn't be signing that one off. That way you can let them, you know, work in the public under their suit of them as long as the person signing off knows who it is. You know, they can't just sign off any random person they don't know unless it looks like it's a real ID. Yeah, I mean, but it's not just that you know them, it's also that they're actually, the DCO is creating an obligation, right? Right, they've already signed a DCO and signed their suit of them. You can't take on the obligation that somebody else doesn't have a patent with a claim that can read against people that are gonna use Basin. Right, they put the DCO under their suit in them, which means they've already accepted the requirements of DCO. I'm not advocating getting rid of DCO. I don't think that's gonna happen. Okay, okay, I just want to make sure I just said them. So, Dano, can you see my comments on that in the wiki? But so you said something like this and I posted some comments. So why don't you tell us what it is all because? So I'm basically, I'm not sure about the viability of just implementing the sort of the maintainers know. You know, if we can come up with a good system where this works and is, you know, is low friction, then that's great, but I just didn't think it would work because the problem is if some maintainer leaves, right? It's, you know, it's a problem, right? If a link in the tree gets broken, then we have problems. And also Arno's point, right? If I have spoken to people that would like pseudonymity and the fact that the maintainer sort of knows them is problematic for that. Yeah, I think if we can tie it to an LFID, which does not require a real name, Satoshi Nakamoto could get an LFID. And we can do that in a way that has minimal to zero friction and the contribution side. That's gonna be the optimal. So I would suggest allowing me to go off and try to figure this out with a legal and LFIT or see if other projects have kind of solved that because I don't think that they have. And in the meantime, you know, requiring people to add the signed off by line, you know, which is the dash s flag during get commit or is, you know, there was a conversation actually on the DCI working group about this this past week where somebody thought they couldn't, that meant they couldn't make a contribution through the web UI, you know, for example, to a documentation fix. Turned out you can, you just have to add that line at the bottom, but that's not clear anymore. So we could probably in the short term make some documentation fixes to optimize things for people, but in the long term, let me figure out how easy it is to have this kind of LFID check kind of kind of, that might even be something we can simply script at the end of the day. But I don't know if you have talking here is going to get us much closer to an answer. No, that's fine. I just wanted to have a chance to see where we were. And I think that was useful from that point of view. I think we can leave it at this for now. We'll wait for you, Brian, to get back to us when you have more clarity as to what's, you know, LFID, LFIT, and what the legal folks think we need to do. When we talk about blow friction, it's not a matter of, you know, finding the sweet spot, right? Because it's clear we could make it extra burdensome and that would definitely turn people off. There's an degree where we have already turned some people off, maybe, I don't know. We've seen, especially in the labs, there are people who make this contribution or proposals. And the number of times we have to say, sorry, you don't have a sign-off you need to do a sign-off. And when they do it on GitHub, it's hard to patch afterwards and stuff. So, you know, there is already some barrier just related to this. And clearly, we're not saying we should just not have DCU at all because there would be less friction and they would make it more contributions. You know, so it's all a matter of finding the right balance here. And I think we should turn those other open source projects on this front too. We're certainly not the first to have this problem. Yeah, no, that's pretty clear. If there was an alternative like a CLA bot where we can get your PR and it sees it's missing, it's DCO, rather than making them rewrite it, they click on another page that says, I assert this follows a CLA, yada, yada, yada, like a lot of other projects have for their CLIs. I think that would reduce the friction because we don't have to tell people to go do a bunch of magical git commands to do a forced push to GitHub. They can go to another robot, make their attestation, the robot comes back and says they attested that they agreed to the terms of this in a commemoration of the CLA signature now with the DCO signature. Yeah, the CLA process is different. There are some concerns that that itself is a higher bar because that is a more of a legal document that somebody has to sign. And I have a separate thread with LF Legal trying to figure out how to characterize the advantages or disadvantages of CLAs versus DCOs in a way that everyone can understand. And possibly we have a conversation about switching from DCOs to CLAs or adding in some hybrid form. That's, I'm hesitant to recommend any action on that yet because those answers just aren't clear, I think. I certainly, you sign a CLA and then, I mean, you don't have to add that line going forward, but for some people, even signing the CLA is a bigger step than just adding the sign off by. But let me, I have kind of as part of this conversation, I've asked LF Legal to help us everyone understand the advantages and disadvantages of DCOs and CLAs and that sort of thing. And I know that they are working on that. It is true, most other projects at the Linux Foundation use CLAs rather than a DCO, but I don't wanna say, well, we should switch until I have some way of helping everyone understand the benefits and costs of that. Could I click through a button to be written that at the direction of the person submitting it, it will add DCO sign, DCO commits to it rather than it being a full CLA rollout? I mean, that's one possibility. If we get modified to get a UI, but I don't know that we can't, you know, yeah, that's, so, yeah, I think there's some documentation you could just provide that explains through the web UI at this line and here at Golden because it really is a cut and paste. But, so again, part of this is also education of our contributors, especially when they're at their point of making the first contribution ever, right? All right, guys, let's leave it at this for today. I think this was useful and at least I have got more clarity as to where we stand and what we can expect. Brian is on the hook, so that works for me. Thanks. Okay, so that's the end of the official agenda, but I got pinged by Sean, Sean Young earlier before the call saying, hey, please, could we have any chance we could have some airtime talking about the Solan Solidi compiler proposal? So I don't expect us to make, you know, this is not like an official proposal that I'm expecting people to have a vote on or anything like this, but since we have a few more minutes left, I'm happy to give Sean a chance to speak up and talk a little bit about what he would like to see happen and what the questions he's facing or if Sean is there. Yeah, I'm here. Hello, this is Sean Young. Hello, so I'm working on the Solan project, which is a Solidity compiler. It compiles Solidity to WASM, uses LLVM, which is the existing Solidity compiler does not. So it offers a number of advantages. It specifically targets WASM, so any ledger that uses WASM for smart contracts, and there are many, it can then target, it can make specific targets for those ledgers and then those ledgers can use Solidity smart contracts, where before they would have to use EVM and it would be bound to the EVM model of how blockchains work. So this offers Solidity in new contexts. It's funded through a web-free foundation grant. The grant will take it to for Solidity language compatibility around the September time. There is already a fair amount of functionality and documentation online. So that's really, and it works with borrow and sort of support is early, but it does work. And one of the reasons I would like this to become a Hyperledger project is so that we, I can work with other ledgers and work on the target support. This is an area where it depends on the specific ledger, what the work needs to be done, that it requires the knowledge of that specific ledger, which I do not have always. I think that's a brief introduction to Solan. All right, thank you. So there was quite a bit of reaction already on the mailing list, then it seemed to be mostly about, what the right setup for this project to be, and especially whether we should pursue this as a, what do we call HIP, like a new project or that would go in incubation or it should go to a lab, which is much more, I mean, as we all know, easier to get started than doesn't have as much, not as much of a heavy weight. So, I mean, Shen actually thinking one of the, I forget, I apologize if it's in the message he sent me or if he sent it to the list, he had a question about, okay, what does it take really to qualify for a project in incubation? And there was this question about how many people were involved in the project, supporting the project. We heard that there are at least a couple of people who said, yes, I think it's great, I'll support this project and be happy to participate. But so, what's the situation beyond that? And maybe back to you, Shen, I mean, would you be open to this lab? Do you really want this to be a project in incubation or would the lab satisfy your need for now, which gives you more visibility? It brings it into the hyperledger landscape? So, the project has been a lab's project from the very start, and so far it's, well, I'm not sure it's helped somewhat, but it hasn't helped very much in gaining much visibility or participation. Okay. So, incubation, I hope, I assume, would be a better way forward, although I'm open to suggestions, of course. So, but it is about getting more visibility in your mind. Well, visibility and cooperation from projects on specifically on the ledger target support. Okay. And I don't mean to dash your enthusiasm, but we just heard it from the borough project earlier and we hear that week after week, all the projects are struggling, even though there are top-level projects in incubation, that, you know, it's by no means a guarantee you're attracting the crowds all of a sudden. Of course, of course. This is a perennial problem for any project. I work on the open source projects and everyone always wants more contributors. No one struggles with too many contributors. Okay. So, let me turn back to the TSC, and all the members, anybody has, what do people think? Any comments or thoughts? I think this is a good opportunity for us taking more of a technical steering turn now that we've been able to put to bed some of these more bureaucratic governance issues. This might be a good opportunity if we've got some technical experts in the community from the Solidity, Wasm and so forth to put together a bit of discussion for next week and we can get a better sense of the technical value of the project and then we can see how that makes us feel in conjunction with the other norms that we've established for things like project size and so forth. I think it points out too that there's a bit of a chicken and egg problem, right? If you're a lab, your lab is supposed to, you know, ideally turn into a project at some point, which, you know, was an incubation and then goes to active if we still have that. But, you know, if it's gonna be hard to get projects to support this proposal if it's a lab, right? Because it means it's a ways before they can use it in their project. So, you know, I think we sort of need to figure out how to weigh that balance correctly and it might not be that there's a hard set rule that you have to have three maintainers or something if it's something that's gonna get used across the board. Yeah, I think it's a good idea from Dan to collect some detailed thoughts and I think this is a very strong project from the point of view of timing and technically what it does, particularly if you compare the state of the Solidity compiler to this one and built on much more modern foundations and the load of interest in place it can go compared to some other proposals as well. It's a very focused project. It's not something that suffers from creep. It's got this cross-project applicability. And across the labs, you know, there's quite a large variance in labs, but I can't think of other labs project that really have the development velocity, the quality of code, the amount. It doesn't really seem to fit in the lab. So there is a signaling thing which you could argue, you know, it doesn't need to be a problem to be a lab, but, you know, like I think having that extra push from being a project in incubation and giving certain people a bit more permission to be like, okay, maybe I could invest some time and energy in this. I think that should maybe be something that is, that trades on the positive column of the ledger for this project. I also think in terms of, well, my colleague Greg is on here for the, well, the burrow update while we're looking at the short time for that, is interesting becoming a contributor maintainer on this. My impression is there is a lot of latent interest. And yes, as Shauna said, he's a colonel hacker. And I think it's a little bit of energy from someone to engage other contributors who can start small, but that this could quite easily get to a place. So I think if I had a vote, it would be to put this into incubation, but failing that, what would be very useful for a project like this is just some clear, I realized the TSC won't write a blank check, but some clear metrics you'd like to see met in order for it to progress there. And then I'm pretty sure we can go about reaching those metrics. I think one of those metrics inevitably is gonna be, additional active maintainers, right? And we always aim for more than one employer on those. But I do wanna say, I think I said this in detail, but for having now three active maintainers from ONACS, but three active from the outside as well, which is a good achievement. But I think that does mean for developers, advocacy and looking for other teams working on this same kind of problem and such is kind of an essential part of being a maintainer, right? And I think it's actually a decent test of, is the developer able to recruit and community built and build and collaborate with others to have as a gateway before becoming a top level project. Here's signs that there's other people out there. And I think in that, I know that there's other projects working on isolated compilers and targeting different back ends and that sort of thing, even if they're in different languages, it might be worth doing a bit of reach out and I know there's some other people in the community, I know Bob someone was posted about this, interested in the same thing. So I think, I don't think it's too high a bar to say before something can become a top level project. It's some demonstration that community building is just as important as does the code compile and does it solve the problem it claims to. All right, so this actually brings us to the end of this call. But Dan, I heard Dan asked for more details. And so since you will be chairing the call next week, I take it that you will follow up with Shen to get that set up if he's available. Yep, I already got a couple notes out. So hopefully we'll have a deeper dive on this topic area next week. And then we'll be able to use that to inform however we wanna address the other policies that we have. Sounds good. All right, so let's leave it at this for today. This is the end of the call. Thank you all for joining. I will not be there next week, but I'll be there back there in two weeks. So talk to you then. We'll wave to you in Phoenix. Oh yeah, we'll see you in Phoenix. Thank you. See you. Bye. Bye.