 Okay All right, so What do we have on our agenda? We have Reminder of the hackfest we have a discussion around the cello community and it's actually it's a broader conversation I think that we should have which is Because I think the cello issue is resolved, but I do think we want to talk about the whole notion of You know private back channel Discussion groups and so forth We have an FYI, I don't know if Makoto-san is on the call, but I think There's been a here emails that Roja would like to seek Approval to graduate and so I think they're proposing to propose is where that is and then Dave would like to have a discussion on CII badge certification requirements for graduation and For the various projects that we have are there any other agenda items? Good Makoto. We'll tell you up Third in the agenda. Okay. I guess we can get started. So Todd you want to bring us up to date on the hackfest and I guess it would be Interesting to know how many people have registered or are planning to register Yep, certainly. So a hackfest is confirmed June 19th and 20th in Beijing This is co-co located with LC 3 which is essentially the Linux con Beijing event Right now. There are 15 people registered Which is pretty typical this far out But if you are planning to attend, please get registered as soon as possible just so We can plan accordingly Me and then as always we have a draft agenda I don't think much is in there as of this point, but any topics you want to see you get covered Please get those slotted in ASAP And I want to add so we've decided It's correct me if I'm wrong Todd We've decided to pass on the hackathon at this time. I We it turns out Beijing is about as expensive as New York when it comes to spaces That would be suitable for this thing right now And as well, it felt like you know, there wasn't as much kind of momentum going into that as as we would have liked Especially for this more ambitious idea of making it very focused on crawling inside the code But it was also partly influenced by the realization that we have room at the hackfest for 200 people. I I mean just again This is the nature of the size that we're able to find in the location which was Co-located with the with the Linux conference So we have a tremendous amount of room and we could really focus on using the hackfest For the kinds of kind of high-level. I mean kind of I'm sorry deep dive kind of conversations that we typically have but we could also use it for Bringing a lot of new contributors into the system helping them understand, you know, how the community works how the code works And so I'm what I'm hoping that we can do is focus our promotional energy and focus our kind of Convertational energy at the hackfest on on really bringing new devs in and getting them, you know Up to speed on how to be contributors to the different projects And and and spread that knowledge about how the projects work that sort of thing And so I still strongly encourage people to travel if they can because I think it will be a really intense and fun event What I'd also like to see if possible if there are some particularly maintainers of Projects who even if you can't travel could commit to being online and accessible during this time Or even during Europe and ordinary, you know work and waking hours But still on those two days to help answer questions to help If new, you know pull requests come up or you know kind of deeper dives kinds of questions that Ordinarily being in person would help answer. It'd be really great to have To know that there might be some some quicker response to those questions and then typical for a Monday Tuesday kind of thing so So that's it. So feel free as well even if you can't make it to suggest ideas for the agenda Is that you think folks might find by an interesting to talk about? And that's it any question Okay, if not, I guess we can Move on. Do we have any questions or actually? I mean, maybe we just go around The horn and you know if we can get you know people to indicate in the chat if they are thinking of going I just like to get a sense for people are thinking Attending hi, this is David from a touchy. I'm not online. So I can't do the chat But we are sending we're working through the approval. So we'll be sending to people Okay, great. I guess we can move on to the next topic of conversation. I don't know Brian Do you want to tee this up? Maybe best? I would I would I mean I Was offline for a lot of yesterday or at least a swimming around in the Oskan Conference kind of Kind of circuit so I wasn't able to participate as directly but getting caught up on it overnight I was really happy to see the community not only have a frank and on a conversation about it But also converge on a solution and in particular. I want to thank Arnold for really stepping in and and then trying to navigate the issue and understand and then articulate what what the right solution might be for Bawa for kind of acknowledging kind of where where the Where the problem lay and being willing to Correct it and for everyone else for contributing positively to the conversation the One of the more challenging or might somebody even say poisonous things that can happen in an open-source community is A sense that the real conversation is happening somewhere else, right? even if that's not the case or even if What happens in slide channels or private conversations is not decisional in nature The sense that you know FOMO fear of missing out Is a is a real? psychological Toxin and so what's really important in in these communities is to help people understand where is the real conversation taking place and where What what are the fewest channels one has to follow to be able to be a part of the governance of a project and so We've supported the China community in being able to use the tools that are more convenient for them As a means to help on board new developers to help answer basic questions The structure of the technical working group China is such that it's designed to be how do we get the local community? They're really fired up and and and and competent about these technologies and and get them to the point of being contributors on the premise that as they Come up with patches as they come up with ideas Those get brought over to the main community right through our standard channels for really what you'd call the decisional type of conversations and then implementation work and so You know having having a side channel related to Cello on WeChat not a problem at all if the focus and the committed Focus for that and people really adhere to this is about bringing new developers in But anytime those conversations evolve to hey We ought to do this or maybe we could make it easier if it did that or let's add this feature Those should be brought to the more formal channels to WeChat to commit to I'm sorry to to rocket chat To the mailing list to JIRA and then eventually into obviously the code Repository so I think if we keep that in mind that that will serve as a guide for navigating these kinds of issues in the future And I do also think even these unofficial side channels when they're about convenience also need to be open also need to be Accessible in even even to observers and I think we still need to figure out what what kind of drove that concern about lurkers on the channel because I think you know and I'll end with this the Every community has a power law dynamic, you know typically one-tenth of the participants in any online community will actually be active contributors and the other 90% are observing are waiting sometimes they're learning trying to figure out how to contribute Sometimes there's just users who want to maintain an ambient awareness of what's going on on the project So they can plan accordingly and that isn't the problem at all There's no extra cost to having additional members on the mailing list and there shouldn't be to having extra members on the chat And so I think that's also an epic that we need to make sure It is permeated in all of the official or even unofficial channels that are involved with development So I'll try to write this up in an email to the to the to the list to which this issue was posted But I again just want to thank the community really for stepping in and and finding a way to Finding a path out of the situation. Thanks Brian. Yeah, I wholeheartedly agree with all of that I just would also though like to just reinforce You know that I think in rocket chat. We've had rye going in and and you know, at least You know when he catches that there's a private channel to try and and and fix that but We I think we all just need to be sensitive to the fact that you know, the you know What what Brian was saying that we really do want to be completely open and transparent in all Shapes and forms and you know having lurkers is actually it's it's it's been a thing for as long as there's been you know open source projects out on the internet and And it's it's it's it's sort of it's a fact of life people like to sort of lurk and just follow what's going on They aren't necessarily participating, but that's it's okay. It's it's perfectly normal not everybody is You know eager to to get out and And so we have a lot of wall flowers in open source. It's just the nature of things but You know the more that we can keep everything completely open transparent do everything out in the open Well, any other comments or no? Hi, this is Victor I Want to say and thanks thanks our lord for help solving the problem and Make the witcher channel open is one thing, but I think there are other things about openness for Because with the witcher channel is open or not. It's decided by only one person It's not a pattern of democracy. So I think And I have already gave some advice On the mailing list and I suggested to transfer the ownership of the witcher channel to new foundation representatives and I think developers can gather together and having private Discussion channels, but the development progress should be going public It's not to support discussing The development thing in the private channel Especially if it's established by the project lead and using the same name of the project So it's hard to say it's private or public because it's a private or public because decisions are made there So we've we've looked at having the ownership there is a an official hyper ledger we chat channel that We're we've looked at trying to get the ownership of that channel transferred to a roll account And there's complexity because roll accounts are Limited to organizations that are official organizations operating in China as I understand it And so it's one of the things we're trying to figure out how to do with our footprints in China and with our community that Kind of our staff that are based in Hong Kong So I think that might have been left as a forgotten to do and I'll try to follow up on that and you know, but the catching up on all of the you know project specific channels that might emerge Might be a challenge. So so I think I think I do want to focus on getting the ethic rights and the morals right in the community And and you know, and then we can talk about kind of ownership and control kind of as a result of that as an after Hi, this is Howard. So I'm the guy that send the email So I I I think the WeChat group Need to be fixed That's going Without saying But I want to echo Victor's comment is that The actual solution I was looking forward to get from the hyperledger community is to establish formal procedures that put this check and balance of You know power of either the project lead or the horror viewers in place so that For example, Opensack community has been very like insisting on they have this for open principles So the TC of Opensack will regularly check all the official projects. So check their diversity Check their compliance with openness So I think this is like one one of the aspect that We could improve upon Another thing is we we need to have For example in the TS Charter if we have one to To to to formalize For example, what is the procedure to promote? From a contributor to a core reviewer. What is the procedure to remove a Core reviewer from the from his position So it cannot be done Just by the grace of the project lead, you know, so the the whole thing I wasn't actually campaign Complain about whether the WeChat group is official or whether or not I was mainly concerning the way of Managing projects the way of how we operating as a at least a normal open source project Okay, thanks Howard. So In fact some well, okay, so so we we've sort of shied away from initially You know actually to this point From dictating any policy with regards to how you manage a given One of the umbrella projects, you know, like fabric or sawtooth or Roja or whatever and Basically left the governance of that project up to the project team itself And so we haven't imposed over arching Policy regarding to what you call your committers or maintainers or whatever And how they're promoted demoted and handled we could I guess the concern has been because many of these projects are being brought in From the outside and they're already in some cases established that Forcing an established project to change its process Is not necessarily conducive to bringing more into the fold I do think though that your point on having sort of a periodic review of the processes and so forth is Actually a good one And maybe there can be just some some sort of Objective criteria that could be measured to determine whether or not the policy is reasonable But I think You know, we collectively would have to come up with something that isn't necessarily stipulating a process so much as Something that we could all agree that we could use to assess whether a policy for how you manage can committers or maintainers or whatever is in place Does that make sense? Yeah Yeah, I agree. This should be a process so I Think for example, like reopen the witch hat group Will not address the issue entirely It might be a good first step but we have to like follow follow a long process that gradually establishing this governance model and you know, everyone should feel like safe and Just just just being hyper ledger should be no difference being in other open source communities Another thing I want to emphasize is that it is okay on the technical side that the project lead Present this you know kind of dominant force. I think it's It's a common practice In order to improve the efficiency of the development and I think this are all okay It's just the non technical part of it The none type technical part of job of a pto This is what at least I think needs to work on I think we could probably continue a lot of this over email but I agree that I Having having some documentation having some some of the basic guidelines and and and figuring out What do we actually want to standardize across projects when it comes to? Developer culture and developer, you know the past from being a you know basic contributor to a core maintainer right Putting putting that into paper having minimum viable process I think it is important not having too many rules because then this can just forget one or two and Inconsistent implementation is worse than no implementation So let's let's figure it progressively to get there and the great news is we have 20 years of the open source Other open source communities figuring out what works and doesn't work that we Do this kind of thing? So I Agree with that and think we can start we can start the process of figuring out what what's the right? What do we want all projects to follow to make sure that they are transparent and Accessible and that the processes are fair too. So thank you for for raising all these issues And If I may add just one thing, I mean, this is honest speaking, you know, it seems like a lot of this is due to the fact that there is a Big percentage of the people involved in this project that actually knew to open source and they don't necessarily understand what's expected I hope you know as we go through these pains Eventually people will learn and improve. I have no doubt, you know people like in this case Is well intended and they will you know, he was happy to have a chat with me and learn and I'm sure you'll do better next time But I think what's important is even, you know, no matter how hard we try to develop the process There will always be cases where, you know, people have dispute over what's the interpretation of the process or whatnot And so I can only encourage again people to step up sooner rather than later Don't let things start getting annoying in the way and and you know Start building resentment or something and then slam the door and just quietly go away I really I'm sure it's you know, this is true for the TSC members We are very open to you coming if you have any doubts whatsoever at any point in time about how things are Taking place and you know, reach out to us. I'm happy to help for sure And and this is Leonard. Good morning everyone and that's a very good thing that Brian Chris, you're so fine. It was just said Yes, I do need governance because the level of maturity we now have in high colleges such that we can equate ourselves to any large corporation out there trying to produce stuff stuff meaning product services Improvement in hands on existing products and services although you might say the component the Applications come from outside, but we there to provide standards and we can have Systems for our industries that have been said means we need to have the right level of process Procedures all of that's part of governance. And yeah, so this is an issue we now need to look at and see if we can improve our Governance process to make it Happy and enjoyable might say project For our different teams based on their cultural environment Sometimes that can play a part in how decisions are made and how we address it So it's that sensitivity. We need to bring to every project based on its merits And I think everyone has said we agree. I've just seen that the document that I Think it's you Brian posted on on process So maybe you can look to see how we can tweak it a little more in favor for that Outstanding and we can all be happy campus right forward But it's a learning process and I'm happy that the gentleman brought it to our attention and we can look to it To address it in a better fit of a manner for all this Okay, next up is Unless there's anybody else that wants to chime in There they are is the because it's on wanted to Bring forward a proposal Should I talk? Can everyone hear me? Yep. Okay, great. Yeah, it's sorry I don't always stay up late, but actually the time changed. So this meeting is now the more reasonable time I guess daylight savings time or something changed in the States so we're working on the proposal for Promoting you know how to Active status. So I'm going to send that out into the mailing list in a day or so So just to keep an eye out for it. So We've made a lot of progress on the core system and we're about to merge version 1.0 beta and to master but Besides that the community has grown quite a lot. I think a lot of people are in Japan, but out of 24 Well out of all the contributors to eat or how we have 24 people At our company in 28 outside the company. So I think we're getting closer to reaching critical mass of People where our company is not required for the project to continue And also especially the National Bank of Cambodia has been very helpful and supportive and they're working on helping to develop the project so Even if you know if our company sort of mitzvah went away the project should continue Even without us. So because that I think we should have a serious discussion about, you know Can we promote the project active and You know, what kind of steps should be taken or any thoughts or opinions on that? So anyone have any Rough opinion before I actually send out the official proposal. I can jump in and say that as the security may have been I'm pretty happy with how it has been running Their branching model seems pretty great and the way the community has been working is excellent my only complaint would be that you still heavily rely on telegram for a lot of your communication and You know pointing back to what we were talking about earlier about communication channels being more publicly accessible and I would encourage that you try to push all of your team members away from telegram and over onto rocket chat and the mailing list That's that's my only feedback on that Uh, thanks. Thanks, David. Um, so one comment about telegram. So I was going to actually say something about it just in the previous discussion, but I didn't want to you know, kind of lead everyone to a different topic, but um Yeah, we we don't like Keep people out of the chats But we kind of have fragmentation in some of the chats with respect to that between rocket chat and getter and telegram a lot of it are the same people and Some of the people are in all three the different places, but um, it's not really convenient We still manage issues and things like that on github, but it'd be really great if we could You know build a bridge between the different Platforms so there's a message forwarding apps for example from rocket chat to telegram and to slack Uh different places like that Yeah, some of our some people like to use slack as well. I'm not I don't we don't do too much without though But with the forwarding apps, there's one error I was having with respect to the rocket chat sub the links foundation uses because logins rely on the links foundation ID it's Seems to not work. So there's some kind of bug or something. So I was wondering if it wouldn't be possible to get Some kind of support from rye or someone to help with a message message forwarding I think the problem with message forwarding between different systems is that it's fragile And it'll break silently When it breaks it could could break silently and it breaks I think a better approach is to decide that one of them is the decisional Channel and that the others are about Support and help and I mean even there it helps to have everything in one frankly, but If it's about if it's really because of you know network blocks for example Which is a big reason why in China it's hard to use the tools the rest of the world can use Then you you have to do that But if it's about one developer likes the UI of one tool slightly better than another Though that's a less compelling reason to to divide the community because it's really hard to keep up with three messaging systems Right for messaging systems for any one developer and so the risk of fragmentation of the community is is something to really be You know cautious about right is to really try to fight hard again, and I think that means just trying to pick one and letting the others be secondary But but not as not as Trying to integrate them all together because they because they have different you eyes That's why bridges and not to work well when I've seen them even between like IRC and flak which should work well In reality, it's really painful even between the two tools that are most alike That's a fair comment to be honest though. I think some forwarding is better than nothing I don't know we can try to push people some more But I've already asked people several times to go towards rocket chat, but it's hard to Motivate people to to switch If you have any ideas how to motivate people, let me know The community could pick one that's different from rocket chat if it had the same accessible Properties as rocket chat has you know the same ability to search history the same ability to For anybody to be able to join that sort of thing, you know, we're also supporting Side channels when language is an issue as well, right? You know you want to allow people to support each other in a their local language if that's their preferred And and clear kind of language, but but you know if you wanted to pick get her as your decisional You know chat channel then That might not be a problem if it meets these other kind of community requirements, but I You know, I do think that's part of the leadership of a project is picking one and You know cajoling the outliers to to get on board with that one Okay. Yeah, that's a fair enough comment. So Yeah, that's something that I think we can continue to move forward at least we try to keep all the issues and things like that on I'm good help as much as possible and things like design and documentation on the good have For kind of preliminary design and things like that We actually use some things like confluence, but that's actually completely open and we don't require users to log in to see the contents, but that's kind of just like a scratch pad Anyway, any other comments? No, so we're looking forward to it Thanks, Makoto-san Okay, thanks. So, yeah, I'll try to finish writing this and Kind of clean up some of the documentation we have on our side as well and send that up Okay, excellent. Actually one quick question. Where do we see the list of contributors? Will we see that on the GitHub activity? Yeah, do you mean maintainers.md or? No, I just when I looked at it, I think it said something like 15 contributors Yeah, so that's that's on one project. So yeah, it that's another thing we should discuss maybe is you know How should we discuss? You know what the contribution is so not everyone has actually You know pushed code, but some of the people have participated in either design or testing So the people who actually are unique individuals pushing code that's all visible on GitHub on the various projects so I can try to Tell you those numbers as well Okay, thank you. Okay Okay, next up is Dave who's gonna raise the bar on you Makoto-san Hey, okay. Yep. I sorry. I was on meeting. Yeah, so I'm bringing a proposal this morning Or today to talk about including the core infrastructure initiative criteria getting the badge as part of the graduation process from Incubation to full Development status either that or make it a criteria for a 1.0 release I really don't care, but I think that we I think there's Consensus around the idea of everybody all the projects in their hyperledger getting their CII badge I just want to decide That we are gonna make that requirement First and if if people are okay with that then we just need to decide when it should be a requirement The second part as I said, I don't really care when that happens Obviously earlier would be better than later But I just want to push Hard for adopting this as a standard at some point I would like to see all hyperledger teams getting it. It puts into place a lot of key elements from a security standpoint that I think are important for our all of our projects to To earn the trust of their users and to have a certain degree of integrity that we're seeking so Does anybody have any comments on that? No, no comments Well then it the one comment that I sent in an email was basically I just thought that the Sentence that said something to the effect that Wouldn't publish a Jira item because it would make the security issue public and I know you and I have chatted about this I think what you're trying to say is that we wouldn't have a publicly accessible Jira item. I think yeah I want to be tracking it in Jira, but as a Restricted access item right that that's correct. Yeah, so Jira has this notion of security Permissions or security assignment. I guess I don't remember exact word it uses But I have another email thread that I've already start up started up on it. I did the research What happens is you create a security policy or security Whatever attribute on Jira and then when a new bug is filed If it's a security bug the person who's filing it needs to needs to assign the security level to you know This is a security bug, right? By doing so that will keep it private even though. It's in our publicly accessible Jira Nobody will be able to see it except for the members of the security triage group Is that an acceptable answer to your concern no it is I'm just saying that I just think it might be worth clarifying that and Yeah, yes, I will definitely make the updates to the proposal I sent it out to the TSC mailing list like late last night I'm probably gonna make another pass on it today because because of this feedback Yeah, um that We can have both right we can have them filed in our public Jira and we can keep them private until they're Resolved and ready to disclose so right That that's the only point. I was everything else. I thought was fine Yeah, and and to answer the questions in chat people saying didn't we already have this Discussion. Yes, I believe we did talk about this, but I don't think it was formally Added to the criteria for the project lifespan, right? I Think we just all agreed. Yes, everybody's gonna get the CII badge I want to just make it explicit that if you're going from incubation to full project that you need to get your CII badge or You know if you're going to your for 1.0 You need to have your CII badge in place. So I'm just trying to make this explicit Dave could you speak to heart's question about why one keeps a security bugs private? And it's not just for active releases. It's it's for different reasons. Yeah, so The reason why you would keep a security bug private is because a it takes time to to figure out what the correct solution is and be you want to be able to If it's a particularly secure well, I guess any security bug you want to potentially go out to the existing Installs like the existing customers of the project and to provide them a way to To patch right basically to get up and plug the security hole before it is known publicly because once it's disclosed all kinds of hacking tools will adopt it and they will start scanning and Trying to exploit unpatched installs of our software. So it's really just to keep our Keep our users ahead of being exploited, right? It's part of what's called responsible disclosure, right? Yeah, and it's it's also a very delicate thing. I mean, it's important I mean, this is something every open source project does have to face is balancing transparency and balancing at equal access and not favoring a Vendor over over over other vendors With the need to manage the disclosure responsibly so that the overall risk of the ecosystem is is You know kept as low as possible. So those who are on the security team have a very special obligation to Make sure that they're not advantaging their own employer unfairly in this process well part of my proposal for the Security bug handling process was that As part of the CII badging thing you each team has to identify at least one engineer who's who's well-versed in security development and I'm proposing that those people Like at least one from each at least one person from each team would be part of this security triage team And we would meet on a regular basis to go through reported issues and work them, right? And into point Brian's point. Yes, we have to balance the security With transparency and I think with responsible disclosure the compromise is Yes, we will keep it private until there's a solution, but we will absolutely disclose it Once there is a solution and to answer Sheehan's Question it's usually after a fix right There's usually a commitment that we will address them in a timely manner. In fact, I think the core infrastructure initiative requirements state that a team has to demonstrate that they respond to security bugs within a certain amount of time When I've been advising the teams I've said that you don't have to spell out X number of days But you just need to spell out a policy that you you are committed to dealing with them in a reasonable amount of time Because we don't have any security bugs or haven't had any security bugs so far We haven't been able to actually demonstrate it so I've been just saying let's have a policy in place for each of the teams and Then we will put this security bug triage group together and then we will demonstrate that That requirement as the need arises as we get security bugs We will get security bugs That's just a given and I want to have a place in a system in place for us to handle this In a publicly accessible way in a responsible way I think the other part of people reporting security bugs is that they Normally give you some deadline right because they want to keep you honest about you fixing that security bug And if you don't fix it within whatever their deadline is they will report it out to the public, right? That's my understanding anyway. Yeah, um, so the us cert Group or actually the cert group at Carnegie Mellon. That's the computer emergency response team Which I think also fed into the us cert group They actually have a publicly stated policy of any Vulnerabilities reported to them. They will make a best good faith effort to contact the developers but They do have a deadline of 45 days So they will sit on a report for 45 days before Disclosing it, um, you know Considering that there's no mitigating Circumstances so if there's if it's being actively worked or if there's it's like a particularly egregious bug Like could take down the dns system or whatever they will not Stay committed to that but they that's the the rough timeline that they have proposed is 45 days Let's see here. So the other question is a good example of a well-written open source security bug policy If you look at the document that I put together, I have a bunch of references at the bottom Links out to security bug policies for a number of groups bitcoin apache Yeah, just a number of really well run open source projects And I should say that I cribbed heavily from the apache one especially in the security bug Handling thing that's pretty much a copy and paste And I'm going to give them attribution in the in the proposal Because they're just rock solid the way the apache group handles security bugs is Probably the best in my opinion They're really good at it Let's see any other questions in chat Um, yeah, okay. So the documentation the cii badge listed Oh, so there yes chris pointed that out. It's not easy to see what the criteria are until you look at the application itself Um, I can post in links to the fabric and the sawtooth applications if you guys would like Or maybe chris can for me because i'm on my phone Yeah, or you know anybody can just go in and you know if you have a github account You can just do it on one of your own one of your own repos Yeah, yeah, and that's the one thing I don't like about the cii page is it's not Easy to look at the criteria until you're actually applying for it right But I think I think the intention there though day is that they see it as a process that you would go back periodically and Yeah, and that they because you you make a pass through it and you say yes. No. Yes. No. Yes. No And then you can adjust it as you come into compliance And then the other piece of it I think I understood that it will be updated and so you probably will have to go back and sort of revisit to address Yeah, um, so to address brian's question about security reporting for the github issues based project I don't have a good answer for that. Um, to be honest, I I will update the proposal today I know that we were talking about cii badge. Now we're talking about the security bug process, but uh Yeah, I'll update I'll update the proposal today for a solution for the github issues based projects I believe github issues has a security flag, but I don't know that for sure. Um, but Yeah, I mean we would like everybody to yeah We would like everybody to move over to jira if at all possible. But if that isn't possible, I will I will address their systems and figure out a way for us to do it Um, this may actually be a reason why you can't use github issues honestly, but I I doubt it I'm pretty sure github has dealt with this many times before Um, anyway to get us back to the cii badge Um, require a proposal that that is a requirement to advance a project Um, is there any other questions related to that before I? Ask christ to put it to a vote. All right Silences acceptance So you said you said you were going to update the proposal. Do you say we want to vote on the proposal now or? I'm going to update the proposal. We'll do can we tackle it next week at the tsc call next week? I just think that probably people would want to vote on the final proposal rather than that's what I'm saying What I'm what I'm calling for a vote for today is should we adopt The core infrastructure initiative badge as requirement to advance a project from Uh, say incubation to full status or from full status to 1.0 status Okay, so let's just focus then on that one thing and and have a discussion because I I suspect and I know we talked about this in the past when we were reviewing the um The the life cycle And so I think probably people would want to weigh in so let's just sort of assume then that the question is should cii badging Be a requirement to advancing from incubator to active And to answer Arno's question Active is just whatever is after incubation So fabric and sawtooth are active projects But aroha is asking today to be to to move forward Well, actually, I think just right now fabric is but I know it's just fabric is okay It's indicated at the hackfest and now aroha I'm a codos on the indicated interest. So I know that there are going to be some requests coming in Yes, and I want to agree with what brian saying here active is different from a software release of 1.0 Right act yet So we could we could make a requirement at either stopping point I just want to I'm proposing that we make it a requirement I don't care where But I just want this to be something that all teams have to do before they get to the yay We're at 1.0 and we're engaging with customers and and pushing for installs and all that stuff Okay, so will it be applied retroactively? Yes, so it would be applied retroactively. I think um fabric is already in the process of going through their application and sawtooth is already applying for cii badge So, um Yeah The the the two active projects are the one active project and the one about to be active Lake it applies only to fabric at this point. Yeah, that's correct. Yes, and fabric is already in the process of getting it So if we accept it as A requirement out of incubation fabric will catch up. They're already way ahead of the other teams anyway on this this front See what about projects that aren't really related to security ie explorer um, so This core infrastructure initiative badge is not focused on security security is just one of many sets of criteria It's actually best practices for running open source software So it includes all kinds of things like have a mailing list have a web page have a publicly accessible Bug tracking tool, you know, it's about transparency and about Being a well-run open source project So I'm only focused on the security aspects of it and that's how we got derailed on onto the security bug Proposal, but this like I said security is probably about 10 percent of the cii badge Does that answer your question? It does. Thanks I'd say if we're looking at this as it's solving technical problems then the the 1o milestone might be more appropriate than the Incubated to active but if we're looking at it as a An aspect of the community's maturity then you would probably apply that as a gate to going active Yeah, I think it makes more sense Putting it as a gate to going active because that would force a team to get all of the open sourcey bits in place Right, right. So I I'll just also since I've just gone through it and Dan I know you just went through it as well About 80 of the questions are Automagically answered for you based on, you know, they do a little bit of introspection on your github repo um And so there's a lot of that filled out But I would say that there's probably 80 percent or even maybe a little bit more That just by virtue of the fact that we're a project in Under the hyper ledger umbrella as it were That the hyper ledger You know umbrella itself is providing for so, you know once Dave gets the security process in place Everybody gets that right And you know the fact that we're you know either using garret and jira means you have a review process in place So there's an awful lot that we have That is just sort of the the the blocking and tackling if you will for hyper ledger itself That you get to tick off. Yes. Yes. Yes. Yes. Yes Or you know the met met met met met I should say So It's not a high bar to be perfectly honest, right? So I I don't want people to think that this is very intimidating. I don't Dan I know you've just been through it yourself. So I don't know if you want to weigh in and sort of echo that um Yeah, I looked through the I think there's a printed list of requirements I'd have to dig up the link. Uh, but when I read through those they weren't intimidating I didn't actually go through the application process, but uh, tom barns One of the sawtooth contributors did So I I can't speak to the specifics of the application. I wasn't sure who'd done. Okay. Yeah So I had a meeting with tom yesterday to go through their application and and um, it's not very onerous actually Yeah, and actually I should point out that there are the the number of the security items in the ci i badge requirements are There's like two or three of them that are blocked by the lack of a security bond process And so that's why this is my top priority Both getting the ci i badge requirement in place and getting a solid security um bug handling process in place So that we can start having badge projects and Doing all the right things around security bugs now that we're starting to move towards 1.0 I just want to fill in just this is tom barns just to fill in for what dan said I I don't know that as much as 80 of it is covered by processes But certainly a great deal of it is covered by the the umbrella processes that we're all That we are all already falling Okay, uh, this is vipin again. Um, well just just want to ask a question Whether uh, if if what i'm hearing is Right, which is uh, which is that this doesn't Really, uh, give you a you know a lot of coverage on the security aspect So is this going to be uh A reason for complacency because we have the ci i badge in place that we should trust the software I mean what what is What's the feeling the community around that that particular aspect? Sorry, what was your questioning in vipin? I just I you cut out a little bit there and i'm trying to figure out what exactly you're asking Okay, having the ci i badge as you have noted is no obviously not a guarantee for You know not Obviously nothing is a guarantee for having a security bug, but if the process is light and security matters Will it give us a false sense of complacency when Getting the security badge to say oh now I mean the ci i badge to say Our software is now secure. I'm not saying that we shouldn't go for the ci i badge process, but i'm just thinking out loud Okay, so the ci i badge is not focused on security. It's focused on doing all the right things That our open source projects should do now under that umbrella there is some security pieces and those Will call it will point out to our security bug process and yes, you're right. It does not give strict criteria of how to do a security bug process Which is why i'm putting in A process that is is much more robust right and i'm looking towards um Other projects that have done this successfully for years when designing ours So yes, the ci i badge is I think it's important. I don't think it's going to give us a false sense of security because It's really about doing all the right things as an open source project You know, I'm not asking about the security bug process. I'm more more interested in Trying to figure out how we can improve security as a whole by following certain other things like You know policy Programming, you know, there are some approaches to improving security Which are not commonly used so maybe some such Practices should be made either, you know by you or somebody else public so that the developers can get information about that kind of approach which Strengthens the overall security of the system Yes, so that is sort of the follow-on after this So we adopt the ci i badging and we adopt the security bug triage system next week or you know shortly thereafter I gave a series of Slides on the ci i badging program At the hackathon and if you remember the last three or four slides were how to keep the security maven happy and I went into pretty deep detail on How we're going to do secure software releases how we're going to do secure software development Things like Making the ci system enforce all of your policies and do static code analysis Making sure that we have dynamic code analysis, you know for each major release, which it actually is part of the ci i badge requirements Looking into doing Sign merges signed commits and then doing signed Releases so that the the release like that the people installing it can verify its integrity doing reproducible builds and things like that I've already had meetings with cloud boundary and several other Cloud distribution type tools to try to figure out what kind of integrity checking is built into those tools And I have a solution that is Is coming together so but I wanted to get these things lined up and knocking down in order Um, I didn't want to confuse you with like a bunch of proposals all at once So yes, this is what um now the Now that i'm focusing more on the security aspects of our software development and the way our teams work Um, you're going to start seeing a lot of these proposals coming fast and furious So we're we're going to tighten everything up if and it's not all based on the ci i badging stuff But the ci i badging does require A good portion of it. Yeah And really I like to address what march is saying. Um, I agree with martin It's really just giving insurance reassurances that we're trying to do the right thing This is this is us demonstrating integrity as as an organization to the internet right and to the people who are using the software and Thankfully, we don't have to figure it all out ourselves. I mean, there's a lot of really great processes in place already with other very security sensitive open source projects and I i'm very well versed in all those because I was part of the one for tour and the the tour browser A deployment system, which was the first project to ever use reproducible builds And we're i'm also looking at things like bitcoin core and ubuntu and all those and and how they do Secure distribution secure development and distribution so Just look for more I guess like sit tight. We're we're going to uh We're going to be tightening everything up So, David, it's a fair to say that the outcome of all your collaboration and And sort of research work will be a Um, sort of policy document Yes Leonard so the idea here is I think the the action items are the output of all of this will be series of blog posts and a published policy um Just describing, you know, the security process is in place at hyper ledger I I've already have Stubbed in blog posts on like the road to 1.0, which is going to talk about Um, all of the things that our projects are doing In the lead up to 1.0 to deserve the the Trust of the community and then also proud posts on Our cii badging requirement and our bug process system, you know, I'm going to be documenting all of this It's all going into the wiki. I'm going to be publishing blog posts working with our marketing group And uh, yeah, ultimately running through the the steering committee here to adopt Policies that all the teams have to adhere to Sounds wonderful. Thank you guys. Yep. Any other questions? Okay So the first policy that we would be adopting is making cii badger requirement I'm mute here any other concerns, um, or maybe Todd you can Take a quick vote. Oh, we probably I think a few people have dropped and we are not at quorum at this point. Um, Let's pick it up then. Yeah next week. You can also have the the proposal we can take them up together Great Sounds good. All right. Thanks Dave and thanks everyone and we'll talk to y'all soon Yep, thanks everybody. Thanks everybody. Have a great day. Take care. Thanks Bye