 Okay, we're recording. All right. Hello everybody and welcome to the Hyperledger Technical Steering Committee meeting. Everybody is welcome to attend and participate as long as you abide by the anti-trust policy and our community code of conduct. Jumping right into the announcements this morning. Salona, do you wanna take the first two there? Sure, just letting everyone know that the Sao Paulo Brazil bootcamp is happening next week. In fact, Rai is in the air. I'll be in the air tomorrow and Dave is flying in this weekend. We ended up having some issues with the venue and some others in regards to marketing. So we've capped attendance at 70 and we'll be reaching that. So, and the agenda is actually looking pretty full for the event at this point and that a lot of people stepped forward to do presentations. In fact, it's so far, it looks like it's gonna be very active in regards to session leadership. Fantastic. Thanks. But it presents a problem for TSC next week and basically the majority of us will be either having flown in extremely late the Wednesday night before or will be flying at the time that the TSC meeting is next week. So I would like to request that someone record the meeting and take notes so that my team can sleep and not try to do anything from a plane. Hart, you're used to kicking recordings off for some of our meetings. Would you be able to kick off a recording? I would love to, but I'm gonna be gone next week. Here, I thought I had you pinned down right away but you were one step ahead of me. I should try, Dad. Let's see here. Who else is used to kicking that off? Hey, Simone, this is Daniela. One of us on our team can do that as well. Dad, I think Mick is used to this. Can he do that from a dunk tank? I can do it if I'd need the host code to do it, that's all. I got it. I got it. You got it. All right, great. Thanks, Mick. Okay, and then we still have the ongoing call for comments for input to the board for 2020 planning. The sooner you get those in, the more likely that we can get the board thinking about those. And then we're coming up on the 4th of July holiday in the U.S., so I think we'll be canceling the TSC meeting on that day. All right, Saloni, you had some traction on the thread that you submitted about chairs or points of contact for projects. Yes, so the reason for this is basically I could give you all a really long list of questions that the CAs handle and take care of in regards to contacting the projects and helping organize a bunch of different things and things of that nature. And as the projects grow, we have a really hard time figuring out who always to talk to for all of the projects and when. And so this was basically an attempt to formalize it. There was no, the only reason we honestly chose chairs and vice chairs is because that's what we call the work groups and sakes. There is a precedent in LF projects for projects having this. And I posted some links to some of the ones that I wouldn't found on the Google search. Though they don't always call them points of contacts or chairs, they call them like the project leader, a bunch of different other things along those lines that indicate that. And so it was basically the reason my team was asking for it is just to facilitate us to help you better so that we knew who to contact because a lot of times when we do ask the maintainers I feel like they're normally busy coding and such and we don't get responses. So that's why we were looking for someone who is more of not necessarily a lead developer but a project type person. Or one of the even one of the other things was like a volunteer lead or something along those lines. So that was the point about doing that. And because of the fact that it was seen like such a big change that it did seem like something that should be voted upon. But there's a lot of discussion but I didn't see any clear thread and my misunderstanding that there is a clear thread and that there is something that some of them want to pose as something that is ready for a vote. I don't know that there was a clear thread or not but one thing that stuck out to me is it looked like there is a need for a security point of contact, a marketing point of contact and maybe a TSC point of contact. That I guess the latter would be about making sure that the reports get out in any decisions that come from the TSC get back into the project. So I think that maybe something along the lines of listing those points of contact on the Wiki or something should maybe satisfy that. Were there other sorts of points of contact needs? Well, so that there are, there's a lot in regards to documentation, certifications, things of that nature and just general where to go, especially on some of the larger projects in that people come in and they're like, we don't know exactly where to go and find things and who to ask and who should be in charge of those things. And so that's why we were asking for something kind of generalized. And Dave mentioned that he maintains already a set of security contacts or for each of the projects. I think in the spirit of trying to be minimal, you could always have on a webpage for a project. Here's other people to talk to if you have questions about documentation or something like that, right? Other people who could be volunteer, points of contact, we're just trying to, in terms of kind of formal tracking and just trying to make sure it's something that each project has. If it was one POC per project, that might be just enough, minimum viable governance or minimum viable structure. Well, questions should be going to like the mail list of the rocket chat, right? You don't want to designate one person, because that person will get swamped. Oh, absolutely. We always try to direct people to those lists. It's just sometimes they do, they go on a list and they ask a question and they don't hear a question, not that this point of contact needs to be somebody chartered with answering every question that goes unanswered. But I, you know, it's still sometimes, it feels like there's a lack of a human. I don't know. Well, this is something we've found with the Indie project is often you'll want to ask a question to see what the status of something is or maybe ask the community architects for a request of some place to put something or some infrastructure. And if we have a point of contact like it was described, it helps make sure that there's not, you know, any phishing attempts going on or that the general consensus amongst the maintainers isn't undermined by one of those kinds of requests because that person can help point things back to the right mailing lists and make sure that all the maintainers are aware of what's going on. I'm confused. So is the point of contact everybody on the planet can use that? Or, I mean, again, I think, you know, as Mark said, the mailing lists are, that's what they're there for. I mean, the security contact makes tons of sense because they have a specific role. They're vetting security vulnerabilities and then they're managing the vulnerability through the life cycle. It's a very different thing than somebody that's just, again, I don't really quite understand what we're trying to accomplish here. Is anybody from the marketing committee on that could speak to the needs for a marketing contact? Let me ask a question a bit differently. I mean, how do you suggest that we identify those people? How would we describe their role and ask for volunteers? So I can give you an example. It's Marta here. Just few days ago, we were contacted by CoinDesk. It was clear that they didn't quite understand Hyperledger and we needed to clarify some things and the reporter became very responsive and now is asking if he could interview some maintainers to get a better understanding of all of the projects and ask some questions and features and so on. So of course, in a week try to keep up to date. Community architects are keeping up to date but having someone who is that point of contact for instance, for that would be wonderful for age-recessed projects. That's kind of the role of the TSC chair. You try to give me more work. Yeah, yeah. But I mean, I didn't, just giving you the follow-up question is specific to a project and you could go to a mailing list publicly and say, hey, there's a reporter from the newspaper who wants to do a story and that's fine that sometimes you wanna go to an individual and kind of those of us who've been around some of these projects for a long time would know to go to certain individuals who know that part of their job is kind of advocacy to folks like that. But I think there's been a few times we've gone to lists and everyone's been busy. That's just human nature, that's fine. Sometimes when three people are responsible for a thing you kind of get less engagement than if one person is and I know they can delegate out to the other three. Not that that one person has to answer every need themselves entirely and bear that burden on their back. Yeah. So Sawtooth has adopted a governance structure from Rust and there's separate teams broken out that are sort of discipline-based and that might be another model to take a look at for the larger projects. I am hearing still though there's two or three rules that need points of contact, security, marketing and then I'm not clear if there's another one for TSC matters or something like that. Maybe that's really just all the maintainers. How does the Hyperlegia staff view this role compared to like a chair on a prom working group or CIG? We were looking at it as a similar perspective like normally if we wanna know something about interoperability or someone comes up and says, hey, we're doing this paper on blah, blah, blah, who do we talk to? One of the things we sit there and do is we're like, oh, you should go talk to the chair of the scale and performance because this is a scale and performance issue and they can probably point you towards some of those topics as to what's going on here at Hyperlegia. And so we do stuff like that all the time. The hard part becomes when it becomes a project. We don't always know exactly who to do it, who to ask for it. And sometimes, so we can either send it to the entire list which sometimes isn't appropriate or we can try to cherry pick certain individuals but then sometimes people's feelings get hurt but they were not the person picked. And it becomes also where some of the stuff is so specific that even when we generally, we can't generally post it to the list, it still also doesn't get responses. A lot of this has to do with honestly the lack of responses and then the fact that the CAs literally go and chase down individuals to get things done. And so things that shouldn't take a huge amount of our time can become incredibly time consuming. And we can't be quickly responsive to any of those people who are coming in with those requests. Okay, so generally all technical quests go to chat or the mailing list and the communities should be handling that as best they can. But I'm hearing on individual marketing. It's not really always technical requests, Dan. Like if someone has a normal question, question, yeah, we send them to chat or we send them to the mailing list and honestly we send them to chat the majority of the time because we found chat to be more responsive than the mailing list. But these are like broader questions than that. It's like a company going, we're thinking of using blah, blah, blah, should we? And or I'm doing a paper on blah, blah, blah, who should we talk to? Or we need to work on something like certifications or we get training or we need to validate that we're doing something with the press but we need to validate that the technology is correct inside of it and maybe it's diverse projects or there's just a really wide swath of things that end up happening. Yeah, so the things that I heard in that that might require more individualized responses are requests from the press where you need one or two people engaged there. So that makes sense to me. Most of the other questions sound like questions to the maintainers. Or to the TSC, right? I mean, something like interoperability is not a project thing. It's something that should be addressing from the TSC or the TSC chair. There's not just one individual that's gonna necessarily know all these things anyway. And so I think it may make sense. In fact, it probably does make sense that a project identify from a marketing perspective what do we talk to? But even then it's gonna be a little bit dicey because if you have projects that are truly diverse then you have to be careful that whoever it is that you're reaching out to isn't going to be necessarily putting their own company spin on it and so forth. So that's obviously something that you probably want to have actually multiple contacts. And but again, I think that that, and maybe we can ask that that be part of when you're trying to establish a project who do we talk to from a marketing and PR and analyst perspective, right? Is that person may not actually be a maintainer. I can appreciate that. But that's a different story than again, some of the questions are coming in are of a technical nature. Some of them are really the TSC chair and or members or just bring it to the TSC. And then we can figure out who maybe needs to talk to. Yeah, okay. I think at the TSC, if the TSC feels strongly right now that they rather not vote to have a point of contact recognized as something between the TSC and the projects or some other official part of the infrastructure, that's fine. I mean, we'll just continue to take issues that are inbound either to the maintainers or the TSC as we see appropriate or just internally amongst the CA staff try to maintain a sense of well, who on a given project tends to be most responsive to our queries and we'll just go from there. And maybe there's just one other footnote here. It sounds like with the larger projects having lots of repos each project should probably already have a maintainers file. But maybe it's not clear across the many repos because you're gonna have different subsets of maintainers. But I would think that each project tends to have like a core repository. And people can check me on this but I'm thinking that the maintainers listed in that core repository is probably the best single source of identifying the current set of maintainers for that project. Yep. And again, I mean, that's one of the things that actually I put in my note and that is maybe we should make it a sort of a policy or a best practice to have, I mean, and just about every one of them does. I think I only found two or three that didn't actually have a maintainers file. But have a maintainers file that lists who the maintainers are and gives their contact information, that would be, I'm fully supportive of that, making sure that those people are easily found at the top level repo or in the wiki for that matter. Okay, well, I don't think we need to belayer the point. We can move on. It sounds like there's strong opposition to it. So that's fine. We'll manage. Okay. Hopefully still some good outcomes from that discussion and clarifying roles and responsibilities. Moving on to the life cycle committee updates. Arno, I kind of put you on point for this. Looking right now for just sort of a feeling of how things are going and whether you feel like you can predict some sort of end date. Can you hear me well? Yes. Okay. So yeah, so we have set up a wiki page. We have invited everybody to go and at least issues that we thought we were to tackle. And we kind of, I waited a little bit, took a little bit of time. And then I decided to try and move the ball forward by pushing forward with a bunch of proposals for resolving those issues. Admittedly, some of them were kind of blunt and maybe to an extent provocative, maybe in some ways. But it did get some reaction. I have to say, using the wiki as a bit of a challenge, I try to not get to schedule calls. I think we already have too many calls. I'm keen on having more calls and trying to figure out the time slot that will work for everybody. But using the wiki, quite frankly, is a bit of a pain. And inline comments, we started with that, that doesn't really work. And to my dismay, I have to share with everybody that inline comments are pain in the butt. You can't have them all open, visible, and there's a very long-standing open issues against confidence wiki. And they have no plans to solve the thing in time soon. So everybody's crying about this, but they don't seem to care. So anyway, we are using comments against the page itself. So they're all at the bottom. And I've tried to organize things by hand on issues so we can have a threaded discussion. But the response has been, I would say, fairly mild. Some people, as you would expect, are pretty vocal or there is not so much. So my plan is to try to take another path at the proposed resolution based on the input that was already shared by some of the members and try to see if those proposed resolutions work better. Some of the ones that I put forward were rejected by different people or amended in different ways. So the plan is to have another go at it. In terms of the timeline, because I know and I understand the need to try to basically set some targets, that's much harder to do, honestly. But my goal is to not try to solve everything and get back to the TSE with the whole list of issues resolved or proposed results. But to try to find some of the ones we can at least agree on and bring those up to the TSE for approval by the TSE. Because all of that is, of course, just legwork for the TSE. So I think that the TSE calls the final decision on any of those. And we may also have some discussion in the TSE when we come with our proposed resolution. But so realistically speaking, I think in two weeks from now or three, now, it's the 4th of July, canceled, quite understanding of me. I'm hoping we can have at least the first batch of proposed resolutions. OK, that's great progress. It does look like quite a bit of work in that conversation. He's been doing a great job. Thank you, but if anybody wants to see what's up, I mean, as I said, from the week, everybody has access to the week, so feel free to pick and contribute if you want. I wonder if it would help put all the try to split those resolutions onto separate pages and then have the comments at each one of those pages? So quite frankly, that's part of the challenge is everybody has their own way of wanting to address this. And I tried to split them. The next one answers several of them together. And it's hard to keep everything organized. So I don't know what the best structure from the week keep one of you with me. It's part of the experiment to try to use the week as effectively as possible and have some kind of attention among the group, right? For those of you out there who do use Wikis a lot and that incorporates a lot of commentary and such, I mean, Wikis are great as kind of, I think, documentation tools, but don't necessarily sell themselves as like brainstorming tools so much as well. But for those of you who do use Wikis and other tools at the same time, what are like the best tools for that and what are some processes that you'd recommend? Salona here, I would recommend what Dan said about breaking each issue into a page because we've also got the feature in regards to polls and some other different things. And a lot of the features WikiWise are normally per page because that's how they normally consider it to be about how to break out. Our note, I can show you easily how to make sure that that first page is an automatically maintained directory of all the child pages so that you don't have to worry about keeping them in sync or anything along those lines. If you wanted to go over what some of those features are, I could help you organize a little better. All right, sounds good. So just grab it. I'm happy to try, I mean. Okay, well, great. Thanks for the update and for everybody who's contributing on evolving the process there. Moving on to Caliper. We have maintainer contributor from Caliper to take questions. Okay, sounds like we probably don't have somebody to take questions so maybe we can leave Caliper on the docket for another week in case there's other questions to be satisfied here. I did throw one on just now looking for checking that we've got an alignment between Caliper and PSWG. I think we wanna make sure that the metric definitions and so forth are well aligned. I think maybe since we don't have somebody live to answer questions now, please make sure that if you do have questions on their update that that gets onto the Wiki and we can handle those asynchronously. I know a lot of the contributors for Caliper are in a time zone that's probably not convenient with this meeting. All right, and then let's see here. When I was looking at the calendar of upcoming reports, there is also a report due from Quilt. I have reached out to the Quilt. Yeah, it actually looks like Caliper was a week early and getting their report out. So maybe that's why they're not here today to answer questions, but it looks like Quilt is overdue. I've sent a note to the maintainers and most active contributor that I saw on that project to see what their status is, but we haven't had an update from them for a couple of quarters now. And so I think we need to start thinking about where this falls into the life cycle. We're gonna have a specific proposal right now, but I think it's something that the TSC members should start thinking about so that we can have a discussion about that if we need to make a resolution within the next few weeks here. So Quilt's in the middle of a rebooting process, which is why they're not doing the reports yet. And there's been some different things that Brian and I have been trying to address in regards to that before there's an official report out. Okay. So I guess that's the report. Basically, the report with Quilt right now is the only people that you'll see is the ILP people, but we're working right now to figure out how to make Quilt be more about generalized interoperability, which was the original proposal. And in fact, there's meetings about that that are currently happening. Yeah, I guess in general, I think when we have a project that may have run its course, I don't think it's a bad thing for that project to follow that life cycle through and be end of life. And if there's similar work coming in that wants to be created as a project that we see a regular project proposal for it with a new set of maintainers or if there's an overlapped set of maintainers. But I think that we shouldn't be afraid to shut things down. That seems to be a part of a healthy life cycle that we're gonna have things that graduate and things that don't graduate. Hey, Dan, this is Rosie. Hey, this is Dave here. So I'll go first. So forth, Rosie. Thanks. So Accenture is looking to bring in some of the interoperability work that they've done and we're thinking about bringing it to Quilt. So based on what you just said, should we be instead thinking about putting together a project proposal? Yeah, yeah. And I think if there's a collection of interoperability things that would wanna be an amalgam, then getting that as part of the project proposal is appropriate or if it's a standalone project with just that individual interoperability piece, then that's also good. And I think that some of the direction that I see in the project life cycle discussion is getting code into a lab first. And that might be another precursor if your work isn't already in a lab. I mean, what we were talking about doing with Accenture stuff and some other stuff coming in was coming back to the TSC with a proposal that was essentially something that was substantive enough for a vote that I would say here's a collection of code. It is, we're all still at an incubator stage, right? It's why Quilt is still in the incubator. There wasn't a question of kind of getting things into a non-incubator status that should still be considered incubator. Also, it's definitely not about removing the TSC's role as an approval step in kind of being a gateway, I'm sorry, being a gating factor for new code as it comes in. So the idea was we'd come and we'd say here are basically two or three additional kind of pieces that play together in the same way that say the piece of the Versa play together. They're kind of thematically connected. They're at the same level of maturity perhaps as the existing ILP Java implementation, which is all that we know of as Quilt today, and that having them together still benefits from whatever brand equity we might have put behind Quilt as an interoperability thing, the same way that Ursa is kind of where we're parking, share security libraries. And that helps prevent some bloat, or not bloat, it's not the right word, but creating too many new top-level projects for those who might be concerned about kind of this car at that level, right? So that's a preview. We weren't ready to, I think, make a proposal on that front yet. I, and there's also some of the subtext of the thing was if you have an amalgam project like Ursa, somebody who's roast these different, think about how to represent them here for them to do the organization and such, might it be easier to, you know, ask out for a different? I don't know if it's my audio inbound or your audio outbound, but I'm having trouble making you out. Out of our car. Yeah, me too. Okay, we caught some of those syllables, Brian. Got a referred syllable, yeah. Yeah, so I think it sounds like a good discussion, probably a good part of the life cycle discussion that Arnaud was leading. From my perspective, if it's mostly about branding that we've got some brand behind something like Quilt or maybe it's Composer, that's maybe where we want to think about, are we using the incubator the way that we want to use the incubator? Because it should be okay for projects to go away. We shouldn't, I don't think like that we should be too concerned about building a lot of brand equity in incubated projects. And the, yeah, I don't know. That's probably enough for now, but. Yeah, I'm kind of in agreement with that, Dan. I think projects should follow their own course. If people lose interest and they go away, that's the way the cookie crumbles. But if something's coming in from the outside and we're gonna try and do a lift and shift kind of a thing, I'm not sure. I think that should go through the regular process. Yeah, I would be against the lift and shift. I mean, if it comes in and enhances what's already there in Quilt and fits in, then it should become a part of Quilt. But if it's like, we'll throw this out, put this in and call it the same thing, that's not the way to go. Yeah, just from the perspective of what we're looking at. You know, obviously when Quilt was brought in to the entire hyperledger and the technical steering committee voted on it, right? There was some concerns about making it a wider interoperability sort of project. And so when we were considering at Accenture bringing in the work that we've been doing, it made sense that it should end the Quilt. But if what we're saying now is that it makes more sense to bring it in separately, that's fine. I wanna make sure I'm following the right processes. And so that's why I brought the question up. Hey, Tracy. Thanks, Tracy. Didn't you invent the process, Tracy? No, I think the process was in place before I showed up. Just out of curiosity, do you know when you'll have a document on that? So I guess not all would have to start working on that document based on the conversation that I had. I didn't actually realize I needed to put together something because I did think I was just bringing it into Quilt. So I will work on that with the team and we'll get that in place. We're just about through all the processes internally. And so this is a good conversation to have come up now. Good. Yeah, I think that if the maintainers on a project are still active and they want to welcome in more breadth in the functionality or scope, then that's a different situation than if the maintainers have sort of dwindled away and they're not active in a project anymore. Then in that latter case, it really feels to me more like new code should be a new project. The maintainers? It's a bit above both, right? Because when we had the conversations with Adrienne and the other name is escaping me at the moment. When we had the conversations with the maintainers of Quilt, they were definitely looking forward to having more being contributed, right? And so that's kind of why, that's the process that we had went through, right? Talking to them first, because it made sense. So I think it's just a matter of making sure everybody's on the same page and doing the right thing. Okay. That is the end of our official agenda here. Since we've got just a little bit of time, if there's any opens, we can take those quickly. Otherwise, we will wrap up for the day. So I saw that one of the six is putting out a white paper and I didn't know since that is outside the purview of the TSC. I just didn't know if there needs to be some better coordination or review or whatever. Don't know how other TSC members feel about that. Hey, Mark, can I comment? This is Daniela. We are aware of that. We've actually had been working with Bobby from the development and training working group to make sure that the template was done and we're advising or even the point of contact on the telecom, say, which is David Boswell on the Ecosystems team is working with Vipin and the rest. That white paper is an interesting one because they're also working with the technical leads in the LF networking project, the Linux Foundation networking project. So we are aware of it. Salona and I actually and the teams spent some time talking about putting together, there's a template, there's a white paper template that Bobby and the rest of that working group, technical working group that falls on the TSC as put together to put together some more guidelines around the white paper. So we are aware of it. We have a draft where we're doing it. We'll get back to the TSC and particularly the learning and developments working group around what things we think are important to make sure that we're using the right language and have the right standards and review process. So we will get. Actually, we discussed this yesterday and we were gonna put it on hopefully for next week so the week after is TSC call. But happy to answer any additional questions that the TSC has. Yeah, so this did come up in the governing board meeting just, I think it was this week. And my position is that the SIGs are outside the, it's outside their scope to generate work products that if they're gonna generate work products, then that those need to go through the governance process that we have established for the TSC. And so we've probably created a little bit of an awkward situation in moving the SIGs out from underneath the TSC and finding that there is some interest there in generating work products. But I think we wanna make sure that those stay clearly under proper governance and community development. Yeah, to be clear, the SIGs are creating work products that are hoped that they would create quite a bit from light papers to blog posts, to use cases on a Wiki, all sorts of non-coding things. They're not creating software. The hope is that if they do that, they come in through the ordinary process and to elaborate into a project proposal. And I think whenever they are making technical kinds of things that could be interpreted as some sort of official position of hyperledger, then that makes a ton of sense to bring to the TSC for input and make sure it's accurate. If it's something that describes policy, I don't think they're really, they're not designing policy for any of the technical projects of hyperledger. So, and if they were to recommend one, it obviously makes sense to bring it to the TSC. But the kinds of content they bring are, it's about, I think all the things that we'd agree upon are useful anyways to have. So, yeah, I think the TSC has always been kind of encroached when there's been appropriate things. So, and if we want a more interesting policy than that, let's talk about it offline and bring something back. I think if they're gonna generate any sort of technical product that has to go through either a technical working group or a technical coding project. Is a blog post a technical product? No, I think we've been pretty free-form with the blog posts that anybody can submit a blog post. And I guess it's sort of at the discretion of hyperledger marketing, whether those go up. Okay, and if you want to call to the right- If you do technical reviews. Oh, I think it's fair to say the blog post. I'm sorry, go ahead, go ahead, sorry. I just wanted to make one quick point that we do technical reviews of technical blog posts. They, I do them all the time. They get sent to me quite often, actually, and Rai and other developers in the projects, if they're very specific to a project, we tend to loop in people who could review them. A lot of times the technical blog posts are coming from developers in the projects and we just do a quick pass. So you're like, yep, looks good, right? And it's mostly around just cleaning up language and making sure it aligns with existing policy and things like that. And we'd love more help with that if somebody wants to volunteer to help with that. It just tends to be time critical. Hey, I'd like to put this up sometimes this week. Can we get technical reviews? So that's something we're more than happy to put input on. And I think, as I was gonna say, I agree if you call something a white paper, asking that that be something that the technical steering committee has had a chance to provide input to and approve, I mean, sure. I think they'll find it just the all work product thing. I just wanted, if we wanna get into that conversation, let's talk and bring something back to the TSC. Yeah, it sounds like we're similarly aligned on that things that sound official like white papers should go through governance and things that are a little less formal like a blog post in kind of stay the course. That's all pretty reasonable. All right, well, we got one extra item in. Mark, you had something? I was gonna say as Daniela, you know, eloquent we put, she was gonna write something up and, you know, bring it up for discussion in a week or two. So we should probably see. On screen, I'm showing the Wiki page as to where all this is being documented when they've been working on it. If you, I know many of y'all don't have the ability to view the screen, but that's where it's all being worked upon. Okay, well, that's interesting because the working groups, presumably, would want to be aware of or follow that process. So that sounds like a good point of collaboration and discussion amongst the working groups as well. Maybe that's a proposal in and of itself that should get circulated here at the TSC. I was gonna say something like that. Maybe we just need some form of notification to the TSC. Hey, we're planning to post this, you know, let us know if you have any issues. By default, you assume everybody's okay with it, but at least, you know, people have a chance to interject and they feel like it. Yeah, the publication thing gets really hazy. I mean, if you write a research paper that mentions Hyperledger, do you have to get that approved by the TSC too? If you're gonna put something out that is under the Hyperledger brand, then it needs to go through Hyperledger processes and those might be marketing ones. If it's purely marketing content and if it's technical content, this is the governance body for that. So how do we define... Okay. But you could conceivably do a performance report on Ursa libraries and put that out. I mean, you know, we don't go tell the researchers they can't put something out, right? The fast fabric paper, they... Right, it just becomes nebulous. Like, Mike Lauder and I made a blog post about Ursa. Is that like Hyperledger or not? Did you put it out on a Hyperledger website? Yeah, I was going to tell you... It was at a Hyperledger claim about something. I mean, you can make the claims you want, but Hyperledger cannot make a claim without this. Gotcha. Right. So, I mean, maybe we need to formalize that so that technical blogs or, you know, they get posted by Hyperledger or Papers, for that matter, are reviewed. I think, you know, I think this was brought up previously when we were talking to the smart contracts, going through the smart contracts working group review last week. And in fact, it looks like there is a sort of a loophole in the sense that we didn't explicitly say that, you know, a work group would bring forward its stuff and maybe we need to codify that. That, you know, deliverables that are going to be published by Hyperledger coming out of a working group for us saying should be, if they're technical in nature, should be reviewed by the TSC. So, I mean, I know we're getting towards the end of the call, but I'd be happy to have my proposal for that. Yeah, I think we're all in agreement on that. And I think that's been how we've done things in the past, right? Yes, right. They're just not reading down anywhere. Right. Yeah. And that's the slide that, the thing that Solani just posted the link to is white paper standards. And I think we just make sure that white paper standards, part of that is, you know, submission to for, you know, early on for feedback and, you know, co-creation and invitation, right? All that sort of thing. And then later on for review and then for final approval. And that's worth restating, worth clarifying, worth making part of the official standard and towards, and I think to everybody's point, calling something the paper, you know, is perhaps that's where, that's where there's an officialness to it that for, you know, individual messages and wiki pages you don't have. And I think even blog posts, because when we put blog posts up, we put them under people's names, you know, they're not anonymous. They're not, you know, Moses coming down from the mountain with, you know, 10 commandments. They are, you know, this is Hart's take on, you know, what he's done with performance on this project, you know, and it's his name attached to that. And so I, you know, we keep those kind of personal names. And if there's errors in them, we certainly would correct them quickly as you can do with a blog post. You don't tend to want to do with a paper, right? Yeah. There might actually be some inconsistency there. I think a lot of times they're just go out, post it as by hyper ledger, even if the article itself says by heart or whomever. Probably just some nuance with the way those web pages get generated. Okay. Certainly the intent is, you know, when we put them out just by hyper ledger, that would be the ones that are more official. But okay, we'll look at that. I'm guessing it's whoever clicks the publish button. The word press stuff just automatically tags it that way. I don't think it's anything. Direct. Okay. But. Okay. Well, I think this, this conversation has run its course for right now. So we'll go ahead and wind up for today. Thanks for the good discussion from everybody and continue to update the various wiki pages that we have on these topics that we have discussed. And thanks again for the contributions. See ya. Thank you. Thanks.