 Thank you, Ryan. Hello everyone, only seen known names in the possibly so I guess I could spare myself from my usual speech. You will know that this is a public meeting everybody is welcome to join and contribute. There is two requirements, which is to be aware and live by the antitrust policy and then the code of conduct. I won't get in trouble for skipping through this. I don't think I can make it faster. So, a couple of announcements to get started. There's the usual reminder, right, you want to say something about. Yeah, so definitely is like our one of our big ways to reach out to developers and it's for you and hopefully by you. And we are really looking for participation. It really helps last week was pretty tough because we couldn't, you know, sift through all the PRs and find super cool stuff. So, you know, give us a hand please. And the high culture mentorship program is getting ready to kick off men is on the call if anyone has any questions, but it's pretty straightforward. Yeah, thanks right. I just want to do a quick announcement. We've done this a few iterations. I think this is the fifth year we're doing this. So today we're actually kicking off the call for any active contributors and maintainers, if possible, to submit a project proposal. So, I put the links there so take a look at the kind of a general description of the program the timeline for this year. And also there's a template that you can just click on if you're interested in mentoring and submitting a project proposal. We're actually looking for 20 to 25 projects this year to open up for applications for mentees to apply. This year for mentee one of the things that we want changed is that in the past years we wanted the mentee applicants to be enrolled college and university students. Doesn't matter which part of the world you're from but you have to be a student but we decided to remove that requirement so we're opening up to you know students and non students alike. Hopefully this gave us a bigger, broader pool of, you know, applicants to draw from. Obviously we have the full time schedule which starts supposed full time and part time mentees start on June 1. So if you're full time you just do it for North America, you know it's summer, you know June, July and August. So when it part time is going to run from June through November. So part time really is for people who may have other commitments such as, you know, some people may still be going to school or have another, you know, job. So part time will be a really flexible option for people to to to still, you know, work on these projects and become part of our community. If you have any questions, let me know. Otherwise, yeah, I'm just here and that's it right. Thanks. Sure, Tracy. Thank you. Yeah, so men, a question for you. So the timelines right that we're submitting applications now for selection for June. What are what are the recommendations or best practices that you might have for submitting something that we may not know what is actually coming in June. That would need to be done for a particular project. And, you know, obviously timelines always become an issue and I guess we're wondering like if we submit it something for something specific and things change or things shift. How does that, how does that end up playing out. Yeah, good question. So right now we're asking, you know, any but people in the community who want to mentor to submit a project proposal so we're opening this today. We gave people six weeks to get the proposals on the wiki, and then we have, you know, probably a subgroup of the TSE members to review all the proposals that came in. Then we'll select 20 to 25 proposals and we'll open those up for applications on the Linux foundations called LFX mentorship. So we'll, if your project is selected by the Hyperledger TSE and open and then we will post it on the LFX mentorship application, the app, and you will get applicants for sure you'll be able to find somebody who would like to work on your project. So it's a matter of, you know, yes, I agree things might change between now and the official, you know, June 1 women to start working on it. But, you know, we're pretty flexible and I think we gave a lot of, you know, for the mentors right to adjust as things progress or you know if they're certain blockers or you know you can always change the milestones and some of the outcomes that you're hoping this project and the mentee to accomplish. Did I answer your question Tracy. I think so, right. I think it sounds like there's flexibility. Obviously, the more specific we can be in our request the probably the better it will be for getting applications. And that maybe something that's new like, you know, help out a feature in Project X is probably not the way to go. I think that's what I've heard. We did have, there's a section on our conference called project proposal if you look at there we're. Yes, you know we, you know you will if you will be nice for this project to be, you know, pretty scoped out so that you know sometimes if it's too broad it's it's hard for people who are applying to your project to know exactly what you're looking for. It would be really nice to be more clearly scoped and structured, obviously needs to be related to you know, any of our hyperledger projects or labs. But really, the mentors have quite a bit of flexibility to adjust things as they as, as, as you go. It's really we're trying to create a learning opportunity for the mentees who are, you know, new contributors for the community, and also you know for the mentors like yourself right to, to work with these new developers, adjust things as they go. Yep. Yeah, I wanted to point out that we've had discussions this year about being very careful with the scope of these projects. Last summer, to a greater degree, two summers ago to a lesser degree, we ran into projects that were too big too complex too difficult for the kinds of students and community members that were doing these mentorships. This year I think the goal was to try to pick something very narrow, something very doable, and those tend to not be, you know, bigger picture critical path kinds of tasks so if I hear you right Tracy I, I don't think that we're going to have that much of a concern because, you know, I don't want to be, I don't, I personally would not like to see proposals for, you know, adding a new key type to some core fabric CA thing, right, which would be right in the critical path for the next delivery. I think these should be more researchy, more aspirational, more several versions down the road kind of projects that are also very narrow in scope. It's kind of a hard balance to cut. But I think that's why we're starting earlier so that we can have a longer time to review and revise these proposals. So, hopefully everybody is aware now understands a little bit what this is about the weekend and move forward if anybody has any further questions, they can obviously reach out to me know anybody else in this stuff. Thanks. Thank you. All right, let's move on. Two quarterly reports that are posted. Judging from the response. I see even though fabric was only posted yesterday. Quite a few members have managed to get through it and review that. So thank you all for your effort. Of course, Andrea is always on top and posted the report and so to time. And, and so I didn't see anybody raising the questions or neither the report did. So I don't know that there's needs to be any discussions about any of those reports. This is your chance if you have any questions you didn't raise in the weekend. If not, yeah, Daniel. So what are these reports do I went spend last night fabric was not a wake up it's on the agenda all of a sudden. How much time should we have to review these before they drop on the agenda. So, the way I have been handling this is that, you know, I look at how many people have actually reviewed it before. And I understand that, you know, if it's just before the meeting people may not have a chance, in which case, I bring it up again on the next call, so that people don't, you know, you don't need to stress out if you didn't have a chance. It's okay. I'll just, you know, it's not the, it's not like they were closing the the common period now. One thing that I'll point out, and I'm not quite sure how to automate this is that I have these quarterly reminders set up automatically. I have a reminder one week before it's due. And I don't have a way to change that reminder text to say in one week. This is due. So it seems that the way people are acting is they get the first reminder that hey you have a week. And they think that, you know, wow it was due today, and they scrambled to get it done. And maybe they do that should be at least a couple of days before so that as, you know, that's that most point, they really has a bit of time to review them before the meeting but sure. I think we did there's no, I think there is no real negative impact of not having reviewed it at the time it's first put on the agenda, as I said, I was, I, I oftentimes put that again. I was like okay this was just brought in and it's not possible that everybody has a chance to look at it I just put it again on the next call. So you, I give you two weeks ready to, or at least the whole week to review it between two calls. Does that work for you don't know. Yeah, I mean we get into the agenda proposal there's going to be some mechanics around that so I just want to ask the current process. I understand sounds good thanks. Anything else, anybody else. All right, if not, let's move on. There's actually no presentation today. I do want to remind people I think it was interesting with a couple of presentation already. And I encourage all the other projects to take the opportunity to come to the TSE and give a bit more insights beyond what's coming through the reports, you know, on what's going on in your project. Just like a 1520 minute presentation, nothing more so it's not a huge amount of work. So that brings us to the discussion points. So we have a couple of them. First one, right. I was trying to figure some stuff out. And I realized that the common repo structure was approved almost a year ago. And in fact, Chris Ferris's polar quest for the fabric repo was rejected for a copy of repo lentor.json, which was the one that was used as a as an exemplar and Caliper is the only project that has a repo lentor.json in place. So, yeah. And so I thank you for bringing this up I have quite a few things to say and to for everybody is like, you know, right actually said, you know, do we need to have that on the agenda or is sending a message to everybody enough and I said no let's put it on the agenda because I want to take that as an opportunity to bring what I think is a problem. So first, you know, I have realized that, you know, before that, it's been on my mind that we, we have made some decisions regarding, you know, certain policies basically we have agreed to live by that I don't think we have that I don't think we are necessarily good at implementing or enforcing if the case might be. So for instance, you know, we said a, you know, when projects create new RFCs they should inform all the other projects, and maybe an email to the TSC should be sent to the maintainers list that kind of stuff. I don't think this is happening. And, and here we have the common repository structure. That's another one. I have to say right. It's a bit misrepresenting because there is one thing that I've realized from your messages. I have actually done a year ago when we agreed to do this, you know, I've gone through quite a few of the fabric related repos and and gone through, you know, the exercise of running the repo linter and trying to fix some of the problems. But I did not go as far as submitting the repo linter JSON file to the repository. And it, you know, so I wouldn't conclude because it's not part of the repo that is not used at all. And there is a question which is related I guess is, should we, you know, ask everybody to have one and make it part of the repo and it. Okay, don't know if in the common repository structure we have the repo linter JSON file being there. I see that Daniel raises hand. I want to the point below this, which is actually what drew me to this is that I was trying to find out if repo linter had an option to flag what the main branch was what the master branch was. So that's the only reason that I was looking in the repos themselves. So anyway, Daniel. So the particular software we're using is kind of the moving part with some of the opportunities when it was presented a year ago you had to put repo linter JSON in your repository but they've since updated it so that you can have repo linter be anywhere and then pointed at your project and in the community tools I roll a little script that would clone your repo bring the script and get a report and spit it out. But one thing that I need to make the time to happen. They have a version of repo linter that worked at the GitHub action. We can't point to a Jason that's in a separate repo but we with that particular action but can be written to do that. My thought is rather than requiring people to put repo linter JSON in there and make it a part of the structure. We just need to have an automated action that will put a report as part of their checking policies like we already have for DCO DCOs TSE policy it's a Linux Foundation policy. And it's enforced as part of the action, whether we make it a blocker for the check in I think it's something like this that can be mechanically checked should be mechanically checked whether or not it gates a thing. It gets it into people's position automatically we don't have to change their repository structure to get a report on a standard repo linter.json and also protects repo linter.json from falling out of date when it gets updated as well. If we keep it centralized. Okay, so one point important I think to remind everybody off is that we didn't say that the common repository structure was mandated on all the project. We have encouraged projects to, you know, be to use the common repository structure so we could I don't think it'd be, you know, unless we want to make the decision to change the decision. We cannot just say, hey, we're going to impose it on everybody by running the tool automatically and flagging projects and compliance and so on. And that's also why I thought that being a repository repo linter.json file per project was reasonable because you could, you know, you could have variations that would be acceptable. Is it a point of a standard to say this is what you do. Not this is a strongly where to guideline do whatever you want. Yeah, I think we have to distinguish between musts and shoulds and may right to use that RFC terminology is and and and you know I think we all want to be nice people and and and you know generally tend to default to shoulds but there is a point I think to saying must if we want to have a degree of consistency across the projects and do what we think are our best practices, not just best practices but but something stronger so. So I think, you know, maybe revisiting that and going is this important enough that we tie it to something like graduation from incubation to active, or something to be expected of all active projects or something like that is another dimension, we could we could add to this. Tracy. Yeah, can you open that link right. I want you guys to read this right and what we accepted adopt repo litter with a policy as in fabric PR 630 each repo will add the same repo link.json file and the CA team will periodically run a check to ensure projects are in compliance. So everything that everybody has just said, doesn't match the formal proposal, and what we actually talked about so. We're going to change that formal proposal, and so somebody should put a new proposal in place. Alright thanks Tracy for keeping us on this there. Yeah, and this is this is actually the. This is the commit that was rejected. Thank you Tracy because this is what night this is why I started going down. I thought that this is like the Baron stain bears thing Baron Steen Stein right. It's like am I an alternate reality I thought this was decided, and then I went and looked and in fact it was decided. And Chris's PR was rejected for whatever reason is there a reason that can you show me the bottom of this page. It wasn't rejected it was withdrawn so we didn't understand any of the history here. Okay, I, for whatever reason it wasn't okay. Interesting. All right, so I guess I mean, unless anybody wants to challenge the decision we had initially made. I would then say okay we all need to do better at implementing the decision we've made. So, and then there's the question of a how do we enforce this. So, I suppose we could ask right now and then to check on all the repos to see who is not compliant. I don't want to be the bad cop. No, but you just send us the report the TSE is the bad cop. Okay. Grace, somebody has to get the gather the data right. One idea, I don't know is we could have every decision we make have a TSE kind of owner or representative or follow through person. You know, to be the one to kind of track it to conclusion and be the kind of accountable party that way, as I said it's not on him it's it's you know the TSE action not, you know, and it's not kind of on the staff to do that and that way you know they can work with you know, there's kind of that point of contact to kind of follow through with whatever decisions just one idea. No, it's interesting idea. Any other comments here. Hi, so the thing, the way it was written said it depended on the fabric one and the fabric one was shown to be invalid. So, do we start over. There is one in the, in the community tool repo. That's the one I used. Caliper, there is one project that has it as well. I don't know if you want to wrap the sub point to this into that or not the piece about the master branch versus main question mark. Yeah, that's a different question though. Right. We probably should get it. I mean, I plan to talk about it but in fact I don't know why it's put as a sub bullet I would think that it can be. It's a sub bullet because that trying to answer that question is how I discovered the. Yeah, yeah, but the repo linter doesn't look at this does it. No, that's what I was great. Like, forget all that let's move on. No, but okay, so are we good on the repo linter everybody's going to make the effort in their own project to add repo linter. Jason to their repo and try to comply. And I think we should make you know, I don't know if anybody wants to become the ambassador for this as grace was suggesting maybe we have somebody. But otherwise I suggest we spread the word we tell. Yeah, grace. Just a couple questions. So, obviously the TSE we don't represent every project. So, I'm not sure who would follow up, you know, Daniel and I can go back for base who for example but I'm not sure if we have someone, you know from, you know, burl for example on on the TSE so make sure we don't forget about them and the follow ups and stuff. No, you're absolutely right but so that's where the staff is helpful right because the staff is in contact with all the different projects, and we have several means of communication. You know, we have the TSE where the maintainers least that includes all the maintainers of all the projects. And at least I believe everybody's on right right, or is that somebody can opt out. Not every single person is on there that touches on another pain point, which could probably take the rest of the hour. So, the answer is, no. All right, so at least we can reach out to some of the maintainers through the maintainers list I guess. So, so I think, you know, we should make an effort to communicate grace, your point is valid. It's not like, you know, all the projects are directly represented on the TSE, but I think the staff can help disseminate the message. Okay, right I'm happy to help to if you need help or reaching out and all that and pointing to this because, yeah, I know it's not fun for you, and don't want to, and want to make sure yeah it's communicated clearly to everyone. Thank you. Hey, just wanted to quickly point out that beginning of this TSE term and late, I guess in October. We had the similar topic discussed that how do we make communication effective from these meetings to rest of the community. I guess it would be nice if we can bring that topic back soon. And actually tied this with try these kind of topics to that. Yeah, it's a tough questions. It's a tough question, I don't know what to answer it so I'm happy to discuss it but I don't know. Okay, let's, let's leave it at this for now and it's already half past the hour so I want to make sure we touch on everything today. So let's get to the other point you have right. I'm sure. So this is, I don't know if everyone saw we had a DCI working group blog post about this this week about you know the default branch naming, moving from, you know, non inclusive language like master to more inclusive language like main. And we have as of the time that I wrote this 129 repos under the hyperledger umbrella are using master as a default. So I guess my question to the TSE is, should or should we incentivize this, like as a project to move that, or is this something that is on the maintainers. And I know that Brian had some ideas around this so I will see the floor to Brian. Yeah, not much more than asking, you know, maybe we can use the fact that we're also a bit behind on recognizing some projects as active projects rather than incubation and use this as a, you know, again, carrots and sticks. I think a project is active. That might be something that we set as a requirement if something's an incubation. If they move to this maybe we as a as a TSE and staff help them go the rest of the way to applying for and getting active status, just the thought was to tie that in some way. Maybe that's helpful, maybe not, but, but certainly hope that as we raise this and get it out through maintainers or other channels that more the community can be encouraged to do that. The other thought was trying to set a date, you know, and by, for example, March 1 saying, okay, at the very least you should have copied your master branch to something to a main or something else. And then by April 1 using that new copy exclusively, perhaps deleting the old one because I know there's tooling implications for for such a migration, some some build tools and others will depend upon there being a master branch existing and those would have to be modified before you could properly delete the master branch. So I have the suggestions for how to implement this on force them. And this is also valid for the previous point about the, the repo linter. I think we should make that part of the quarterly reports. And even we could add those questions, literally in the templates but people may not get it. And then it's up to us to see members when we review the report to, you know, ask if it's not there. Are you, you know, are you compliant with the repo linter. Did you make the change from master branch to main. And we have, we could actually say, you know, by the next quarterly report you should all be compliant. And that gives us somewhat of a rolling and deadline but eventually we should all get them all. I think tying that to active status is not right thing because of some projects, you know, this is actually a fairly rare occurrence. So, it's, you know, it's not going to to motivate me but if we if we use the quarterly reports that's what we consistently get. And that gives basically products that three months period of course the ones that have coming next week need to have a bit more break but you know, a more time but essentially I think the quality reports are a good way to enforce those decisions we make. Hey, at least you monitor them and to ask specifically, have you done this. Gary. I saw that you unmuted so I thought you were going to. Oh, sorry, I switched over. I had to switch to my phone so I'm unmuted on the thing and muted on my phone. Okay, no worries. Anyone else any comments. What do you think of my idea. Personally, I think that's a lot easier than having a date. I think the idea of having like a rolling deadline is nice because it'll spread the workload out. I can't support it. Okay, I'm like, I'm like muting you. I don't know how to interpret the signage if people agree they don't care or they disagree silently. Do we say rather than next week starting like with the first report due in March from that point on, give people a month to get it done if we're concerned about it taking a while. You could just say that's what if we just said, this starts q2 right. Your first report in q2 your first report in q2 is give us status and your first report in q3 is we expect it to be done. And I'm using the royal we I'm obviously not a member of the TSC. I think that's a very good proposition actually I like this proposal we can just say that, and it gives everybody quite a bit of time to get there together. We can disseminate if they haven't cut that up by the first report, we can flag it and say hey, watch out, you know, we can ask for status report on those questions specifically and then on the next one they have to comply. Everybody agrees with this. Do we have to make a decision, we can make that official. Sounds good to me. I like it. Okay, so the proposal before the floor is to require a status update in your first report for q2 2021 and then compliance by q, your first report in q3 of 2021 that's a proposal. Yeah. Okay, so someone else should bring it to the floor and motion it. Well, I bring it to the floor. Second. Okay, anybody disagrees with this wants to oppose it. Anybody wants to abstain. It's an active abstain where you speak up to abstain. Otherwise, I will assume everybody agrees. And this is therefore unanimously approved. Thank you. Okay, I think we did pretty well on that. I haven't made one of those decisions in a while so that's a good. Okay, so with that taken care of. Let's get to the project badging proposal. So we talked about this, there was an open issue. We looked at different aspects and talked about, you know, creating new metrics and a badging mechanism to measure how projects are doing beyond what we currently have that basically, you know, is that when you actually transition from essentially incubation to active status, and then I'll actually put a proposal together that's been on the wiki for a few weeks now. Some of us have commented on this, there is actually two parts to it. I don't know if I can speak, but I would like to, you know, solicit more discussion or if, you know, if there's general agreement, we could move to the next stage. So Daniel, you're the floor. Yeah, there's there's two wiki pages on this and I consider it something that would happen in three parts. The first one, the first page that I put together is I took our existing active project standards that have been agreed on to get active and conceptualize what would they look like as a set of badges. The second part is the second wiki page, which is the process. And the third step that's not on here that I want to hold off until later because it's can really come up the works is discussion of adding new badges because I think that's one of the real values of a badging system. The badges that aren't necessarily appropriate for new active projects, but are great indicators of continuing projects like the one that right brought up, I think it was right to brought it up about how quick you are respond to get hub issues and pull requests that show how responsive a community is, that's not necessarily, you know, something that's captured by the productive process, and shouldn't be because it's not a one and done thing it's a continual process. So the first step I went through and try to split up into a set of number of badges based on the major sub points and I put into it, a set of criteria and objective criteria to say, what does this badge cover. And the second part is I said, you know what sort of evidence should you submit today, I have this badge and also the frequency that you would need to submit that evidence, because some badges, you know, are kind of one and done we're on hyper ledger infrastructure that's pretty obvious once you get over there. And that doesn't change until something dramatically changes. But some, some stuff needs to be I put in there they're called the renewable badges that they're good for like a year. And every year you need to submit new evidence to say hey we're still doing this, hey we're still releasing software, we're still up to date on our licensing. So if we go through some of these, you know, give the name of the badge legal, you know what it describes the criteria, and then the evidence I think you centralize it's probably going to be the most contentious one, because that's always the most contentious issue with with the active process, and unless you know what the goal is what the objective standards are and what the preferred evidence is and how often you need to give it. And so, if you have everything but the decentralized this gives a way for projects to say hey, we have everything around it we just have this one issue with getting more, more, more diverse corporate representation here. And I'm using the word decentralized instead of diversity, reserving diversity for talking about people, and he said realization for talking about organizations, because we may want to put a diversity badge in there. So it means that people think about it when they, you know, see diversity project and all it's going to get two different words to do different separate concepts. Um, so the second step is the badging process up page right could click on that. So the general process that I would propose for this is that project self certified and say hey, we have this badge. And they do it as part of the quarterly report we put a section of the quarterly report say new badges or renewed badges, and they would list the badges that are new to them or renew and put links to the evidence maybe to separate wiki page maybe it's small enough. It's a direct link in the report and say hey, we think we're in these badges. Now because we're in a decentralized distributed ledger technology. You know we need to deal with, you know, by the team fault tolerance we should presume that we can handle at least a third of the people behaving badly, we need to have some sort of a formal process around it. So the process around that is that you would be able to challenge someone else's badge if you don't think the evidence is sufficient. So it goes into the question I had about, you know how much time we have to review these quarterly reports. So I'd expect there would be some revision to the particular mechanics of this. But basically when reports been out for a week you would have a week to challenge it. And we would limit the challenges to TSC member or maintainers. So some random Joe couldn't come in and challenge a badge and problems. It's got to be someone with with a stake in the game. So basically they challenge it and you know you try and work it out and if you can't work it out. Ultimately you bring it to a vote the TSC. And if the majority of the TSC quorum says that they have the badge they have the badge. And if the form of the TSC vote says they don't have the badge and they don't have the badge. Now sometimes this could be because of a mistake. So there's one opportunity to cure the gallons the next week and say you're right we, you know, we only listed three companies and two of them are the same. We have like five different companies here. So here's a different member, maintenance from a different company to kind of review the, the, the evidence and, you know, for take of, you know, ease of the process you can do that only once and if you don't get it. If the challenge is not accepted to overturn the challenge. Then you can just come back the next quarter. So I think the key things of this proposal or that you self certified, you do it every quarter. Challenges are talented once and you can attempt to correct that successful calendar once. And if you can't do that you come back to the next quarter and try again. And the third step that we haven't gone into is once we get this in place. We should bring in new new badges that represent things that aren't necessarily aren't necessarily related to active status, but are related to the health of an ongoing project like do you let PRs bird in the sun and no one looks at them or do you respond to them within 24 hours. You know, those are some things that I think are really important for ongoing community health and if we give them a badge, we instead of by projects to get some sort of a, you know, a green light on a dashboard to say hey we need to fix that to get some sort of an incentive and gives a TSC some sort of teeth when they do some policies that can be enforced via badging system. So I know that some of us have already looked at it and commented sometime last question, but not everybody has. I would like to open the floor to questions if anybody has already immediate reaction. Otherwise, I think what I'd like us to do is, you know, give everybody another week to look through this if they haven't had chance to do that before. So we can make that a proposal for the TSC to decide on next week. You know, unless there's something that you know it triggers a big discussion and then it will postpone the decision. Once we have decided if it's approved, then we can go into the implementation phase where Daniel turns that into a poor request against the document repository. So is there any questions I would I would just one minor comment I mean the on the on the expiration part I think should be, I know it's there, I didn't see it initially as you may see in one of the comments I put down there. And it's there but I know I think it would be worth highlighting it to be differently than the way you have on the other page, instead of in parenthesis where you say like, I knew only at least I would make it a separate entry in the badge definition record, if you will. Yeah, that's user experience. Thanks. Hey, thanks, Daniel. So a quick question to you. Have you considered an automated way of issuing badges instead of somebody self certifying and then somebody else going to review it. The self certifying tool, or let's say, even if we spend a week or two on developing such a thing. It helps in maintaining the status up to date and without much interference. So I thought of this and the problem is some of these badges if we could go back to the badge pages fall down through some of them. Some of them at the end of the day are subjective. The alignment is a great example of a subjective one. There's no way you can write an automated tool to say we align our chart, or we align with type of legend. So my thought is things that can be automated, probably belong in something like a repo literature, something that can be completely totally automated. If it's automated that the CSC just sets a standard, and you set a tool to check the standard and you put that on the dashboard. And maybe we will get I mean I can honestly see repo structure repository structure being a badge that you would self certify maybe we create a third category of automated badging that shows up with the tool passes in and updates the dashboard so maybe we could add that to the to the standard as we add new badges. But as far as the active status, I think every single one of these categories has at least a tiny bit of subjective judgment that goes into each and every one of them. Okay, can I continue or. Yeah, if you want to follow up. Sorry for the interruption hard side. So yeah, and on that maybe I have another thought I can follow up as a comment on on the page for these subjective thoughts right maybe we can have a process because TSE has the reports quarterly reports. And instead of letting everyone adding their comments probably we can have a voting based thing within the TSE or we could have a consortium kind of people. I mean, one who understands the project better plus the TSE. I'll probably propose that on on a comment in the process page. That's all thank you. All right, thank you. Paul. Hey, thanks dana first of all for putting this together I think this is a great step forward. Thanks for the comments. First of all, I'm a little worried that the challenge process might become adversarial, you know, I don't want. I don't want this to like, you know, to be used to essentially like nitpick minor things. And I particularly don't want it to be like a work inflator, where, you know, say, it takes me like, you know, five minutes to write up like a small paragraph on, you know, like a minor complaint on you of some say repo structure, and then it takes say Arno like two hours to have to respond to that. So that's, that's one thing and we also don't want it to be the case, like, I guess like right pointed out with the common repo stuff where we all just ignore sort of each other shortcomings either so I think we need to have steps for both. I also would like to say that, you know, going forward, I think a great thing to do would be is if we could start sort of by listing all of the badges and what we want for for badging criteria in a way that allows us to sort of decide things individually because I think that there will be a lot of badging stuff that we can all agree on pretty easily but there will be some stuff that requires a lot more discussion like we haven't even begun. To talk about the project diversity metric which has historically always been the sticking point for this kind of stuff. So I think, you know, just just getting this ready for sort of badge by badge discussion so we can get the easy stuff out of the way and then hammer out the hard points is a great strategy going forward. So there is a badge that touches on diversity aspect. Right. And I think this will be by far the most contentious one. But I have to say I do agree with the first statement you made regarding the adversarial nature. And if you look at the comment I put one of my comments was very much in that line like it felt like the escalation process in case of challenges and all seem to be very formal and very quick. And I know Daniel says well I don't know, you know, it seems necessary anyway, but I also feel like it'd be nice to have a way to achieve the same outcome without making it adversarial. And I don't know how to do that though, because you you you made that comment but you haven't offered about today's solution of you. No, I have not. I'm hoping someone can come up with a good one. I'm welcome to alternate solutions and you know I could rewrite that part to say that at first there is a mediation process we speak with the main standards and make it. I'm going to put more verbiage on that. But if we're going to have objective criteria that we're going to have a second criteria this autumn. But if we're going to have a subjective criteria at some point there's going to have to be a group judgments and something like that if it's clear how the group judgment happens people know what they're getting into. So the formality does yes it looks like it could become adversarial. It provides certainty as to what will really happen so when you're through the mediation stage, you understand and you know, well I've gone through this and you know have to TSE has said bad things about the evidence on my badge so maybe I should just withdraw it, instead of go through a vote. So I'll put in some more verbiage about the mediation and discussion that has to happen before a challenge can be voted on. I mean, even when you talk mediation, it sounds very formal again and my opinion was more like, you know, we should have some wording about encouraging the different parties to talk to one another and figure out whether there's a real disconnect or not. Because, you know, that's kind of informal and maybe sweeping the issue into the rug I don't know, but it feels like that might be enough to diffuse some major challenge that would then blow up into a big controversial thing. Yeah, it doesn't work. The process would, I know the process would still function, but more as a fallback, not as the normal way, you know, the. So Angelo has been waiting. So I must admit that if I can say this straight, I'm against this thing for the simple reason that I still haven't seen or maybe this will come later during a discussion, a discussion about the benefits against the costs of this initiative and in particular I was thinking who is our customer who is the customer of these badges. It's who is gonna use the ones to use this hyper ledger project, but what counts really I mean it's I think what the only thing that counts here is the number of success stories that each project can tell not the by the badge that we put. First of all, I also don't want to go into any political discussions or say oh this should they should get this badge or for some other reason I personally I don't want to do this this kind of this kind of work. But I really think we should analyze the costs and the benefits for our end customer who is gonna look at these badges why we should ask the projects to spend cycles on these badges rather than spending cycles on making on making their project successful. This is this is really my point. All right now that's a that's a fair question but I do think we have quite a few motivating factors to make us look into this. So first, you're aware that we have you know this notion of active status versus incubation. And the underlying point here is that we, a lot of us feel like this is not an appropriate way to convey the what's going really what's really going on into the projects. The issue that we're trying to address is confusion among the community of users who come to hyper ledger and see those labels and don't actually understand what they mean. And we've heard from the Aries project the other day that for instance in their case, they have a bit of a mixed bag situation because they have different sub projects and, you know, and so they don't know if they can qualify as an active status and so on. So we are trying to provide more clarity as to the status of the different projects by having those badges that communicate, and that are more dynamic than the status of a project between incubation and active, which is kind of a one time threshold, and doesn't seem to capture, any possible evolutions. We have had these discussions about, you know, project diverging from the initial charter. There were several issues like this have come up. And this is an attempt to address some of those issues. You go. I mean, let's ask to the project to the project leaders to make their project more streamlined that someone when comes to the to the project that they it's clear what they do what they deliver. I mean, it's up to them at the end of the day it's the project leaders they want their project to be used right it's in their interest. If they don't do that, if they don't make the decision easy, they will just die. Hey, but by the way before anybody speaks can I just say I'm raising my hand so I want to be put in the queue this time. Tracy first. Yeah, I just want to comment on the challenge process right that seems like administrative nightmare. That's what it seems like to me. I know when we initially had talked about kind of the challenges that we have with moving from incubation to active and then on grace you can comment on this because of the challenges that you had was getting based you to active right is that it felt very subjective to you. As you went through that process. And so the only way that I think we have any chance of making this successful is if our criteria can be completely objective. Basically, yes you are or no you're not and if you're not, then you don't get the badge if you are the badge. I don't think anything that adds subjectivity to this isn't any better than what we have today, and just adds confusion. All right, thank you, Tracy. Back on. Let her go first I think the first. Okay, Gary. Yeah, I think I would kind of agree with Tracy so I like the, and maybe I see where Angela was coming from to right and heart. So, I think the only reason that something gets adversarial. And then how this thing turns into some type of competition. And then I think it becomes very careful as to which things you decide to badge. Right. And which things we think are important that community users, you know want to know about a product, right. And I'm not sure that getting into like features. I don't know what's going on in there is the right thing. Like, it's like if we had I like the original idea right we said there was an adherence to standards. Okay, so you have to, I don't know what you do do do this thing you have to have 100% test completion I don't know whatever right. But if you think about when you go to an open source project right. What are the things that we think are important for somebody to check, and that are fairly objective that you could verify yourself. Right. And then we'll put the test badge in there right you know how about what percent of tests are failing. Last date, right. I think there are interesting metrics on GitHub stuff right the pull requests response to pull request those things are kind of interesting right they're pretty much objective and not subjective. And I guess isn't the goal to provide some level of information, some commonality or some level of information about our users to give them confidence and why they should use why they should feel confident in using the code base. Isn't that really isn't that really the end goal. Now feature function is different than that right. I can feel confident using a code base that may not have a feature and function I want. They're two separate things. And I think we have to be careful not to mix them. No, that's correct. Okay, Daniel, I'll give you the floor and we'll have to close after that but I'm glad we had this discussion obviously people have quite a bit to say. So to circle back to Angelo's original question about you know what problem is it solving. I think that the current active process is broken. There are projects that deserve to be active that aren't, and there are projects at one point that were active that no longer meet the standards. And what it comes down to is there have been sales people from hyper ledger companies and sales called them said oh no you shouldn't use this hyper ledger project, because it's still an incubation, which was never the goal of the active in active it's supposed to be reflection of the community, but people downstream using it don't see that they don't understand that nuance, they see incubation, and they think not ready for production. So there are absolutely incubating projects that are absolutely worthy of use of production today in hyper ledger. So that's my main motivation of getting this is to get something that downstream. People will be able to accurately use and that it says what it claims to say, rather than getting muddled up with, you know, what people think it means. Thank you for resetting the goal here I completely share Daniel's goal here I think this is really what this is about and trying to achieve. I do. You know, it seems pretty clear we might need to massage a bit more. You know, it's either the badges themselves or and the process. But this for now I encourage everybody to continue the discussion either through the mailing list on the weekly. For now we have to close so thank you all for joining. We'll talk again next week.