 Good morning everybody. Afternoon, good evening, good night, whatever it is, wherever you are. Can we get the agenda up? I didn't memorize it, thanks. So on the agenda today, we have a couple of reminders about Hackfest coming up in the two, three weeks and the Global Forum in December. So registrations are open for them and the call for papers for that. Todd can go for that in a second. Then we have a couple of updates on projects. We have Explorer this week, Quilt next week. The Architects Working Group today, hopefully Ram is on. I didn't check the attendance, rather. And then Dave, I think, is going to give us an update on hyperlendrolabs. Is there anything else to be added to the agenda? If not, then I think we can get going, so Todd. All right, sounds good. So the first thing is heads up that Hyperledger Global Forum will be December 12th through 15th in Basel, Switzerland. I know Brian had some additional information on this on the TSC thread last week. The main thing to note is we have a call for papers open right now. That's going to close on July 13th. So please take a look at the link there. Get talks submitted for this. Just to reiterate, this is the major public summit for Hyperledger. It's 100% focused across the entire Hyperledger community ecosystem, et cetera. So there'll be the various talks and panels that we often see at these events, but there's also going to be a lot of coding, collaboration, community building, and whatnot. So we definitely want to hear a lot from the technical community as we're laying out the agenda for this. So please have a look at the CFP and get talks submitted. And then onward from there, Amsterdam Hackfest is in about two weeks, I want to say. So let me drop the link into the TSC chat one moment. All right. So two things I'll say here. We've seen tremendous interest in this Hackfest. So really excited for that. Over 100 registered for it and around 130 registered for the initial day. So that's fantastic. If folks can click on the link, I just dropped in the TSC window. This is the draft agenda. So previously, we had met with a smaller group kind of to talk through the day zero training stuff as well as the broader Hackfest. So we have mapped this out a bit better in the link I just provided. Tracy, if you're on, do you want to just talk quickly about the day zero and how we have that structured and what we need? And then from there, we can just spend one quick minute on mapping out the rest. Sure. So with day zero, we decided that the kind of the lightning talks that we had last time in LA were too quick. And so we wanted to give some focus to the people that were on it. The other challenge that we had was last time when we broke out into different sessions, we were basically breaking people into having to choose which one they wanted to go to and really kind of breaking up the community on the first day. And so we really felt that it was necessary to keep people together and go through a shorter list of the projects. And so what you see here is that we're going to do the standard welcoming and introductions where we go around the room and introduce everybody that's attending. Then we'll do kind of an introduction to Hyperledger where we talk about the projects and how you get involved in those sorts of things. Then we're going to focus on fabric and really helping people get set up with fabric, learning what fabric is. And then we thought maybe as part of that hour and a half kind of going through maybe the getting started so that the community could then get some feedback on kind of the documentation and what it's like to get started for somebody who hasn't installed the project yet. And then after lunch, do the same thing for Sawtooth and for Indy. So what we're looking for is obviously volunteers who can help provide that introduction to each of the fabric Sawtooth and Indy projects and then walk them, walk people through kind of getting started and helping them kind of get their machine set up. And then of course, just kind of being the person who will gather the feedback for the different communities to figure out what it is that needs to be improved with the getting started. So I see Chris is already volunteering for fabric. And then we'll need volunteers for Sawtooth and Indy. So that's kind of what we're looking for. Cool. On the Sawtooth side, I think Sean Amundsen and say Peter Schwartz and Adam Woodvick are planning on attending. So I'm sure any one of them would be happy to do the Intel. Sorry. Happy to do the Sawtooth coverage. We have a few folks coming for Indy as well. So we have a few options there. Tracy, is there anything maybe in yours or that talks about what's common between the three and what's different between the three? Or is that just going to be left as an exercise for the people in attendance to take away? So there's nothing specific in mind section that was going to cover that. We do, if you look down towards the proposed agenda and topics, we had talked about doing possibly an architectural comparison of the different frameworks on the other two days, Thursday or Friday. So I think this is maybe a good place for us to start thinking about those sorts of things. And definitely, I think it makes a lot of sense to kind of, maybe we cut back on something earlier and give ourselves some time at the very end just to do maybe the start of that comparison. But I definitely think that's a good idea, Mark. Tracy, that's Nikolai from Hyperledgeroka speaking. I was really curious if our representative has some voice on this hackfest agenda. As I've seen, he has some suggestions in the end of this document, like erotic topic proposals. But I haven't seen any activity in the direction so that our proposals were included. Is that because he wasn't really proactive and asking you for suggestions or maybe you haven't seen them so far? So no, Nikolai, I did see those at the bottom of the document. And I think it's great that we're going to have some ROHA representatives there. And I think we can definitely include those in day two or day three, or whatever you want to call it, two or three. So Thursday and Friday, right now we have completely open slots. And I think it would be great if we could start slotting topics into Thursday and Friday. They could be the topics that are proposed, the ROHA topics. Any of these topics, I think, are really good topics for us to start slotting in. OK. I'm not sure whether it should be very technical, like a discussion of data model, or maybe we can do the same, like getting started. As I've seen, someone has proposed like getting started on Hyperledger Fabric and the Sotos and Minji. Can we do the same? Or what are the expectations of the participants in the hack-fest I really want to understand? So you know, it's difficult to tell, but many people are new to this, right? And it's an answer that, yeah. So getting started is usually much better. And then if we see that people really understand stuff, we accelerate. So we're always assuming that people don't know a lot. And then, yeah, so it's more kind of hand-holding at the beginning, especially in the labs. You know, when we start kind of getting people to compile code, download code, download Docker images, run your first network or something like that, that's usually very helpful for people to get their hands dirty, right? Yeah, I agree. So you can also have a presentation explaining more as well, right? It doesn't have coding. I would actually recommend the following, I think, and Todd, tell me if we can do this. I think it would be good if we can have pointers, you know, if the Fabric, Sawtooth, and Indie teams can get together a little sort of onboarding package email that provides, you know, links to download the software, links to the setup instructions prerequisites so that people can do that as homework before they come, rather than at the thing, because that oftentimes, especially if we're stressing the Wi-Fi and so forth, can be problematic. We can probably have some on thumb drives to facilitate that. But it'd be great if people could actually do the homework and just, if they want to participate in the getting started, if they could download and get the software up and installed on their system. Exactly, and we're thinking the same thing. We've already chatted with our events team to get a section into the final confirms that go out just so folks can walk through exactly that. Yeah, and I think we should probably also, well, the trouble with that would be, I would consider that email to be spam, and I might not even look at it to be perfectly honest. And maybe a separate email that highlights that, or just. That's fine as well. I mean, action-inspired kind of a thing. I only say that because, I mean, everybody's really busy, and some people are going to be traveling and so forth, and I think it would just be good to try and get as many of that handled as possible. Cool, and we can have that come from Tracy or me or whoever, just so it's. Yeah, exactly, right. Make it a little bit more personal than just coming from. Great, we'll do it. Is there, since you are volunteering, Chris, is there somebody specifically that we should be reaching out to you for the different communities, if there's people online now that. Well, I can, Arno and I can craft, you know, the, I mean, it's basically derivative of the getting started and, you know, and so on and so forth. So, we can craft that for you and, you know, you just got to let us know when you think you want to send it so we can do that. I can't speak for the other team, though, is it? That's fine. Should I reach out, Tracy? I'm sorry, should I reach out, Tracy, or what's the plan? How can we send the getting started completion? Yeah, Nikolai, feel free to send it to me and I'll make sure it gets sent out. We'll make sure that it gets sent out to the different participants that are going to be joining us. Todd, when do we want to send that out by? Yeah, I was going to say, if we can get that out early next week is probably best just so folks have a week to back this in. So, if the project can get stuff over to Tracy by end of day Monday is ideal if that's feasible. Okay. Cool. I know we have a bunch of other topics to get through today. So, is there any stuff on this or? Just one left. Oh, go ahead, Dan, sorry. Yeah, sorry, just one last thought for Nikolai. Usually the way that we've run these events, anybody can go in and add things to that agenda. So, if there's ever for this or a future event where you wanted to add, you wanted to add a session on something and you can just go in and add it. Cool. And I think the important thing for this time, we have the grid built out in the Google Docs. So, let's start mapping some of the stuff in the suggested items into actual times. And then I think people can hit the ground running once they get there. Awesome. Okay. Who's doing Explorer? I think that's Pardah. Who's doing it? I thought so too, but I don't see his name. So, he may be dialed in, but I don't know. Yeah, it looks like... Oh, there he is, down the bottom. Doesn't look like he has voice though. So, he may be dialed in one of the numbers above. I don't know. Pardah, are you there? I think it's... Does anybody know how to unmute yourself when you're on the phone? If you press star six, it should unmute you. Okay. I'm on now. Yeah. Can you guys hear me? Okay. Yes. All right. It should be a very quick update. So, we have... We've been actually working on the Explorer in the last quarter. The project is being developed using Agile methodology. We have daily stand-ups. The stand-up, the meeting details are, as with any other project, they are posted on the wiki, but anyone who is interested in joining can attend those meetings. And as of now, we have all the developers essentially are from DDCC. We had previously few contributors from different companies, but then they worked on the project for some time and then they dropped off. The latest one was from Inspore. We had one developer working actually with us, but recently he stopped contributing and we're not sure when he'll be back. As far as the functionality is concerned, we have upgraded the code base to support Fabric 1.1. We've been doing some of the cleanup that's required to support different platforms. So a lot of the work in this quarter has been about cleaning up the code, react-taking it and to make it easy for, in fact, to make so that everyone else, maybe somebody who is new to this code base can also contribute. So that's the work that's been going on. And also we've been talking to the AWS folks who created the template out of the Fabric as well as the Explorer, trying to work with them and to see how to improve this one so that it's much easier to package it also. As far as the functionality is concerned, we think we are getting very close to what we want to achieve. And since based on the G-RAS and the stories, it may not be very clear actually what is the scope of this project. We are creating a requirement document that has detailed functionality and we'll post that also into the repository. And one last thing because this is really a UI application, we are looking at the usability. So we are working, we're going to work towards improving the look and feel plus also how the application flows. So that's really the only significant thing that's pending. There are a few things when we, especially regarding the Fabric, there are several features that are not supported as in when we find the things that needs to be available for Explorer, they're not supported, we are raising Gira tickets for Fabric guys, Fabric team to work on. Other than that, the only request I have is anybody who is anyone of you who is interested in contributing to Explorer, if you guys can join the project or if you know anyone who is interested, if they can join and help us extend the support for other platforms, that'll be useful, very useful because otherwise we won't be actually be able to get out of incubation right now. DTC is the only one that's actually working and maintaining the code base for Explorer. Any questions or comments? Do you support Fabric 1.2 beta, have you tried it or? Not yet, we haven't yet tried 1.2. Okay, we have time for that, just wondering. Thank you. Okay. I think maybe coming out of the last update, there was some interaction with the contributors who had provided the Sawtooth Explorer and the beating of some collaboration there to bring some more contributions into the Hyperledger Explorer project. I don't see any that was selected in the update. Could you speak a little bit about it? Yeah, we had, right after that, we had I think probably two calls with them and then there was no activity and suddenly just the last week, they said they are going to start working on it. So other than that one email, we don't have any update as to what the current status is. So maybe they'll have some free time to work on this thing. I can probably report that in the next update, but so far they haven't done any work that we know of. Okay, good that it sounds like there's maybe something coming soon. Yeah. I think I've got a note in my inbox that I haven't gone through yet from Tuesday that seems to have some design right up in it. So there might be a little bit more meet behind that now. Okay. Yeah. So I related this update to include that also that pocket is working on it, right? Yeah, so that would make it essentially two contributors, right? DDC and pocket. I think we would need at least one more contributor to that out of integration. Any other comments or questions? So what functionality are missing in fabric? No, there's decay. What are the known issues if you want to integrate this? So it's not necessarily known issues. For example, a block hash, right? Block hash is not, there is no API for that. Everyone seems to be, they have to calculate the block hash. Yeah. Instead of everyone having to calculate, I think it would be nice. Yeah, it's either the API or the fabric itself provides that one, right? That's one and there are other, for example, I have no way of showing in the node explorer what's the status of the node, right? The node is actually connected to the network or there is, or is it, are there any issues with the node, right? So the node status APIs are not available. There are other, I believe, for example, the block creation time or smart, the chain code deployment time, few things like that. They can be inferred by the, when they are included in the block, but not necessarily, you know, they're not, those timestamps, they're not directly available from the VHL. So we have this list of few things I can send them out to you guys if you're interested. I believe the team has created the geartickets. It's not there at least in the process of creating them. Okay. So it's not, it's not that there are like issues. It's more like you are waiting for some more functionality that you would like to have in the SDK so that you can operate better, right? That is true. It's not necessarily issue or anything like that. It's just that we need more. I understand, I understand. Okay. I think most of the 1.2 SDK work should be wrapping up next Friday. Yeah, yeah. We're looking at API soon so you can start. And actually the thing that I was thinking would be probably most interesting and explore would be the service discovery information to be able to understand, you know, what are my peers, where are my ordering services and that sort of thing. Yeah. Like monitoring, like here's something we don't have, but yeah. Well, there is service discovery is available right now. There's a metrics API, right? Yeah. Okay. Okay. Then in that case, we didn't look into the 1.2 API because then it has, looks like it has a lot more information than. Yeah. Yeah. Okay. Yeah. There's a metrics GRPC API, but I'm not sure that there's anything in there for that. Okay. The best thing is just, I think that's, Yeah. Yeah. Sorry. Okay. Thanks, Parta. Okay. Any other questions for Parta? I mean, we, you know, we had a really pretty good discussion about. Um, You know, a Roja and, uh, how to, you know, to grow that community. Um, I don't know part of if you were on for that, but, you know, there's a number of different strategies that people can take to try and, you know, grow their committership and, you know, potentially grow new maintainers and so forth. Um, were you on for that discussion? No, I think I joined at the very, you know, the end of the discussion. Yeah. So you might want to sort of go back and review the, I dig up which, which week it was. Um, and review the, the audio for that. I think there's probably some great insights that you might be able to gain as to how to, you know, how to get people to come and play in your sandbox. Um, and so I would, I would encourage that. Okay. And then, you know, I think, you know, reaching out to Rai and, and, and Tracy also, you know, for assistance and how we can help you to grow your, your team there a little bit. Okay. I will. Yeah. So I'll get in touch with both of them. Right. I'll review the audio also. Awesome. Okay. Ram, are you there? Hi folks, Ram here. Just finding the unmute button as well. Can you hear me? Yeah. Yeah. Um, yeah. So, uh, architecture work group, uh, update, um, you know, uh, the health has been, the health of the working group has been great. Uh, we have the same steady participation of eight to 12, uh, folks, uh, with a few new participants coming in. Um, some of them, uh, um, uh, a few of them have become steady participants, but most of them come and go. Uh, but there's been a solid core of participation, uh, uh, representing, uh, multiple companies and projects. Uh, we're making a steady progress on several work items. Uh, we published the second architecture paper on, uh, smart contracts a few weeks ago. Uh, and, uh, you know, I'll talk about the other work items, uh, um, below. Um, so, for me. Bless you. Um, so there are no major issues at this time. Um, uh, I would say the main thing we'd need help on is to kind of encourage participation, uh, especially from, uh, the different projects, uh, you know, like, uh, you know, all the other work groups, uh, and, uh, projects here. We have contribution driven. Um, you know, if, uh, uh, uh, we, uh, you know, it would be great if, uh, you know, we could kind of encourage, uh, projects to nominate, uh, uh, our work group, uh, uh, uh, participants. So, and, you know, encourage them to kind of, uh, uh, attend the meetings and contribute. Um, you know, all of us are busy in the projects with releases coming on and so forth, but, uh, you know, this is an important, uh, um, you know, community effort. So, uh, it'll be great if we can kind of, uh, uh, have, uh, participation from all the active projects. Um, so, um, you know, we'd ask for the TSE's help, uh, to see what we can do more to kind of encourage that. Puts questions on that. Uh, overall activity in the past quarter. Um, so we've been, um, uh, following two parallel tracks we meet every other week. Uh, the main track meets on Wednesday a.m. And, uh, the privacy and confidentiality track alternates on the other, other week on Fridays. Um, and, uh, um, we are, uh, so, uh, as I mentioned, uh, on the main track, we've, uh, completed, uh, the smart contract paper and we are working on the identity services, um, you know, functions and when that gets done, uh, we'll convert that into a paper as well. Uh, and we're just kicking off discussion on interoperability. Um, privacy and confidentiality track, Mick drives, uh, that and we're making steady progress, uh, on, uh, developing an ideal model based on a trade finance use case. Um, and that's going, um, steadily. Um, so, uh, work products, uh, we are working the next, uh, next work items, uh, will drive work products. One is on the identity services paper and the other will be on the privacy and confidentiality paper. Uh, I already mentioned on the participation, uh, really need your help to kind of, uh, get more, uh, folks, uh, from the projects to participate. Thoughts, suggestions, questions? Yeah, I've, I've heard, uh, mention of this ideal model, um, recently and I wonder if, if you were, were one of the other folks on the, uh, on that track could just say a little bit about that. So I'll do my best not to butcher it and heart can jump in and save me when I do. Um, the ideal, the idea behind the ideal model is to describe essentially how the system, how you expect the system to behave using, um, kind of idealistic assumptions. So for example, you, you describe it in terms of a trusted third party. Um, and the, the characteristics of that might look like, um, uh, something that can process messages in a particular way, which gives us a way of representing, um, uh, something that has the characteristics of a typical distributed ledger. And then you can use that ideal model, um, as a basis for comparison, um, uh, an analysis of the existing implementation systems that you have. Um, and you can use it to drive, um, uh, requirements, um, uh, and requirements discussion, which actually is has been kind of the focus over the last few weeks on it. So it's, it's a vehicle for, um, both uncovering assumptions, um, and ultimately for, um, uh, providing a basis for analysis. Yeah. Um, that's exactly right, Mick. Um, fundamentally Dan, the basic idea is that it's very difficult to analyze exact security properties of a blockchain, right? You know, what about traffic analysis? What about, you know, kind of all of these other potential side channels that may show up. So the idea is if you can take your blockchain system and show that the security is equivalent to something much simpler, then you effectively gain something because you can look at the simple thing and say, okay, well, you know, these attacks, like traffic analysis and other things are very evident here. You can really see, uh, see what's going on. Um, and this is, this is called the, the ideal model. Uh, it goes back to the definitions from this thing called universally composable security. Uh, but when it's, as Mick pointed out, it's just a, it's a way to sort of see security properties about a system and to, to write them down. Uh, because otherwise they're, they're, it's very, very difficult to, to concretely say things about security. Did that answer your question? Yeah. So my imagining aspects of this are like showing indistinguishability to a random oracle. So using techniques like that. Um, sort of, yeah, but it's basically like, uh, saying that you basically say that any adversary that can, you know, do something, some kind of attack on a blockchain can also do the same attack on some kind of very simple system with a trusted third party. Um, and, uh, and you can, you know, look at that trusted third party system. Uh, and I should say the vice versa is the more important direction, right? Any, well, yeah, okay. So you can look at the third, the simple trusted third party system and it's very easy to see what the security guarantees are, right? Loving like traffic analysis or other things like that. And you can say, you know, if an attack is here, it applies to the blockchain, but if not, you know, it doesn't. So it's, it's, um, yeah, that's basically the idea. It's a way of just exact, it's, it's a way to kind of, uh, to write down the security of a blockchain system in kind of a simple and concrete manner because otherwise, you know, um, otherwise, you know, things like traffic analysis, uh, in particular, you know, for some blockchain systems, you don't care. Others you might care a lot, right? Uh, and it can be difficult to analyze whether, you know, uh, whether something is a problem for you or not. And so that's what the goal of this is to do is to simplify, to simplify things so that, uh, so that you can make a decision about whether the system is secure for your purpose, I guess. Got it. Yeah. We've had, uh, interesting discussions in the word group on the, on the name itself. And it seems like ideal model is the, uh, the, the standard term used in the security research community. Uh, you know, the rest of us probably would think of it as more of a reference model to allow us to analyze and reason about the system. You can thank Ron Canetti. Um, just to chime in, as you know, uh, Dan, uh, the engineers, um, viewpoint and the, uh, you know, the, the abstraction that is being built around the TPP, uh, I mean, uh, TTP, uh, you know, Trusted Third Party, because it has other meanings in other contexts. Um, that's what we needed to get resolved in the privacy and confidentiality track, which is, uh, what, you know, a lot of that debate was about because we are also used to creating abstractions. Uh, but you know, we, we were, uh, basically debating the use of the, the validity and the use of this technique in order to model something like trade finance. Uh, so that's all I had. Uh, any other questions and comments? Um, you know, one request would be to see, you know, is there, um, what else we can do to kind of encourage the projects to kind of nominate someone to participate? Uh, there any thoughts on that? That'll be great. Okay. Thanks, Ron. Thanks. Um, who's, uh, Dave, who's beyond? Uh, Chris, I'm doing the lab's update. Tracy's doing it. Okay. Well, I'm just going by lab email. So, sorry. Yeah. No worries. Yeah. Uh, so yeah. So this is, uh, the first time that we've been doing a, or that we're doing a lab's update. Um, so we've been kind of in process for at least a quarter, if not a little longer. And, uh, during that time, we, uh, put together a process for proposing a hyperledger lab. And we've had, uh, since that process has been put in place, five different labs that have been proposed to, to the stewards. Three of those have been accepted. And, uh, one of the proposals is still in process. And then one of them was, uh, deemed out of scope and was withdrawn. So of the three that were accepted, uh, we have private data objects, which is, uh, technology for functionality preserving off-chain smart contracts. Um, it's been fairly active, uh, since it was created on March 2nd. And, uh, we have the crypto library, um, that was created on March 29th, which is really intended to create a shared, uh, cryptography module for cross-project use. And then we've had, uh, S-parts, uh, software parts for doing SPDX and tracking kind of the open source components that are used to build, uh, a piece of software. So, um, this update was actually created, uh, updated on Tuesday morning. Um, I, I did notice that, uh, yesterday, as of yesterday, there was at least one PR merged into the S-parts. So all three of our labs that have been accepted have had activity since they've been accepted. And so that's a good sign. We're also starting to see some labs, uh, projects come in that are based on the interns, uh, internships that are happening this summer. So, I expect to see probably some more of those. I think the labs is a good place for us to do, um, internship projects. Obviously, with internship projects or any sort of labs that come in, we, we need a sponsor for those projects as, as we agreed to when we created Hyperledger Labs, um, the sponsor has to be either a TSC member or a, um, a project maintainer. So, um, look to see, you know, if there's internship projects that make sense for you to sponsor as a TSC member or a project maintainer, um, that, that makes sense, then, then definitely feel free to, to offer your sponsorship to those projects. So, yeah, I mean, that's a very quick update, but lab seems to be going fairly well so far. Thanks, Tracy. Um, I saw there was, there was a little bit of chat, uh, going about whether to say open up JIRA projects for, for labs. Uh, could you speak just in general about the overhead in, in running the labs at this point, are there any, um, I don't know, hot spots that you see or, or coming on the horizon and then if you've got any thoughts specifically about, uh, the JIRA discussion. Yeah, thanks, thanks Dan for bringing that up. Um, so, uh, hot spots as far as running labs, uh, there doesn't seem to be much, um, in the way of, of overhead, right? Uh, really the stewards are, are doing a really good job of reviewing lab proposals as they come in, um, you know, and then once, once they've been approved by, um, at least two of the stewards, we create the, the Github project in the Hyperledger Labs organization and that's a fairly straightforward process, right, as far as just copying the, um, MD file that was, um, the original proposal to the README and setting up the, the actual project. Um, and then to talk about kind of the JIRA side of the house or the issue tracking side of the house. Um, you know, I, I don't think we really had discussed what, what we wanted to do there, right? I think there was some assumptions made by people who, excuse me, um, you know, assume that Github issues would be the, the mechanism for tracking issues for labs. Um, but then I think it was the private data objects, um, lab that had requested a JIRA project be created and um, we, we had a, as Dan mentioned a discussion on the labs rocket chat channel about, um, you know, whether that's what people expected or what we should do there. Um, and we didn't really come to any sort of conclusions and so I think this is definitely a good topic for, um, TSC discussion as far as, you know, what, what process we want to follow for, um, you know, whether we create JIRA projects, um, on request only, whether we create JIRA projects for all lab projects, uh, or what we really want to do there. But if I remember, um, this is Vipin, um, we had discussions on this topic and, uh, I think, uh, several people including Arno and myself said that there should be low gating factor for the labs that was the whole reason the labs were set up and we shouldn't make, uh, too many demands on exactly what they should, uh, be following. Um, so I mean, I guess the TSC has to opine on that particular aspect of the labs that it should be an open situation. Once you are in the labs, you, you have uh, lots of freedom. Um, obviously you have to follow some, uh, processes, but we cannot use, uh, you know, heavy process, sort of heavy process management, and that's why it's not a project, it's a lab, uh, and, uh, that was discussed. Also, one more point on this was that, um, uh, in order to add, uh, new labs towards, uh, Rai's name was proposed and we, the stewards felt comfortable that he should be added, uh, but according to the charter, it is, uh, meant to be approved also by the TSC. Should we just take a quick second and just vote on adding Rai? Hopefully that will be anybody opposed to adding Rai? Going once, going twice, he's added. Outstanding. Um, just to comment on the JIRA side of things that, which is the flip side of what what, um, that Ben was just talking about, which is we already have a JIRA that we're using for the private data objects work internally. Um, we would like to be able to move as much of our development process as possible externally. Um, and we were just kind of, the question for us was really what resources are available to us, um, in order to do this as opposed to, you know, we're not looking for JIRA to be a requirement for the projects, looking for resources that we can use in order to start establishing that collaborative development process. Right. So this is Anu. I think that's the, indeed the point. I mean, as, as VPIN said, I mean, we didn't want to put much, you know, requirement on the labs, but the question is really on the other side, how much requirements can labs put on the staff or the resources, the infrastructure in general? I mean at the end of the day, you know, I was being conservative in the discussion we had on the channel. I said, well, probably we should just stick to Gita because it's there and that's good enough. But you know, I'm not firmly opposed to providing JIRA for labs who want it if the staff feel like, well, that's a very small burden to them. But as I pointed out, the question is, well, then where do you draw the line? If we just say, well, people get Gita repo, they get the issues, you know, that comes with Gita, but that's it. It's easy to just stick to that. But, you know, if we say, oh, they want JIRA, sure, give them JIRA. The next one says, I won't gear it and the next one wants what not. I don't know. You know, I don't know. So it was just seem easier to just say, nope, stick to Gita. Thanks, Arnaud. Appreciate it. By the way, the serious side of that is, like I said, we already have the existing processes that we have. We already have the resources. We're trying to find a way to get a machine outside our firewall so that we can do some CI integration on our own. I think GitHub allows us to put some additional hooks and we've been trying to figure out if we can make that work. Having not having administrative access does make it a little bit challenging to add some of that stuff in on the GitHub pieces of it. But it's really just a matter of trying to figure out what the expectation should be. Are there best known methods for how we should do this? We could share with others as well. This is an ask, not a demand. If not, we'll figure something else out. I think maybe this is sort of also the point at which you start thinking about, well, is this really a lab or is this a project? That is a very good question, Chris, and I'm happy to explore it. The biggest issue for us is just sort of how long and how broad is the commitment that we're willing to make to it. And so precisely the reason for doing the labs is to try to get others who are interested in the technology so that we can get that persistence. So I would be hesitant to propose it as a project until I felt like we could step away or we could change our role and the project would still be valuable enough to others that it would continue on. That's my criteria of making that switch. If that makes sense and if you have other opinions, I'm happy to talk about it, but that's the approach we've been taking on it. But that's also really what incubation is for. I think it's worth giving it a little bit of thought of potentially incubating and maybe the additional socialization that I know you're doing and maybe some additional socialization at the Hackfest at the end of the month will give you some fodder to consider maybe this should be incubated. I think that's a good question, Chris. And I'm happy to have that discussion and I would appreciate your input on that obviously. We've already got signed up for a session at Amsterdam to go through this as an intro and tutorial. We can really boost it a little bit even if we don't call it incubation. We spend a lot of time both on the GitHub kind of CI integration and with Gary. We can share some experiences. That'd be great, Jonathan. Sorry, to continue that thread really quickly, I'd be interested and curious to hear what people think about when some of these lab projects should become regular projects. Something like obviously the crypto is on my mind. I'm with Mick. I'd be curious to hear Chris what you have to say about that. I think that that's probably another one that maybe starting to get a little bit of interest outside the initial cabal that cooked up the idea and maybe that's why we're here. We're all trying to feel out what's right. But once that does start to happen, maybe that's a good time to start thinking about bringing it over and doing a formal incubation. It gets care feeding, you can use the tools and so forth. I feel like we have tried a little bit here because independently of whether some of these projects may be ready sooner than that or to move to incubation, the question remains when it comes to a lab what tooling are we willing to provide? Could somebody from LF comment on the overhead for creating another project in JIRA? I really don't know off the top of my head if this is just a trivial thing or if there are four other projects or other labs rather wanted to do that if that would become oppressive or costly. So what are the differences? It's just the JIRA, the Github is the same, right? And the official CIEx support, what are the differences in terms of investment at the moment? It's just the JIRA at the moment, right? Yeah, I mean this was just specifically around if a lab wants JIRA so that they can have a whole overhead process. Creating a JIRA project is a pretty low amount of effort. What I would propose instead is that instead of each project getting one, we just create a labs project and then labs projects can file their bugs under that. Yeah, we can use a component in JIRA if it's really not a lot, if it's not like hundreds and hundreds of issues per project, per lab, right? We can have a component or something like that to differentiate. Would there be an easy migration from components in one project into a new project if a lab graduated into its own project? So no commitment, but we had a very strong JIRA guy and he used to use the JIRA query language and he can slice and dice everything you wanted and then he would take that output into a new project. We needed a JIRA expertise here a little bit, but he used to do it like an hour or two. Would that be more effort rather than just creating a project from the get-go? It's a little bit more effort, yeah. It's a little bit more effort. It would be more effort. I just, I'm a little bit leery of a ton of JIRA projects. The links are going to change as well, right? That's the main problem that we had. So you have like labs one, two, three, right? And then I'm going to move to my next big incubated project and the issue is going to be number two. And then what I do with the links, right? So it's a little bit more work, right? So, yeah. But JIRA is not that easy for the beginners. Although it's already bought by Microsoft. So I'm just going to press enter. I had a joke waiting if you look at the chat. We should check into Microsoft, right? We shouldn't check into GitHub. You can use Visual Team Studio, whatever the hell it's called. No, no. I think that GitHub is actually easier. Honestly, it is easier. It's like, you know, a pull request and the flow is easy. If it's a small project, you know, the overhead in bootstrapping is almost none. This is Leonard. I just wanted to know. Lab, which is similar to having a sandbox, which literally there is a need to allocate resources for whatever will run in that lab. Because potentially you could have several, you might say, many projects running at the same time. So what would be the process for allocated resources like time, space, cycles in that sort of sandbox environment? Is this something that we need to consider or not? So I was going to say, I heard, you know, I mean, we, the number of labs we're talking about for now is obviously pretty minimal. And quite frankly, I was, I wasn't sure how much how many labs would be proposed when we launched this whole thing. Clearly, we haven't seen an explosion. Of course, you know, that might change in the future, but maybe we don't have to worry about too much, you know, having an explosion in labs that becomes completely unmanageable. Yeah, we can look at the solution for the, let's say for the coming quarter. And then in three months we can revisit, right? I just want to bring up maybe something that we talked about when labs were originally created just to make sure that we're thinking about this, which is the fact that we don't want to confuse labs with projects, right? And, you know, just let's make sure that whatever we decide we're not confusing labs with projects. I support Arno and Tracy right here saying that we shouldn't be overthinking this. What would happen if they migrate to projects? Then of course, you may have to put in some effort into doing that, but the issue that we're discussing here is more to Arno's point is whether resources should be available from a general pool to a specific lab project to do JIRA and if so, you know, what kind of resources, how much commitment to that point? What is the effort needed? What I heard there was it's low effort. I'd say let's take an experimental approach to this and let's let this lab have a, let's give this lab a JIRA project and if that turns into debacle then we don't need to do that for future labs. And if it turns out that it's no big deal then we know that's an option open to the labs that want to use that as part of their community building. I think that's a reasonable proposal given that the cost seems pretty low. If the number stays low. I'm happy to keep labs like even though separate than real projects that I incubated and voted for I'm happy to kind of still make people feel like a first class citizen even though it's just gauging the water and get people used to it. So the switch is going to be easier actually. If we have a JIRA project and then to go to incubation it's actually less overhead if you think about how many will get incubated, right? So we still need to make sure that they remember the dialogues. So this is a lab, be careful, this is a lab, be careful. Don't trust these people. Yes, I agree with Tracy. We're at end of Java I think. So thanks everyone and we'll talk at y'all next week. Ciao. Thanks a lot. Have a good day. Bye. Tata. You cannot kick me out automatically. I'll do it. Bye.